Wie kann ich einen mysqldump einer großen Datenbank optimieren?

Ich habe eine Symfony-Anwendung mit einer InnoDB-Datenbank von ~ 2 GB mit 57 Tabellen. Der Großteil der Größe der Datenbank befindet sich in einer einzelnen Tabelle (~ 1,2 GB). Ich verwende derzeit mysqldump, um die Datenbank jede Nacht zu sichern.

Aufgrund meiner Comcast-Verbindung tritt bei der manuellen Ausführung eines Speicherauszugs häufig eine Zeitüberschreitung für die Verbindung zum Server auf, bevor der Speicherauszug vollständig ist, sodass ich den Speicherauszug erneut ausführen muss. [Ich führe derzeit einen Cron aus, der den Dump jede Nacht ausführt. Dies gilt nur für Dumps, die ich manuell ausführe.]

Gibt es eine Möglichkeit, die Speicherauszüge für das Problem des Verbindungszeitlimits zu beschleunigen, aber auch die Zeit zu begrenzen, die der Server mit diesem Prozess beschäftigt ist?

Übrigens arbeite ich derzeit daran, die Größe der gesamten Datenbank zu verringern, um dieses Problem zu beheben.

Der größte Engpass in diesem Speicherauszug ist die Laufwerk-E / A. Sie lesen eine Menge Daten und schreiben sie erneut. Sie können dies auf verschiedene Arten beschleunigen:

• Vergewissern Sie sich, dass Ihre Ausgabe auf einem anderen Laufwerk als dem oder den anderen Laufwerken abgelegt ist, auf denen die Datenbankdateien gespeichert sind. Dies macht einen großen Unterschied bei sich drehenden Festplatten, da die Laufwerksköpfe nicht ständig zwischen den Speicherorten wechseln und der Ort, an den geschrieben wird.
• Die Ausgabe von mysqldump ist sehr komprimierbar. Wenn Sie also die Ausgabe nicht wie oben erwähnt von der Eingabe trennen können, leiten Sie die Ausgabe durch gzipoder ähnliches. Dies reduziert den Umfang des Schreibvorgangs (also die gesamte E / A-Last und die Kopfbewegung) auf Kosten einiger CPU-Zeit (die Sie zu diesen Zeiten ohnehin möglicherweise viel Zeit sparen).
• Leiten Sie die Ausgabe (auch oder anstelle der Komprimierung) durch ein Pipe-Dienstprogramm (wie pv ), das große Schreibpuffer unterstützt, um die auf die Laufwerke geschriebenen Blöcke stärker zu gruppieren, um den Effekt der Latenz bei Kopfbewegungen zu verringern ein ziemlicher Unterschied, wenn Sie die --quickOption verwenden, um den RAM-Effekt beim Sichern großer Tabellen zu verringern.
• Führen Sie Ihren Sicherungsvorgang nur aus, wenn die E / A-Last ansonsten niedrig ist.

Möglicherweise beheben Sie jedoch das falsche Problem: Möglicherweise ist es einfacher, die Verbindungsabbrüche zu beheben (wenn Sie jedoch die durch Ihre Sicherungen verursachte E / A-Belastung verringern, können Sie die Auswirkungen auf andere Benutzer verringern. Daher lohnt es sich, es trotzdem zu versuchen). Könnten Sie Ihre manuellen Sicherungen über den Bildschirm (oder ähnliche Tools wie tmux ) ausführen ? Auf diese Weise können Sie, wenn Ihre Verbindung zum Server screenunterbrochen wird , die Verbindung zur Sitzung wiederherstellen, ohne dass Prozesse unterbrochen werden.

