Automatiserad eller regelbunden säkerhetskopiering av mysql-data

CSV och VÄLJ IN TILL UTFIL

http://dev.mysql.com/doc/refman /5.7/en/select-into.html

SELECT ... INTO OUTFILE skriver de markerade raderna till en fil. Kolumn- och radavslutningar kan specificeras för att producera ett specifikt utdataformat.

Här är ett komplett exempel:

SELECT * FROM my_table INTO OUTFILE '/tmp/my_table.csv'
  FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
  LINES TERMINATED BY '\n'
  FROM test_table;

Filen sparas på servern och sökvägen som väljs måste vara skrivbar. Även om den här frågan kan köras via PHP och en webbförfrågan, körs den bäst via mysql-konsolen.

Data som exporteras på detta sätt kan importeras till en annan databas med LADDA DATAINFIL

Även om den här metoden är överlägsen att iterera genom en resultatuppsättning och spara till en fil rad för rad, är det inte lika bra som att använda...

mysqldump

mysqldump är överlägsen SELECT INTO OUTFILE på många sätt, att producera CSV är bara en av många saker som det här kommandot kan göra.

Klientverktyget mysqldump utför logiska säkerhetskopior och producerar en uppsättning SQL-satser som kan köras för att återskapa de ursprungliga databasobjektdefinitionerna och tabelldata. Den dumpar en eller flera MySQL-databaser för säkerhetskopiering eller överföring till en annan SQL-server. Mysqldumpcommand kan också generera utdata i CSV, annan avgränsad text eller XML-format.

Helst ska mysqldump anropas från ditt skal. Det är möjligt att använda exec i php för att köra det, men eftersom det kan ta lång tid att producera dumpen beroende på mängden data, och php-skript vanligtvis bara körs i 30 sekunder, skulle du behöva köra det som en bakgrundsprocess.

mysqldump är inte utan sin beskärda del av problem.

Det är inte tänkt som en snabb eller skalbar lösning för att säkerhetskopiera stora mängder data. Med stora datastorlekar, även om säkerhetskopieringen tar en rimlig tid, kan återställningen av data vara mycket långsam eftersom återuppspelning av SQL-satserna involverar disk I/O för insättning, indexskapande och så vidare.

Ett klassiskt exempel se denna fråga: Serverkrasch vid MySQL-säkerhetskopia med python där en mysqldump verkar starta innan den tidigare har avslutats och gjort att webbplatsen inte svarar helt.

Mysql-replikering

Replikering gör att data från en MySQL-databasserver (mastern) kan kopieras till en eller flera MySQL-databasservrar (slavarna). Replikering är asynkron som standard; slavar behöver inte vara permanentanslutna för att ta emot uppdateringar från mastern. Beroende på konfigurationen kan du replikera alla databaser, valda databaser eller till och med valda tabeller i en databas.

Således replikering fungerar annorlunda än SELECT INTO OUTFILE eller msyqldump Det är idealiskt att hålla data i den lokala kopian nästan uppdaterad (skulle ha sagt perfekt synkroniserad men det finns något som kallas slavlag) Å andra sidan om du använder en schemalagd uppgift för att köra mysqldump en gång var 24:e timme. Föreställ dig vad som kan hända om servern kraschar efter 23 timmar?

Varje gång du kör mysqldump producerar du en stor mängd data, fortsätt att göra det regelbundet och du kommer att upptäcka att din hårddisk är full eller att dina fillagringsräkningar slår i taket. Med replikering skickas endast ändringarna vidare till servern (genom att använda den så kallade binloggen)

XtraBackup

Ett alternativ till replikering är att använda Percona XtraBackup .

Percona XtraBackup är ett hot backup-verktyg med öppen källkod för MySQL-baserade servrar som inte låser din databas under säkerhetskopieringen.

Men av Percona är den kompatibel med Mysql och Mariadb. Den har förmågan att göra inkrementella säkerhetskopior i brist på vilket är den största begränsningen för mysqldump.