mysqldump bedste praksis:Del 1 – MySQL-forudsætninger

Mysqldump er et klientværktøj, der bruges til at udføre logiske sikkerhedskopier af MySQL-databasen. Dette populære migreringsværktøj er nyttigt til forskellige brugssager af MySQL, såsom:

• Sikkerhedskopiering og gendannelse af databaser.
• Migrering af data fra én server til en anden.
• Migrering af data på tværs af forskellige administrerede MySQL-tjenesteudbydere.
• Migrering af data mellem forskellige versioner af MySQL.

Mysqldump virker ved at læse kildedatabaseobjekterne og generere et sæt SQL-sætninger, der er gemt i en dumpfil. Ved at afspille disse udsagn på destinationsdatabaseserveren rekonstrueres de originale data. Da denne model bruger læsning af hele databasen og derefter i det væsentlige genopbygning, er både dump og gendannelse tidskrævende operationer for en stor database. Processen kan endda blive besværlig, hvis du støder på fejl under enten dump eller gendannelse, da det kan få dig til at løse problemerne og køre operationerne igen. Dette er grunden til, at det er vigtigt at planlægge i god tid, før du begynder at dumpe og genoprette aktiviteten.

I denne blogserie i 2 dele diskuterer vi nogle af de almindelige aspekter, du bør håndtere på forhånd for at sikre en vellykket dump- og gendannelsesaktivitet. I den første del fokuserer vi på de forudsætninger, du skal passe på, mens du importerer MySQL-tabeldataene, og i den anden del vil vi tale om, hvordan du håndterer import for gemte programobjekter og visninger.

1. Pladskrav

For det første er det vigtigt at sikre, at din destinationsdatabasevolumen har tilstrækkelig plads til at opbevare de importerede data. Specifikt skal du være forsigtig, hvis binære logfiler er aktiveret på din destinations-MySQL-database, da binære logfiler, der genereres under import af dataene, kan have næsten samme størrelse som selve dataene. Binære logfiler er nødvendige, hvis du vil gendanne dine data på én server og ønsker, at de skal replikeres. I sådanne tilfælde er det en god idé at planlægge destinationsstørrelsen større end dobbelt så stor som kildedatabasen.

Det er også vigtigt at sikre, at der er tilstrækkelig plads til rådighed på den diskenhed, hvor du genererer mysqldump-outputfilen. Uden disse forholdsregler kan du se, at din dump eller gendannelse mislykkes på grund af utilstrækkelig plads efter at have kørt i lang tid, hvilket er et tab af din produktive tid og indsats.

2. SQL_mode

sql_mode-indstillinger for MySQL-server bestemmer SQL-sætningens syntaks og datavalideringstjek, som serveren udfører for operationerne. Det er vigtigt at sikre sql_mode af kilde- og destinations-MySQL-servere er kompatible med hinanden, eller du kan støde på fejl under gendannelse af det dump, du har taget. Lad os demonstrere dette med et eksempel.

Sig, at du har en tabel på din kilde, som har en datokolonne med indgange som nul datoer:

