mysqldump bästa praxis:Del 1 – MySQL-förutsättningar

Mysqldump är ett klientverktyg som används för att utföra logiska säkerhetskopieringar av MySQL-databasen. Detta populära migreringsverktyg är användbart för olika användningsfall av MySQL som:

• Säkerhetskopiering och återställning av databaser.
• Migrera data från en server till en annan.
• Migrera data mellan olika hanterade MySQL-tjänsteleverantörer.
• Migrera data mellan olika versioner av MySQL.

Mysqldump fungerar genom att läsa källdatabasobjekten och generera en uppsättning SQL-satser som lagras i en dumpfil. Genom att spela upp dessa uttalanden på måldatabasservern rekonstrueras originaldata. Eftersom denna modell använder läsning av hela databasen och sedan i huvudsak ombyggnad, är både dumpning och återställning tidskrävande operationer för en stor databas. Processen kan till och med bli besvärlig om du stöter på fel under antingen dumpning eller återställning eftersom det kan leda till att du åtgärdar problemen och kör om operationerna. Det är därför det är viktigt att planera i god tid innan du tar upp dumpningen och återställer aktiviteten.

I den här bloggserien i två delar diskuterar vi några av de vanligaste aspekterna du bör hantera i förväg för att säkerställa en framgångsrik dumpnings- och återställningsaktivitet. I den första delen fokuserar vi på de förutsättningar du behöver för att vara försiktig när du importerar MySQL-tabelldata och i den andra delen kommer vi att prata om hur du hanterar import för lagrade programobjekt och vyer.

1. Utrymmeskrav

För det första är det viktigt att se till att din destinationsdatabasvolym har tillräckligt med utrymme för att lagra importerad data. Specifikt måste du vara försiktig om binära loggar är aktiverade på din destinations MySQL-databas, eftersom binära loggar som genereras vid import av data kan vara nästan lika stora som själva data. Binära loggar behövs om du vill återställa din data på en server och vill att den ska replikeras. I sådana fall är det en bra idé att planera destinationsstorleken större än dubbelt så stor som källdatabasen.

Det är också viktigt att se till att det finns tillräckligt med utrymme på volymen där du genererar utdatafilen mysqldump. Utan dessa försiktighetsåtgärder kan du se din dumpning eller återställning misslyckas på grund av otillräckligt utrymme efter att ha kört under en längre tid, vilket är en förlust av din produktiva tid och ansträngning.

2. SQL_mode

sql_mode-inställningar för MySQL-server bestämmer SQL-satssyntaxen och datavalideringskontroller som servern utför för operationerna. Det är viktigt att säkerställa sql_mode käll- och destinationsservrar är kompatibla med varandra, eller så kan du stöta på fel när du återställer dumpen du har tagit. Låt oss demonstrera detta med ett exempel.

Säg att du har en tabell på din källa som har en datumkolumn med poster som noll datum:

mysql> visa skapa tabellschema;---------------------------------------- ----------------+| Tabell | Skapa tabell |------------------------------------------------------ ----------+| schema | SKAPA TABELL `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin1 |+-------+---------- -------------------------------------------------- -------------------------------------------------- -------mysql> välj * från schemat;+------+------+| id | ts |+------+------------+| 1 | 2020-01-12 || 2 | 0000-00-00 |+------+------------+

Anta att det strikta sql_mode (och NO_ZERO_DATE ) är inaktiverad på källan, men aktiverad på destinationen – återställning av sådana rader kommer att resultera i misslyckanden som:

ERROR 1292 (22007) på rad 40:Felaktigt datumvärde:'0000-00-00' för kolumn 'ts'' på rad 2

Du kommer vanligtvis att se sådana problem om du tar en kompakt dumpning genom att aktivera alternativet kompakt som en del av din mysqldump.

Om compact är inaktiverat (vilket är som standard) kommer du inte att möta det här problemet eftersom mysqldump genererar följande villkorliga uttalande som en del av dumpen:

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

Detta betyder att sql_mode under återställningen är inställd på 'NO_AUTO_VALUE_ON_ZERO' innan du återställer tabelldata, så återställningen går bra.

3. Unique_checks och foreign_key_checks

Som standard (om du inte använder alternativet –compact), ställer mysqldump även in följande:

/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKSpre> 
Som förklarat här kan du påskynda återställningen genom att tillfälligt stänga av unikhetskontrollerna under sessionen. För stora tabeller sparar detta mycket disk I/O eftersom InnoDB kan använda sin ändringsbuffert för att skriva sekundära indexposter i en batch.
 
Om du har FOREIGN KEY begränsningar i dina tabeller kan du påskynda tabellåterställningsoperationen genom att stänga av kontrollerna av främmande nyckel under återställningssessionens varaktighet:För stora tabeller kan detta spara mycket disk I/O.
 
Inaktiverar FOREIGN_KEY_CHECKS kommer också att hjälpa till att undvika fel på grund av kontroller av utländska nyckelbegränsningar under återställningsoperationen. Närhelst en tabell med foregin-nyckel-begränsning skapas, förväntar MySQL att den överordnade tabellen som refereras till av foregin-nyckeln redan existerar. Detta är ett problem eftersom mysqldump-verktyget dumpar tabellerna i alfabetisk ordning. Låt oss ta ett exempel för att visa detta.
 
I källdatabasen har vi två tabeller:
 
SKAPA TABELL `lösningstabell` ( `num1` int(11) INTE NULL, `num2` int(11) DEFAULT NULL, PRIMÄRKEY (`num1`));SKAPA TABELL `ref_table` ( `nyckel` int(11) ) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`))
 
