Detaillierte Analyse der MySQL Master-Slave-Replikation

Vorwort:

In MySQL sollte die Master-Slave-Architektur die grundlegendste und am häufigsten verwendete Architektur sein. Die anschließende Lese-/Schreibtrennung, die Multi-Active-Hochverfügbarkeitsarchitektur usw. basieren meist auf der Master-Slave-Replikation. Auch die Master-Slave-Replikation ist ein unverzichtbarer Teil unseres MySQL-Lernprozesses. Es gibt viele Artikel zur Master-Slave-Replikation. Ich möchte mich gerne an dem Spaß beteiligen und über diesen Aspekt schreiben und meine eigenen Erfahrungen und Methoden teilen.

1. Einführung und Prinzip der Master-Slave-Replikation

Master-Slave-Replikation (auch AB-Replikation genannt) bedeutet, dass ein Server als Master-Datenbankserver fungiert und ein oder mehrere andere Server als Slave-Datenbankserver. Die Daten auf dem Master-Server werden automatisch auf die Slave-Server kopiert. Bei der mehrstufigen Replikation kann ein Datenbankserver sowohl als Master als auch als Slave fungieren. MySQL verwendet standardmäßig asynchrone Replikation.

Der Ablauf und das Prinzip der Master-Slave-Replikation lassen sich wie folgt zusammenfassen:

1. Der Masterserver zeichnet Datenänderungen in einem Binärprotokoll auf. Wenn sich Daten auf dem Master ändern, werden die Änderungen in das Binärprotokoll geschrieben.
2. Der Slave-Server erkennt in einem bestimmten Zeitintervall, ob sich das Master-Binärprotokoll geändert hat. Wenn dies der Fall ist, startet er einen I/OThread, um das Master-Binärereignis anzufordern.
3. Gleichzeitig startet der Masterknoten einen Dump-Thread für jeden I/O-Thread, um ihm binäre Ereignisse zu senden und sie im lokalen Relay-Protokoll des Slaveknotens zu speichern. Der Slaveknoten startet den SQL-Thread, um das binäre Protokoll aus dem Relay-Protokoll zu lesen und es lokal wiederzugeben, damit seine Daten mit denen des Masterknotens übereinstimmen.

2. Konfigurieren Sie die Master-Slave-Replikation basierend auf dem Speicherort der Binärdatei

Die auf der Position der Binärdatei basierende Master-Slave-Replikation kann auch als herkömmliche Replikation bezeichnet werden. Das heißt, der Slave-Server hängt von der Position der Binärdatei des Master-Servers ab. Wenn sich die Daten in der Master-Datenbank ändern, erhöht sich die Position der Binärdatei, und die Slave-Datenbank erkennt die Änderung und schließt die Synchronisierung ab.

Um die Master-Slave-Replikation zu konfigurieren, müssen wir zunächst mindestens zwei MySQL-Instanzen vorbereiten, eine als Master-Server und eine als Slave-Server. Da die Master-Slave-Replikation von Binlog abhängt, muss Binlog in der Master-Datenbank aktiviert sein und Master und Slave müssen mit unterschiedlichen Server-IDs konfiguriert sein. Nachfolgend finden Sie eine detaillierte Beschreibung des Konfigurationsprozesses:

2.1 Bestätigen Sie die Konfigurationsparameter der Master-Slave-Bibliothek

Die folgende Konfiguration wird für den MySQL-Master-Slave-Server empfohlen. Sie können sie zunächst bestätigen. Wenn sie nicht konfiguriert ist, müssen Sie die Konfigurationsdatei ändern und neu starten.

# Die Parameterkonfiguration der Hauptbibliothek muss die folgenden Parameter haben vim /etc/my.cnf 
[mysqld] 
log-bin = binlog // Binäres Protokoll aktivieren server-id = 137 // Eindeutige ID des Servers, der Standardwert ist 1, normalerweise auf die letzte Ziffer der IP-Adresse eingestellt binlog_format = row // Bilog wird auf Zeilenmodus eingestellt, um Replikationsfehler zu vermeiden # Für Slaves werden folgende Parameter empfohlen vim /etc/my.cnf 
[mysqld] 
Relay-Log = Relay-Bin
Server-ID = 138

2.2 Bestimmen Sie den Binärspeicherort der Hauptbibliothek und erstellen Sie ein Synchronisierungskonto

Wenn die Master- und Slave-Datenbanken gerade initialisiert wurden und an der Master-Datenbank kein Vorgang ausgeführt wird, muss die Slave-Datenbank die Daten der Master-Datenbank nicht synchronisieren und kann die Binlog-Position der Master-Datenbank direkt bestimmen.