Wenn Sie die Daten direkt über die Verbindung senden (dh Sie führen mysqldump auf Ihrem lokalen Computer für eine entfernte Datenbank aus, sodass der Speicherauszug lokal angezeigt wird), ist es möglicherweise besser, den Speicherauszug zuerst auf dem Server auszuführen, nach Bedarf zu komprimieren und dann zu übertragen die Daten über das Netzwerk mithilfe eines Tools (z. B. rsync), das teilweise Übertragungen unterstützt, sodass Sie die Übertragung fortsetzen können (anstatt sie neu zu starten), wenn ein Verbindungsabbruch die Übertragung unterbricht.

Als Teil Ihrer "Verringerung der Größe der Gesamtdatenbank, um dieses Problem zu beheben" würde ich vermuten, dass sich ein großer Teil Ihrer Daten nicht ändert. Möglicherweise können Sie einen großen Teil der 1,2 GB von dieser Haupttabelle in eine andere verschieben und diesen Teil von denjenigen entfernen, die durch den mysqldumpAufruf kopiert wurden . Sie müssen diese Daten nicht jedes Mal sichern, wenn sie sich nie ändern. Das Aufteilen von Daten zwischen Tabellen und Datenbanken auf diese Weise wird normalerweise als Datenpartitionierung bezeichnet und ermöglicht es Ihnen, die Daten- und E / A-Last auf mehrere Laufwerke zu verteilen. High-End-Datenbanken unterstützen die automatische Partitionierung. In MySQL müssen Sie dies jedoch möglicherweise manuell tun und die Datenzugriffsebene ändern, um dies zu berücksichtigen.

Nicht zum Thema gehörend für diese Site (daher sollten Sie sich wahrscheinlich an ServerFault oder SuperUser wenden, um zu fragen, ob Sie weitere Details benötigen): Wenn Sie aufgrund von Inaktivität Verbindungen verlieren, überprüfen Sie die zu treffenden Optionen in Ihrem SSH-Server und SSH-Client Stellen Sie sicher, dass Keep-Alive-Pakete aktiviert sind und häufig genug gesendet werden. Wenn Sie feststellen, dass die Verbindung unterbrochen wird, obwohl die Verbindung aktiv ist, können Sie auch OpenVPN oder ähnliches verwenden, um die Verbindung zu bündeln. Es sollte eine kurze Unterbrechung behandelt werden, auch eine vollständige Unterbrechung, wenn die gesamte Verbindung für einige Sekunden unterbrochen ist, so dass der SSH-Client und Server merkt es nicht.

EINBLICK IN DIE DURCHFÜHRUNG VON BACKUPS MIT mysqldump

IMHO Backups zu machen ist mehr eine Kunstform geworden, wenn man nur weiß, wie man damit umgeht

Sie haben Optionen

Option 1: mysqldump eine gesamte mysql-Instanz

Dies ist der einfachste, der Kinderspiel !!!

mysqldump -h... -u... -p... --hex-blob --routines --triggers --all-databases | gzip > MySQLData.sql.gz

Alles in einer Datei geschrieben: Tabellenstrukturen, Indizes, Trigger, gespeicherte Prozeduren, Benutzer, verschlüsselte Passwörter. Andere mysqldump-Optionen können auch verschiedene Stile von INSERT-Befehlen, Protokolldateien und Positionskoordinaten aus Binärprotokollen, Datenbankerstellungsoptionen, Teildaten (Option --where) usw. exportieren.

Option 2: mysqldump separate Datenbanken in separate Datendateien

Beginnen Sie mit der Erstellung einer Liste von Datenbanken (2 Techniken, um dies zu tun)

Technik 1

mysql -h... -u... -p... -A --skip-column-names -e"SELECT schema_name FROM information_schema.schemata WHERE schema_name NOT IN ('information_schema','mysql')" > ListOfDatabases.txt

Technik 2

mysql -h... -u... -p... -A --skip-column-names -e"SELECT DISTINCT table_schema FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql')" > ListOfDatabases.txt