mysql> vis opret tabelplanlægning;---------------------------------------- ----------------+| Tabel | Opret tabel |------------------------------------------------------- ----------+| skema | OPRET TABEL `sched` ( `id` int(11) DEFAULT NULL, `ts` dato DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin1 |+-------+---------- -------------------------------------------------- -------------------------------------------------- -------mysql> vælg * fra skemaet;+------+------+| id | ts |+------+------------+| 1 | 2020-01-12 || 2 | 0000-00-00 |+------+-------------+

Antag den strenge sql_mode (og NO_ZERO_DATE ) er deaktiveret på kilden, men aktiveret på destinationen – gendannelse af sådanne rækker vil resultere i fejl som:

FEJL 1292 (22007) på linje 40:Forkert datoværdi:'0000-00-00' for kolonne 'ts'' i række 2

Du vil typisk se sådanne problemer, hvis du tager en kompakt dump ved at aktivere den kompakte indstilling som en del af din mysqldump.

Hvis compact er deaktiveret (hvilket er som standard), vil du ikke stå over for dette problem, da mysqldump genererer følgende betingede erklæring som en del af dumpet:

/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;

Dette betyder, at sql_mode under gendannelsen er indstillet til 'NO_AUTO_VALUE_ON_ZERO' før du gendanner tabeldataene, så gendannelsen går fint igennem.

3. Unique_checks og fremmednøglekontrol

Som standard (hvis du ikke bruger –compact option), indstiller mysqldump også følgende:

/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS, FOREIGN_0_CHECKSpre> 
Som forklaret her, kan du fremskynde gendannelsesfunktionen ved midlertidigt at deaktivere unikhedskontrollen under sessionen. For store tabeller sparer dette en masse disk I/O, fordi InnoDB kan bruge sin ændringsbuffer til at skrive sekundære indeksposter i en batch.
 
Hvis du har FOREIGN KEY begrænsninger i dine tabeller, kan du fremskynde tabelgendannelsesoperationen ved at deaktivere tjek af fremmednøgle under gendannelsessessionens varighed:For store tabeller kan dette spare en masse disk I/O.
 
Deaktivering af FOREIGN_KEY_CHECKS vil også hjælpe med at undgå fejl på grund af kontrol af foregin nøglebegrænsninger under gendannelsesoperationen. Når der oprettes en tabel med foregin-nøglebegrænsning, forventer MySQL, at den overordnede tabel, som refereres til af foregin-nøglen, allerede eksisterer. Dette er et problem, da mysqldump-værktøjet dumper tabellerne i alfabetisk rækkefølge. Lad os tage et eksempel for at demonstrere dette.
 
På kildedatabasen har vi to tabeller:
 
CREATE TABLE `solution_table` ( `num1` int(11) IKKE NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`));CREATE TABLE `ref_table` ( `nøgle` int(11) ) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` UDENLANDSKE KEY (`ref_num`) REFERENCER `solution_table` (`num1`))
 
Tabellen ref_table har en fremmednøglebegrænsning, der refererer til solution_table . Baseret på den alfabetiske rækkefølge dumper mysqldump først indholdet af ref_table . Når dette afspilles igen på gendannelsestidspunktet, vil det mislykkes med fejlen:
 
FEJL 1215 (HY000) på linje 50:Kan ikke tilføje en begrænsning af en fremmednøgle - 
 
Hvilket sker under udførelse af oprettelsestabellen for ‘ref_table’ .
 
I opsummering skal du være opmærksom på de problemer, du kan støde på, hvis du angiver --compact mulighed, mens du kører mysqldump.
 
4. Krævede rettigheder for at køre mysqldump
 
Det mindste privilegium, der kræves af mysqldump for at dumpe en database, er SELECT på den database.
 
Men hvis din database har visninger, skal du også have SHOW VIEW-tilladelser, da mysqldump altid dumper visninger sammen med tabellerne i databasen. Antag, at du ikke har SHOW VIEW tilladelser, så mislykkes mysqldump med:
 
 mysqldump:Kunne ikke udføre 'show create table `ivew`':SHOW VIEW kommando nægtet til brugeren 'dumpuser'@'172.31.18.79' for tabel 'iview' (1142)
 
Et andet interessepunkt er, hvis din dumpuser har SELECT tilladelser kun på en bestemt tabel i databasen, vil mysqldump kun dumpe data for den pågældende tabel og ignorerer automatisk alle andre tabeller eller visninger.
 
Så sørg for, at brugeren, der udfører mysqldump, har alle de relevante rettigheder på forhånd for at undgå overraskelser eller fejl på et senere tidspunkt.
 
 
 
 
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.
 

 
 
 
 
 
 
 
 
 
5. Max_allowed_packet
 
Den største kommunikationspakke, der håndteres af mysql, bestemmes af indstillingen max_allowed_packet . I forbindelse med import er en kommunikationspakke en enkelt SQL-sætning, der sendes til MySQL-serveren under gendannelsen ELLER en enkelt række, der sendes til klienten under dumpningen.
 
Standardværdien for max_allowed_packet for mysqldump er 24MB. hvis mysqldump modtager en pakke, der er større end dette, kan du løbe ind i fejlen:
 
mysqldump:Fejl 2020:Fik pakke større end 'max_allowed_packet'-bytes, da tabellen 'huge1' blev dumpet i række:2.
 
Sørg derfor for, at mysqldump bruger den samme eller større værdi af max_allowed_packet der er konfigureret på MySQL-kildeforekomsten.
 
Indstillingen kan angives med flaget --max-allowed-packet=value når du kalder mysqldump.
 
Når du gendanner dumpet, skal du sikre dig, at max_allowed_packet størrelsen på din destinationsserver er stor nok til at modtage pakkerne fra dumpfilen.
 
Ellers vil du under gendannelse af dumpet se en fejlmeddelelse:
 
FEJL 2006 (HY000) på linje 70:MySQL-serveren er forsvundet
 
Denne fejl kan være lidt misvisende, da du måske tror, ​​at MySQL-serveren er lukket ned eller styrtet ned. Men det betyder bare, at serveren har modtaget en større pakke end dens konfigurerede størrelse på max_allowed_packet . Igen er den bedste praksis at sikre, at max_allowed_packet værdien for din destinationsserver er den samme som værdien i kildeserveren. Dette er også en vigtig indstilling, som kan kontrolleres og indstilles korrekt på forhånd, i stedet for at se fejlene i øjnene på et senere tidspunkt.
 
I denne første del af mysqldump-serien diskuterede vi forudsætninger for en vellykket dump- og gendannelsesoperation for store MySQL-databaser for at hjælpe dig med at undgå flere forsøg og uproduktiv tid brugt.
 
I næste del vil vi diskutere bedste praksis for at importere de lagrede programmer og visninger fra din MySQL-database.