Ich bereite die Einrichtung einer MySQL-Master-Slave- oder Master-Master-Beziehung vor. Im Moment habe ich einen einzelnen MySQL-Produktionsserver und möchte natürlich nicht zu viele Ausfallzeiten, während ich den Slave verbinde.
Gibt es keine Möglichkeit, einen leeren Slave anzuschließen und ihn die Daten „langsam“ vom Master synchronisieren zu lassen, bis sie identisch sind?
Mir ist aufgefallen, dass ich mit mysqldump einen Transaktionsdump auf dem Master erstellen und diesen dann in den Slave importieren kann. Bis der Slave den Dump importiert hat, sind jedoch bereits viele neue Zeilen geschrieben. Und wie erhält der Slave diese?
Ich hoffe, ich übersehe hier etwas Offensichtliches, aber wenn man ausgiebig googelt, erhält man Ratschläge wie: „Da dies in Zukunft zu weniger Ausfallzeiten führt, sind einige Ausfallzeiten jetzt vielleicht gar nicht so schlimm.“ Aber das würde ich wirklich gerne vermeiden.
VerwandtFrage zu MyISAM, aber ich verwende InnoDB.
Antwort1
Wenn Sie 100% InnoDB verwenden, haben Sie Glück. Sie können verwendenXtraBackupum eine vollständige Sicherung Ihrer Masterdatenbank ohne Ausfallzeiten oder Tabellensperren zu erstellen. Dies ist eine konsistente Sicherung im Snapshot-Stil, die gleiche Art, die Sie erhalten, wenn Sie die Optionen FLUSH TABLES WITH READ LOCKoder verwenden --master-data.
Das Tool XtraBackup legt außerdem eine zusätzliche Datei im Sicherungsverzeichnis ab, die die MASTER_LOG_POS- und MASTER_LOG_FILE-Informationen enthält, die Sie zum Starten der Replikation auf dem Slave benötigen.
Wenn Sie mit der Sicherung fertig sind, müssen Sie die --prepareOption von XtraBackup für die Sicherung ausführen, sie in den Slave laden, den MySQL-Slave-Sicherungsprozess starten und ihm die neuen MASTER_LOG_POS- und MASTER_LOG_FILE-Werte mitteilen, die er benötigt.
Sie möchten dies skip-slave-startin Ihrer my.cnf, bevor Sie den Slave starten.
Bedenken Sie auch, dass das mysqlSchema standardmäßig MyISAM ist (und wenn ich mich recht erinnere, kann es nur MyISAM sein). Sie müssen also trotzdem darauf achten, während der Sicherung keine Änderungen an diesen Tabellen vorzunehmen. Solange Sie sich an diese Regel halten, sind die Stamminformationen weiterhin korrekt.
Es ist oft eine gute Idee,Ignorieren Sie das mysqlSchema in Ihrer my.cnfauf dem Slave und erstellen Sie immer nur Benutzer mit SELECT-Berechtigungen. Inkonsistente und nicht synchronisierte Slaves sind schwer zu erkennen und mühsam zu handhaben, selbst wenn Sie die Tools verwenden, die Percona (und zuvor Maatkit) hierfür bereitstellen.
Bearbeiten:
Obwohl Sie sagten, dass Sie InnoDB verwenden, gibt es der Vollständigkeit halber noch eine andere Möglichkeit, wenn Sie MyISAM-Tabellen verwenden. Wenn Sie einen Volume-Manager mit Snapshotting haben (wie z. B.ZFSoderLVM), können Sie ein ausführen, FLUSH TABLES WITH READ LOCKgefolgt von einem SHOW MASTER STATUS, einen Snapshot erstellen und ausführen UNLOCK TABLES. Die Ausfallzeit sollte relativ gering sein. Zum Vergleich: Der Cron-Job letzte Nacht, der dies zum Sichern einer unserer Datenbanken durchgeführt hat, benötigte 6 Sekunden zum Erstellen des Snapshots (also der Zeit, in der die Datenbank „down“ ist) und 27 Minuten zum Kopieren der Dateien vom Snapshot auf den Backup-Server.
Antwort2
Es ist nicht möglich, eine MySQL-Replikation „von Grund auf“ zu starten.
Stattdessen können Sie --master-data=2beim Sichern Ihrer Datenbanken mysqldump mit dem Parameter verwenden, also etwa so:
mysqldump --master-data=2 --all-databases --opt -p > myinitialdump.sql
Dieser Befehl sperrt während des Dumps alle Tabellen in den betroffenen Datenbanken und schreibt die Replikationskoordinaten in auskommentierter Form wie folgt in den Header des Dumps:
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000018', MASTER_LOG_POS=106;
Nachdem der Import abgeschlossen ist, können Sie den Befehl „change master to“ manuell ausführen, ergänzt mit dem Hostnamen Ihres Masters und den Authentifizierungsdaten. Die Replikation wird dann am Punkt des Dumps gestartet.
Bitte beachten Sie, dass der mysqldump-Prozess aufgrund von Sperrkonflikten selbst „Ausfallzeiten“ verursacht – er setzt Lesesperren auf alle Tabellen (ähnlich wie der Befehl FLUSH TABLES WITH READ LOCK) für die gesamte Dauer des Dumps. Daher werden keine Schreibanforderungen an eine der Tabellen zurückgegeben, es sei denn, der Dump ist abgeschlossen. Außerdem würden die Schreibanforderungen wahrscheinlich auch alle nachfolgenden Leseanforderungen blockieren, sofern Sie nicht Folgendes angegeben haben:Updates mit niedriger Prioritätin Ihrer MySQL-Konfiguration oder haben Sie vor dem Dump SET GLOBAL LOW_PRIORITY_UPDATES=1 ausgegeben.