Technik 1 ist der schnellste Weg. Technik 2 ist die sicherste und sicherste. Technik 2 ist besser, da Benutzer manchmal Ordner für allgemeine Zwecke in / var / lib / mysql (datadir) erstellen, die nicht datenbankbezogen sind. Das Informationsschema würde den Ordner als Datenbank in der Tabelle information_schema.schemata registrieren. Technik 2 würde Ordner umgehen, die keine MySQL-Daten enthalten.

Sobald Sie die Liste der Datenbanken kompiliert haben, können Sie die Liste in einer Schleife durchlaufen und sie auf Wunsch auch parallel mit mysqldump sichern.

for DB in `cat ListOfDatabases.txt`
do
    mysqldump -h... -u... -p... --hex-blob --routines --triggers ${DB} | gzip > ${DB}.sql.gz &
done
wait

Wenn zu viele Datenbanken gleichzeitig gestartet werden können, sichern Sie diese 10 gleichzeitig:

COMMIT_COUNT=0
COMMIT_LIMIT=10
for DB in `cat ListOfDatabases.txt`
do
    mysqldump -h... -u... -p... --hex-blob --routines --triggers ${DB} | gzip > ${DB}.sql.gz &
    (( COMMIT_COUNT++ ))
    if [ ${COMMIT_COUNT} -eq ${COMMIT_LIMIT} ]
    then
        COMMIT_COUNT=0
        wait
    fi
done
if [ ${COMMIT_COUNT} -gt 0 ]
then
    wait
fi

Option 3: mysqldump separate Tabellen in separate Datendateien

Beginnen Sie mit der Erstellung einer Tabellenliste

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT(table_schema,'.',table_name) FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql')" > ListOfTables.txt

Dann geben Sie alle Tabellen in 10er-Gruppen aus

COMMIT_COUNT=0
COMMIT_LIMIT=10
for DBTB in `cat ListOfTables.txt`
do
    DB=`echo ${DBTB} | sed 's/\./ /g' | awk '{print $1}'`
    TB=`echo ${DBTB} | sed 's/\./ /g' | awk '{print $2}'`
    mysqldump -h... -u... -p... --hex-blob --triggers ${DB} ${TB} | gzip > ${DB}_${TB}.sql.gz &
    (( COMMIT_COUNT++ ))
    if [ ${COMMIT_COUNT} -eq ${COMMIT_LIMIT} ]
    then
        COMMIT_COUNT=0
        wait
    fi
done
if [ ${COMMIT_COUNT} -gt 0 ]
then
    wait
fi

Option 4: NUTZEN SIE IHRE FANTASIE

Probieren Sie Variationen der oben genannten Optionen und Techniken für saubere Schnappschüsse aus

Beispiele

1. Ordnen Sie die Liste der Tabellen nach der Größe der einzelnen Tabellen auf- oder absteigend.
2. Führen Sie in einem separaten Prozess "FLUSH TABLES WITH READ LOCK; SELECT SLEEP (86400)" aus, bevor Sie mysqldumps starten. Beenden Sie diesen Vorgang, nachdem mysqldumps abgeschlossen ist. Dies ist hilfreich, wenn eine Datenbank sowohl InnoDB als auch MyISAM enthält
3. Speichern Sie die mysqldumps in datierten Ordnern und drehen Sie alte Sicherungsordner heraus.
4. Laden Sie die gesamte Instanz von mysqldumps auf eigenständige Server.

VORBEHALT

Nur Option 1 bringt alles. Der Nachteil ist, dass mysqldumps, die auf diese Weise erstellt wurden, nur in dieselbe Majot-Release-Version von mysql zurückgeladen werden können, die der mysqldump generiert hat. Mit anderen Worten, ein mysqldump aus einer MySQL 5.0-Datenbank kann in 5.1 oder 5.5 nicht geladen werden. Der Grund ? Das MySQL-Schema unterscheidet sich grundlegend zwischen den Hauptversionen.

In den Optionen 2 und 3 werden keine Benutzernamen und Kennwörter gespeichert.

