mysqldump bedste praksis:Del 2 – Migrationsvejledning

I den anden og sidste del af vores mysqldump bedste praksis vil vi tale om, hvordan man håndterer migreringen og importen for lagrede programobjekter og visninger fra din MySQL-database. For at læse mere om forudsætningerne for en vellykket dump- og gendannelsesoperation for store MySQL-databaser, tjek første del af denne 2-delte blogserie.

Import af dine lagrede procedurer, funktioner og triggere

Som standard importerer mysqldump visninger og triggere. Den importerer dog ikke procedurer, funktioner og hændelser. For at importere procedurer og funktioner, --routines mulighed skal angives, og for at importere hændelser, --events mulighed skal angives.

1. Importerer triggere

Mysqldump vil forsøge at dumpe alle triggere i din database som standard. For at kunne dumpe en tabels triggers , skal du have TRIGGER privilegium til bordet. Hvis dumpbrugeren ikke har dette privilegium, vil triggere blive sprunget over, og mysqldump vil ikke give nogen fejl. Så bliv ikke overrasket, hvis du ikke ser nogen udløsere importeret til din destinationsdatabase.

2. Import af begivenheder

For at importere hændelser skal du angive --events mulighed, mens du aktiverer mysqldump-værktøjet. Denne mulighed kræver EVENT privilegier for disse databaser. Igen springer mysqldump over hændelser, hvis dump-brugeren ikke har disse privilegier, selvom du har angivet –hændelsesindstillingen, når du kalder mysqldump.

3. Import af funktioner og lagret procedure

For at importere rutiner skal du angive --routines mulighed, mens du aktiverer mysqldump-værktøjet. Denne mulighed kræver global select privilegier. Selv i dette tilfælde vil mysqldump stille over funktioner og procedurer, hvis dumpbrugeren ikke har disse privilegier, selvom du har specificeret --routines mulighed, når du kalder mysqldump.

3.1 Import af ikke-deterministiske funktioner

Et lagret program, der ændrer data, kaldes ikke-deterministisk, hvis det ikke producerer gentagelige resultater. Eksempel rand() funktion. Det er især udfordrende at bruge sådanne funktioner i replikerede opsætninger, da de kan resultere i forskellige data om kilde og replika. For at kontrollere sådanne muligheder pålægger MySQL visse begrænsninger for funktionsoprettelse, hvis binære logfiler er aktiveret.

Som standard for en CREATE FUNCTION erklæring, der skal accepteres, mindst én af DETERMINISTIC , NO SQL , eller READS SQL DATA skal angives eksplicit. Ellers opstår der en fejl:

FEJL 1418 (HY000) på linje 181:Denne funktion har ingen DETERMINISTIC, NO SQL eller READS SQL DATA i sin erklæring, og binær logning er aktiveret (du *måske* vil bruge den mindre sikre log_bin_trust_funable)

Så hvis din funktion ikke er erklæret som deterministisk på kilden, og binær logning er aktiveret på din destination, vil du se ovenstående fejl under gendannelsen af ​​dumpet. Derfor er det vigtigt at forstå den deterministiske karakter af dine funktioner på forhånd. Hvis du er sikker på, at dine funktioner er deterministiske, skal du aktivere log_bin_trust_function_creators konfiguration på din destination før gendannelsen. Når aktiveret, tillader MySQL oprettelse af sådanne funktioner, selv når binær logning er aktiveret.

4. SQL SECURITY karakteristisk for de lagrede rutiner og visninger.

MySQL tillader en SQL SECURITY kontekst, der skal specificeres, mens butiksprogrammerne eller visningerne oprettes. SQL SECURITY karakteristik kan angives som DEFINER eller INVOKER . Hvis SQL_SECURITY kontekst er DEFINER , udføres rutinen ved at bruge privilegierne for den konto, der er navngivet i rutinen DEFINER klausul. Hvis konteksten er INVOKER , udføres rutinen ved at bruge privilegierne for den bruger, der påberåber den. Standardværdien er DEFINER .

Hvis du gendanner lagrede rutiner eller visninger, skal du sikre dig, at den definerede brugerkonto findes på din destinationsdatabase med passende bevillinger. Ellers vil du støde på fejl under gendannelse.

Lad os demonstrere dette med et eksempel relateret til synspunkter.

Lad os antage, at du har Views V1 og V2 definerer som nedenfor:

CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table;CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;

Bemærk, at visninger som standard dumpes af mysqldump, og hvis du ikke har brugeren 'admin' på din destination, vil du støde på nedenstående fejl under gendannelsesoperationen:

Kommando mislykkedes med fejl - FEJL 1449 (HY000) på linje 206 i filen:'/mysql_data/mysqldump/sqldump_1582457155758.sql':Brugeren angivet som definerer ('admin'@'%') findes ikke.

Bemærk, at det ikke blot er tilstrækkeligt at sikre, at brugeren eksisterer, men at brugeren skal have passende privilegier for at udføre visningerne. For eksempel hvis brugeren admin@'%' findes på destinationen, men har ikke SELECT privilegier på mydb-databasen, vil du se en fejlmeddelelse:

'/mysql_data/mysqldump/sqldump_1582456858033.sql':View 'mydb.V2' refererer til ugyldige tabeller eller kolonne(r) eller funktion(er) eller definerer/invoker of view mangler rettigheder til at bruge dem. 
 
 
 
Er du interesseret i en fuldt administreret MySQL-løsning?
 

 For at lære mere om, hvordan en DBaaS-udbyder som ScaleGrid kan hjælpe dig med at administrere dine MySQL-databaser, tjek vores MySQL-side. Se, hvordan ScaleGrid kan lade dig fokusere mere på at udvikle dit produkt og mindre på at administrere databaser.
 

 
 
 
 
 
 
 
 
 
Oversigt
 

 I denne 2-delte blogserie dækkede vi vigtige forudsætninger, du skal håndtere for at sikre en vellykket migrering af dine data og lagrede programmer. ScaleGrid MySQL-hosting håndterer disse retningslinjer for at give en jævn oplevelse, mens du importerer dine data til ScaleGrid-platformen. Del venligst med os din erfaring og bedste praksis, du anvender til MySQL-datamigrering!