Detaillierte Erläuterung der Wissenspunkte zur Echtzeitsicherung der MySQL-Datenbank

Vorwort

Der Bedarf an Echtzeit-Datenbanksicherungen ist weit verbreitet. MySQL selbst bietet einen Replikationsmechanismus. Die offizielle Einführung lautet wie folgt:

MySQL Replication kann Daten von einer Masterdatenbank mit einer oder mehreren Slavedatenbanken synchronisieren. Und dieser Synchronisierungsprozess funktioniert standardmäßig asynchron, und es besteht keine Notwendigkeit, eine Echtzeitverbindung zwischen der Master- und der Slave-Datenbank aufrechtzuerhalten (d. h. Verbindungsunterbrechungen sind zulässig). Es ermöglicht auch die benutzerdefinierte Konfiguration von Datenbanken und Datentabellen, die synchronisiert werden müssen.

Die Vorteile und Anwendungsszenarien der MySQL-Replikation sind wie folgt:

1. Verwenden Sie MySQL Replication, um einen Lastenausgleich und eine Trennung von Lesen und Schreiben zu erreichen (die Master-Datenbank wird nur aktualisiert und die Slave-Datenbank nur gelesen), um die Datenbankleistung zu verbessern.

2. Zur Gewährleistung der Datensicherheit wird eine Echtzeit-Datensicherung durch MySQL-Replikation erreicht.

3. Implementieren Sie eine Offline-Datenanalyse durch MySQL-Replikation (die Masterdatenbank generiert Daten und die Analyse und Berechnung der Slavedatenbank hat keinen Einfluss auf die Leistung der Masterdatenbank).

4. Datenverteilung.

Die vollständige offizielle Dokumentation zur MySQL-Replikation finden Sie unter: https://dev.mysql.com/doc/refman/5.7/en/replication.html

So funktioniert es

1111

1. Alle Datenbankänderungsereignisse im Master werden in die Binärprotokolldatei geschrieben

2. Wenn der Befehl „SLAVE START“ im Slave ausgeführt wird, wird der Slave I/O Thread gestartet und mit dem Master verbunden

3. Der Master erkennt die Verbindung des Slave-E/A-Threads und öffnet den Log Jump Thread, um zu antworten

4. Das Master-Binärprotokoll wird über den Master-Log-Jump-Thread und den Slave-E/A-Thread an das Slave-Relay-Protokoll übertragen.

5. Der Slave-SQL-Thread stellt das Relay-Protokoll wieder her und die Synchronisierung ist abgeschlossen.

Hinweis: Mit dem Befehl „SHOW PROCESSLIST“ können Sie den Ausführungsstatus der entsprechenden Threads im Master und Slave anzeigen.

Konfigurieren des Masters

Aktivieren Sie das Binärprotokoll und legen Sie die Server-ID fest. Die Server-ID muss eindeutig sein und kann im Bereich von 1 bis 232-1 liegen.

[mysqld]
# Binärprotokoll aktivieren
log-bin=mysql-bin
# Festlegen der globalen ID
Server-ID = 1

# Geben Sie die zu synchronisierenden Datenbanken an (da der Datenbankname Kommas enthalten kann, müssen mehrere Datenbanken mehrfach konfiguriert werden, anstatt sie durch Kommas zu trennen)
binlog-do-db=Datenbankname
#Geben Sie die Datenbank an, deren Synchronisierung nicht zulässig ist. binlog-ignore-db=database_name
# Binärprotokollformat angeben binlog_format=MIXED

Erstellen eines Synchronisierungskontos

Da jeder Slave ein Konto und ein Kennwort benötigt, um eine Verbindung mit der Masterdatenbank herzustellen, muss in der Masterdatenbank ein Konto bereitgestellt werden. Es wird empfohlen, ein unabhängiges Konto zu verwenden und nur Berechtigungen zur Datensynchronisierung zu autorisieren.

ERSTELLEN SIE BENUTZER 'repl'@'%.example.com' IDENTIFIZIERT DURCH 'Passwort';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';

Abrufen von Binärprotokollinformationen