Tabell ref_table har en främmande nyckel-begränsning som refererar till solution_table . Baserat på den alfabetiska ordningen dumpar mysqldump först innehållet i ref_table . När detta spelas upp igen vid tidpunkten för återställning, kommer det att misslyckas med felet:
 
FEL 1215 (HY000) på rad 50:Kan inte lägga till en främmande nyckel-begränsning - 
 
Vilket händer när man kör satsen create table för ‘ref_table’ .
 
I sammanfattning, var medveten om de problem du kan stöta på, om du anger --compact alternativet när du kör mysqldump.
 
4. Behörigheter krävs för att köra mysqldump
 
Minsta behörighet som krävs av mysqldump för att dumpa en databas är SELECT på den databasen.
 
Men om din databas har vyer behöver du SHOW VIEW-behörigheter också, eftersom mysqldump alltid dumpar vyer tillsammans med tabellerna i databasen. Anta att du inte har SHOW VIEW behörigheter, då misslyckas mysqldump med:
 
 mysqldump:Kunde inte köra 'show create table `ivew'':SHOW VIEW-kommandot nekades användaren 'dumpuser'@'172.31.18.79' för tabellen 'iview' (1142)
 
En annan intressant plats är om din dumpuser har SELECT behörigheter endast för en viss tabell i databasen, kommer mysqldump att dumpa data endast för den specifika tabellen och ignorerar automatiskt alla andra tabeller eller vyer.
 
Så se till att användaren som kör mysqldump har alla lämpliga privilegier i förväg för att undvika överraskningar eller misslyckanden vid ett senare tillfälle.
 
 
 
 
Intresserad av en fullt hanterad MySQL-lösning?
 

 För att lära dig mer om hur en DBaaS-leverantör som ScaleGrid kan hjälpa dig att hantera dina MySQL-databaser, kolla in vår MySQL-sida. Se hur ScaleGrid kan låta dig fokusera mer på att utveckla din produkt och mindre på att hantera databaser.
 

 
 
 
 
 
 
 
 
 
5. Max_allowed_packet
 
Det största kommunikationspaketet som hanteras av mysql bestäms av inställningen max_allowed_packet . I samband med import är ett kommunikationspaket en enda SQL-sats som skickas till MySQL-servern under återställningen ELLER en enda rad som skickas till klienten under dumpningen.
 
Standardvärdet för max_allowed_packet för mysqldump är 24MB. om mysqldump tar emot ett paket som är större än detta, kan du stöta på felet:
 
mysqldump:Fel 2020:Fick paket större än 'max_allowed_packet'-byte när tabell 'huge1' dumpades på rad:2.
 
Se till att mysqldump använder samma eller större värde för max_allowed_packet som är konfigurerad på MySQL-källinstansen.
 
Alternativet kan anges med flaggan --max-allowed-packet=value när du anropar mysqldump.
 
När du återställer dumpen, se till att max_allowed_packet storleken på din destinationsserver är tillräckligt stor för att ta emot paketen från dumpfilen.
 
Annars kommer du att se ett felmeddelande under återställningen av dumpen:
 
FEL 2006 (HY000) på rad 70:MySQL-servern har försvunnit
 
Det här felet kan vara lite missvisande eftersom du kanske tror att MySQL-servern har stängts av eller kraschat. Men det betyder bara att servern har fått ett större paket än dess konfigurerade storlek max_allowed_packet . Återigen, bästa praxis är att se till att max_allowed_packet värdet för din destinationsserver är detsamma som värdet i källservern. Detta är också en viktig inställning som kan kontrolleras och ställas in på lämpligt sätt i förväg, snarare än att möta felen vid ett senare tillfälle.
 
I den här första delen av mysqldump-serien diskuterade vi förutsättningarna för en framgångsrik dumpnings- och återställningsoperation för stora MySQL-databaser för att hjälpa dig undvika flera försök och improduktiv tid.
 
I nästa del kommer vi att diskutera bästa praxis för att importera de lagrade programmen och vyerna från din MySQL-databas.