# Zeigen Sie den Speicherort der Binärprotokolldatei der Hauptbibliothek an. Show Master Status;

# Erstellen Sie ein Synchronisierungskonto in der Hauptdatenbank. Erstellen Sie den Benutzer „repl“@„%“, identifiziert durch „123456“.
gewähre 'repl'@'%' Replikations-Slave auf *.*;

Wenn die Masterdatenbank bereits seit einiger Zeit ausgeführt wird und Geschäftsdaten enthält, die Slavedatenbank jedoch gerade erst initialisiert wurde, müssen Sie die Daten in der Masterdatenbank sichern und sie anschließend in die Slavedatenbank importieren, um die Konsistenz der Master- und Slavedaten herzustellen.

# Erstellen Sie ein Synchronisierungskonto in der Hauptdatenbank. Erstellen Sie den Benutzer „repl“@„%“, identifiziert durch „123456“.
gewähre 'repl'@'%' Replikations-Slave auf *.*;

# mysqldump -uroot -pxxxx -A -R -E --single-transaction --master-data=2 > all_db.sql

# MySQL aus der Datenbank wiederherstellen -uroot -pxxxx < all_db.sql

# Der Binlog-Speicherort der Hauptbibliothek kann aus der Sicherungsdatei ermittelt werden

2.3 Rufen Sie die Slave-Datenbank auf und aktivieren Sie die Master-Slave-Replikation

Nachdem wir den Speicherort der Binärdatei der Masterbibliothek gefunden und die Konsistenz der Master-Slave-Daten sichergestellt haben, können wir offiziell mit der Master-Slave-Replikation beginnen.

# Rufen Sie die MySQL-Befehlszeile aus der Slave-Bibliothek auf und führen Sie die Anweisung „change master“ aus, um eine Verbindung zur Master-Bibliothek herzustellen. # Der Binärdateiname und die POS-Position werden aus den obigen Schritten ermittelt. CHANGE MASTER TO MASTER_HOST='IP-Adresse des MySQL-Masterservers',
 MASTER_PORT=3306,
 MASTER_USER='repl',
 MASTER_PASSWORD = '123456',
 MASTER_LOG_FILE='binlog.000002',
 MASTER_LOG_POS=154;
 
# Starten Sie die Master-Slave-Replikation und behalten Sie den Status „Start Slave“ bei.
show slave status \G //Überprüfen Sie den Slave-Status, um sicherzustellen, dass Slave_IO_Running: Yes Slave_SQL_Running: Yes

3. Master-Slave-Replikation basierend auf GTID

GTID ist eine neue Funktion von MySQL 5.6. Der vollständige Name lautet Global Transaction Identifier und kann das Umschalten und Failover von MySQL-Mastern und -Slaves vereinfachen. GTID wird verwendet, um eine Transaktion im Binärprotokoll eindeutig zu identifizieren. Wenn eine Transaktion festgeschrieben wird, schreibt MySQL Server zuerst ein spezielles Binlog-Ereignis vom Typ GTID_Event, das die GTID der nächsten Transaktion angibt, und schreibt dann das Binlog der Transaktion.

Bei der GTID-basierten Replikation teilt der Slave-Server dem Master-Server zunächst die GTID-Werte der Transaktionen mit, die auf dem Slave-Server ausgeführt wurden. Anschließend sendet die Master-Datenbank alle Transaktionen, die nicht auf der Slave-Datenbank ausgeführt wurden, zur Ausführung an die Slave-Datenbank. Durch die Replikation mithilfe von GTID kann sichergestellt werden, dass dieselbe Transaktion nur einmal auf der angegebenen Slave-Datenbank ausgeführt wird, wodurch Dateninkonsistenzen aufgrund von Offset-Problemen vermieden werden. Mit anderen Worten, unabhängig davon, ob es sich um eine kaskadierende Situation oder eine Ein-Master-mehrere-Slave-Situation handelt, kann die Position automatisch über GTID gefunden werden, ohne dass die Binlog-Position der Hauptbibliothek wie zuvor über File_name und File_position gefunden werden muss.

Die auf GTID basierende Master-Slave-Replikation ähnelt der oben beschriebenen Master-Slave-Replikation basierend auf dem Binärdateispeicherort. Im Folgenden finden Sie eine kurze Demonstration des Einrichtungsvorgangs:

3.1 Bestätigen Sie die Master-Slave-Bibliothekskonfiguration und aktivieren Sie GTID