Wenn der Slave den E/A-Thread startet, muss er einige Informationen aus dem Binärprotokoll übergeben. Daher ist es notwendig, die folgenden Binärprotokollinformationen abzurufen:

MASTER-STATUS ANZEIGEN;

Führen Sie den Befehl SHOW MASTER STATUS aus, um Informationen zum Binärprotokoll abzurufen und die Werte der Felder „Datei“ und „Position“ aufzuzeichnen.

Stellen Sie vor der Synchronisierung sicher, dass die Daten von Master und Slave konsistent sind

Bevor der Slave den E/A-Thread startet, muss sichergestellt werden, dass die Daten von Master und Slave konsistent sind. Daher wird der Master zuerst gesperrt (um Datenänderungen zu verhindern) und dann nach Sicherstellung der Datenkonsistenz manuell synchronisiert und entsperrt.

FLUSH-TABELLEN MIT LESE-SPERRE;

Vorgänge im Zusammenhang mit der manuellen Datensynchronisierung werden kurz beschrieben …

TABELLEN ENTSPERREN;

Slave konfigurieren

Um die Server-ID festzulegen, müssen Sie BinLog nicht aktivieren:

[mysqld]
# Festlegen der globalen ID
Server-ID = 2

# Geben Sie die synchronisierte Datenbank an replicate-do-db=database_name
#Geben Sie die Datenbank an, die nicht synchronisiert werden darf replicate_ignore_db=database_name

Um die Master-Informationen festzulegen, führen Sie den folgenden Befehl aus:

mysql> ÄNDERN SIE MASTER IN
  -> MASTER_HOST='Name_des_Masterhosts',
  -> MASTER_PORT='Master-Host-Port',
  -> MASTER_USER='Replikationsbenutzername',
  -> MASTER_PASSWORD = 'Replikationspasswort',
  -> MASTER_LOG_FILE='aufgezeichneter_Protokolldateiname',
  -> MASTER_LOG_POS=aufgezeichnete_Logposition;

E/A-Thread starten

SLAVE STARTEN;

Überprüfen Sie den Synchronisierungsstatus:

SLAVE-STATUS ANZEIGEN;

Binlog_Format-Parameter des Masters

binlog_format wird zum Konfigurieren des Formats des Binärprotokolls verwendet und unterstützt die folgenden drei Typen:

Reihe

Änderungen basierend auf Datenzeilen aufzeichnen. Dieser Modus hat nichts mit SQL-Anweisungen, gespeicherten Prozeduren, Funktionen, Triggern usw. zu tun. Es ist nur wichtig, ob sich die Daten in jeder Zeile geändert haben. Wenn dies der Fall ist, wird dies aufgezeichnet. Daher hat der Zeilenmodus die höchste Genauigkeit. Der Nachteil besteht jedoch darin, dass dadurch in manchen Fällen sehr viel Inhalt generiert wird und die Effizienz sinkt, beispielsweise wenn sich die Tabellenstruktur ändert.

Stellungnahme

Die Aufzeichnung per SQL-Anweisung behebt offensichtlich die Mängel des Zeilenmodus, das Problem besteht jedoch darin, dass die Genauigkeit nicht hoch genug ist, da SQL-Anweisungen sehr komplex sein können und zu unerwarteten Situationen neigen.

Gemischt

Gemischter Zeilen- und Anweisungsmodus: MySQL entscheidet automatisch, wann Zeilen und wann Anweisungen verwendet werden. Dies ist auch der Standardmodus.

Hinweise zu „Replicate-do-db“

Wenn Sie die Konfigurationselemente replicate-do-db und replicate-ignore-db im Slave verwenden, beachten Sie bitte, dass SQL-Anweisungen zwischen Datenbanken nicht synchronisiert werden, wie zum Beispiel:

replizieren-do-db=a
benutze b;
Aktualisiere a.some_table, setze some_field = 'einiger Wert';

Die Lösung besteht darin, replicate_wild_do_table und replicate_wild_ignore_table zu verwenden, etwa:

replicate_wild_do_table=Datenbankname.%
replicate_wild_ignore_table=Datenbankname.%