Hier ist die allgemeine Möglichkeit, die SQL-Berechtigungen für Benutzer zu sichern, die lesbar und portabler sind

mysql -h... -u... -p... --skip-column-names -A -e"SELECT CONCAT('SHOW GRANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user<>''" | mysql -h... -u... -p... --skip-column-names -A | sed 's/$/;/g' > MySQLGrants.sql

Option 3 speichert die gespeicherten Prozeduren nicht, daher können Sie Folgendes tun

mysqldump -h... -u... -p... --no-data --no-create-info --routines > MySQLStoredProcedures.sql &

Ein weiterer Punkt, der beachtet werden sollte, betrifft InnoDB. Wenn Sie über einen großen InnoDB-Pufferpool verfügen, ist es sinnvoll, diesen so gut wie möglich zu leeren, bevor Sie Sicherungen durchführen. Andernfalls verbringt MySQL die Zeit damit, Tabellen mit verbliebener Dirty Page aus dem Pufferpool zu leeren. Folgendes schlage ich vor:

Führen Sie diesen SQL-Befehl ca. 1 Stunde vor der Durchführung der Sicherung aus

SET GLOBAL innodb_max_dirty_pages_pct = 0;

In MySQL 5.5 beträgt der Standardwert für innodb_max_dirty_pages_pct 75. In MySQL 5.1 und früheren Versionen beträgt der Standardwert für innodb_max_dirty_pages_pct 90. Wenn Sie innodb_max_dirty_pages_pct auf 0 setzen, beschleunigt dies das Leeren von fehlerhaften Seiten auf die Festplatte. Dies verhindert oder mindert zumindest die Auswirkungen der Bereinigung unvollständiger zweiphasiger Festschreibungen von InnoDB-Daten, bevor ein mysqldump für InnoDB-Tabellen ausgeführt wird.

LETZTES WORT ZU mysqldump

Die meisten Leute scheuen mysqldump zugunsten anderer Tools und diese Tools sind in der Tat gut.

Solche Werkzeuge umfassen

1. Maatkit (parallel Dump / Restore - Skripts von Percona [veraltet , aber groß])
2. XtraBackup (TopNotch Snapshot Backup von Percona)
3. CDP R1Soft ( MySQL- Moduloption , die Momentaufnahmen macht)
4. MySQL Enterprise Backup (früher InnoDB Hot Backups [kommerziell])

Wenn Sie den Geist eines echten MySQL-DBAs haben, können Sie mysqldump annehmen und die vollständige Beherrschung darüber erlangen, die erreicht werden kann. Mögen alle Ihre Backups ein Spiegelbild Ihrer Fähigkeiten als MySQL-DBA sein .

Schauen Sie sich MySQL Replication Master to Slave an. Hiermit können Sie die Datenbank des Masters auf einen anderen Datenbankserver mit derselben Datenbank klonen. Dies schließt die Master- und Slave-Identität ein. Slave macht sich die exakte Kopie des Master-Datenbankservers und / oder seiner Datenbanken. Es kann eine Eins-Eins-Eins-Viele-Viele-Eins-Beziehung zwischen Master (s) und Slave (s) geben.

Der Slave liest kontinuierlich das Binärprotokoll am Master ( das Binärprotokoll speichert die auf dem Master-Datenbankserver geschriebenen Abfragen) und erhält Eingaben an den Slave-Datenbankserver. (Dies bedeutet, dass Ihre Master-Datenbank überhaupt nicht betroffen ist.)

Die gute Nachricht ist, dass es Ihren MySQL-Server nicht zu sehr beeinträchtigt, da Sie keine Ausfallzeiten oder langsamen Abfrageantworten bemerken. Wir verwenden es für 10-Gbit-Datenbanken und es funktioniert wie ein Zauber ohne Ausfallzeiten.

MySQL-Replikation auf demselben Computer

Plan A: Siehe auch Xtrabackup von Percona. Dies ermöglicht die Online-Sicherung von InnoDB ohne nennenswerte Sperrung.