# Die Parameterkonfiguration der Hauptbibliothek muss die folgenden Parameter haben vim /etc/my.cnf 
[mysqld] 
Server-ID = 137
log-bin = Binlog 
binlog_format = Zeile 
gtid-mode = ON //Gtid-Modus aktivieren enforce-gtid-consistency = ON //Gtid-Konsistenz erzwingen, um die Sicherheit von Transaktionen nach dem Start von gitd zu gewährleisten # Es wird empfohlen, die folgenden Parameter aus der Bibliothek vim /etc/my.cnf zu konfigurieren 
[mysqld] 
Server-ID = 138
log-bin = Binlog 
binlog_format = Zeile 
gtid-Modus = EIN 
erzwingen-gtid-Konsistenz = EIN 
Relay-Log = Relay-Bin

3.2 Erstellen Sie ein Synchronisierungskonto, um die Konsistenz der Master- und Slave-Datenbankdaten zu gewährleisten

Wenn die Masterdatenbank gerade erst initialisiert wurde oder alle Binärdateien in der Masterdatenbank verbleiben, ist es nicht erforderlich, die Daten manuell mit der Slavedatenbank zu synchronisieren. Andernfalls müssen Sie die Daten manuell synchronisieren, um Konsistenz zwischen Master und Slave herzustellen.

# Erstellen Sie ein Synchronisierungskonto in der Hauptdatenbank. Erstellen Sie den Benutzer „repl“@„%“, identifiziert durch „123456“.
gewähre 'repl'@'%' Replikations-Slave auf *.*;

# Wenn die Masterdatenbank gerade initialisiert wurde oder vollständige Binärdateien enthält, müssen Sie die folgenden Schritte nicht ausführen. # Vollständige Sicherung der Masterdatenbankdaten mysqldump -uroot -pxxxx -A -R -E --single-transaction > all_db.sql
# MySQL aus der Datenbank wiederherstellen -uroot -pxxxx < all_db.sql

3.3 Rufen Sie die Slave-Datenbank auf und aktivieren Sie die Master-Slave-Replikation

# Rufen Sie die MySQL-Befehlszeile aus der Slave-Bibliothek auf und führen Sie die Anweisung „change master“ aus, um eine Verbindung zur Master-Bibliothek herzustellen. CHANGE MASTER TO MASTER_HOST='IP-Adresse des MySQL-Masterservers',
 MASTER_PORT=3306,
 MASTER_USER='repl',
 MASTER_PASSWORD = '123456',
 MASTER_AUTO_POSITION = 1;
 
# Starten Sie die Master-Slave-Replikation und behalten Sie den Status „Start Slave“ bei.
Slave-Status anzeigen \G

4. Einige Erfahrungen und Vorschläge

Im Laufe meines täglichen Lernens und Arbeitens habe ich auch einige Erfahrungen mit der Master-Slave-Replikation gesammelt. Hier sind einige einfache Punkte, die ich weitergeben möchte. Ich hoffe, Sie können Fallstricke vermeiden.

• Die Datenbankversionen auf der Master- und der Slave-Seite sollten so weit wie möglich konsistent gehalten werden.
• Es wird empfohlen, dass die Parameter der Master- und Slave-Datenbank (z. B. Zeichensatz und SQL-Modus) identisch sind.
• Die Leistung des Slave-Servers darf nicht zu weit hinter der des Master-Servers zurückbleiben, um Master-Slave-Verzögerungen aufgrund der Serverleistung zu vermeiden.
• Alle Tabellen müssen über einen Primärschlüssel verfügen, da das Synchronisieren einer Tabelle ohne Primärschlüssel mit einer Slave-Datenbank sehr wahrscheinlich zu Master-Slave-Verzögerungen führt.
• Es wird empfohlen, die Slave-Datenbank auf schreibgeschützt zu setzen, um menschliche Fehler bei der Verarbeitung der Slave-Datenbankdaten zu vermeiden.
• Überwachen Sie die Master-Slave-Verzögerung und den Status und beheben Sie Synchronisierungsunterbrechungen oder -verzögerungen rechtzeitig.
  

Zusammenfassen:

Dieser Artikel stellt das Prinzip und den Konstruktionsprozess der Master-Slave-Replikation vor. Tatsächlich gibt es noch viel Inhalt zur Master-Slave-Replikation, der kontinuierliches Lernen erfordert. Hier empfehle ich, den GTID-Modus zum Erstellen einer Master-Slave-Replikation zu verwenden. Die Erfahrungen, die ich später teile, sind auch meine täglichen Erfahrungen. Ich hoffe, sie werden Ihnen hilfreich sein. Schreiben ist nicht einfach. Wenn Sie denken, dass es gut ist, teilen Sie es bitte mit.

Das Obige ist eine detaillierte Analyse der MySQL-Master-Slave-Replikation. Weitere Informationen zur MySQL-Master-Slave-Replikation finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!