Plan B: Ein Slave kann gestoppt werden, und Sie können auf verschiedene Weise eine konsistente Sicherung durchführen (Dateien kopieren, mysqldump, xtrabackup usw.).

Plan C: LVM-Snapshot. Nach einigen kryptischen Einstellungen beträgt die Ausfallzeit für eine Sicherung weniger als eine Minute, unabhängig von der Größe der Datenbank. Sie stoppen mysqld, erstellen den Snapshot, starten mysqld neu und kopieren dann den Snapshot. Der letzte Schritt kann lange dauern, aber MySQL ist nicht inaktiv.

Plan D: Momentaufnahme eines Slaves - keine Ausfallzeit.

Ein paar Admin-Punkte zuerst: Stellt ihr eine Verbindung zu einem FTP her oder seid ihr eingeschüchtert und es stirbt? Wenn ssh, stellen Sie sicher, dass Sie den Bildschirm verwenden, damit Sie nach dem Absturz des Comcasts fortfahren können. Wenn ftp, dann stellen Sie sicher, dass Sie es / tar vor dem Senden komprimieren.

Probieren Sie auch den Parameter --opt oder --quick aus

--opt Mit dieser Option werden eine Reihe zusätzlicher Optionen aktiviert, um die Sicherungs- und Nachladeoperationen effizienter zu gestalten. Insbesondere entspricht dies der gemeinsamen Verwendung der Optionen --add-drop-table, --add-locks, --all, --quick, --extended-insert, --lock-tables und --disable-keys. Beachten Sie, dass diese Option dazu führt, dass die Ausgabe weniger portabel ist und von anderen Datenbanksystemen weniger verstanden wird.

--quick Mit dieser Option wird mysqldump angewiesen, beim Lesen jeder Zeile vom Server eine Sicherungsausgabe zu schreiben. Dies kann bei großen Tabellen hilfreich sein. Standardmäßig liest mysqldump alle Zeilen aus einer Tabelle in den Speicher, bevor die Ausgabe geschrieben wird. Bei großen Tabellen ist hierfür viel Speicher erforderlich, wodurch der Speicherauszug möglicherweise fehlschlägt.

Ich hatte auch Probleme mit Zeitüberschreitungen beim Speichern großer Datenbanken. Ich habe es endlich gelöst, indem ich einzelne Befehle für jede Tabelle in der Datenbank gesendet und alles wie folgt an eine Datei angehängt habe:

TABLES=`mysql -u $USER -p$PWD -Bse 'show tables' $DB`
for TABLE in $TABLES
do
    mysqldump -u $USER -p$PWD $DB $TABLE >> dump.sql
done

Ich denke, die Frage ist, wie aus den von mysqldump erstellten Dump-Dateien schneller wiederhergestellt werden kann, nicht aus einer anderen Backup-Lösung.

Eine Möglichkeit besteht darin, Tabellengruppen in Ihrem Schema zu erstellen und für jede Gruppe einen eigenen DB-Benutzer zu erstellen. Anschließend können Sie mithilfe der MySQL-Berechtigungen festlegen, dass Tabellen nur mit einem DB-Benutzer eingefügt werden dürfen.

Dies ist eine bewährte, schnelle, fast parallele Technik, die jedoch nicht hundertprozentig sicher ist, wie lange es dauern wird, bis große Dumps wie etwa 500 G wiederhergestellt sind. Aber meiner bescheidenen Meinung nach brauchen Sie etwas Paralleles. Überprüfen Sie den Link unten für ein Beispiel.

[Schnelle, parallele Wiederherstellung von SQL-Dumps (mysqldump) für MySQL] [1]

http://geeksww.com/tutorials/database_management_systems/mysql/tips_and_tricks/fast_parallel_restore_from_sql_dumps_mysqldump_for_mysql.php

"Schnelle, parallele Wiederherstellung von SQL-Dumps (mysqldump) für MySQL"