Detaillierte Analyse der Replikation in MySQL

1.MySQL-Replikationskonzept

Dies bedeutet, dass die DDL- und DML-Vorgänge der primären Datenbank über Binärprotokolle auf den Replikationsserver übertragen und diese Protokolldateien dann auf dem Replikationsserver erneut ausgeführt werden, um die Daten des Replikationsservers und des primären Servers synchronisiert zu halten. Beim Replikationsprozess fungiert ein Server als Master und ein oder mehrere andere Server als Slaves. Der Master schreibt Aktualisierungen in die binäre Protokolldatei neu und verwaltet einen Index der Datei, um Protokollrotationen zu verfolgen. Diese Protokolle zeichnen Aktualisierungen auf, die an die Slave-Server gesendet werden. Wenn ein Slave eine Verbindung zu einem Master herstellt, informiert er den Master über den Speicherort des letzten erfolgreichen Updates, das der Slave im Protokoll gelesen hat. Der Slave akzeptiert ab diesem Zeitpunkt alle auftretenden Updates, blockiert dann und wartet auf die Benachrichtigung über neue Updates vom Master.

2. Zweck des Kopierens

Die Datensynchronisierung erfolgt über die Master-Slave-Replikation, und die Lese-/Schreibtrennung (MySQL-Proxy) verbessert die gleichzeitige Ladekapazität der Datenbank. Alternativ kann ein Master-Slave-Design verwendet werden, um sicherzustellen, dass die Anwendung auf die Sicherungsmaschine umgeschaltet werden und innerhalb kürzester Zeit weiter ausgeführt werden kann, nachdem der Host nicht mehr reagiert.

Vorteile:

(1) Das Datenbankclustersystem verfügt über mehrere Datenbankknoten. Wenn ein einzelner Knoten ausfällt, können andere normale Knoten weiterhin Dienste bereitstellen.
(2) Wenn auf dem Master-Server ein Problem auftritt, kann auf den Slave-Server umgeschaltet werden. (3) Durch Replikation können Abfragevorgänge auf dem Slave-Server ausgeführt werden, wodurch der Zugriffsdruck auf den Master-Server verringert und eine Datenverteilung und ein Lastausgleich erreicht werden. (4) Auf dem Slave-Server können Sicherungen ausgeführt werden, um zu vermeiden, dass der Dienst des Master-Servers während des Sicherungszeitraums beeinträchtigt wird.

3. Durchführung der Replikation (3 Methoden)

(1) DRBD ist eine softwareimplementierte Shared-Nothing-Speicherreplikationslösung, die den Inhalt von Blockgeräten zwischen Servern spiegelt.
(2) MySQL-Cluster (auch als MySQL-Cluster bekannt). Die MySQL-Replikation selbst ist eine relativ einfache Struktur, d. h. ein Slave-Server (Slave) liest das Binärprotokoll von einem Master-Server (Master), analysiert es und wendet es dann auf sich selbst an.
(3) Für eine einfache Replikationsumgebung sind lediglich zwei Hosts erforderlich, auf denen MySQL läuft. Sie können sogar zwei mysqld-Instanzen auf einem physischen Server-Host starten. Einer wird als Master und der andere als Slave verwendet, um die Replikationsumgebung zu vervollständigen. In tatsächlichen Anwendungsumgebungen können Sie jedoch die MySQL-Replikationsfunktion verwenden, um eine Vielzahl anderer, skalierbarerer Replikationsarchitekturen basierend auf den tatsächlichen Geschäftsanforderungen zu erstellen, z. B. die am häufigsten verwendete Master-Slave-Architektur.
Bei der Master-Slave-Architektur werden ein MySQL-Server als Master und ein oder mehrere MySQL-Server als Slaves verwendet, um die Daten des Masters auf die Slaves zu kopieren. In tatsächlichen Anwendungsszenarien wird der Master-Slave-Architekturmodus am häufigsten für die MySQL-Replikation verwendet. Im Allgemeinen werden bei dieser Architektur die Schreibvorgänge des Systems im Master ausgeführt, während die Lesevorgänge auf jeden Slave verteilt werden. Daher eignet sich diese Architektur besonders für die aktuellen hohen Lese- und Schreibprobleme des Internets.

Der MySQL-Datenbankreplikationsvorgang ist grob in die folgenden Schritte unterteilt:

(1) Der Master aktiviert das binäre Logging. Die Aktivierung der binären Protokollierung wird ausführlich unter „Protokollverwaltung“ beschrieben.
(2) Der I/O-Prozess auf dem Slave verbindet sich mit dem Master und fordert den Log-Inhalt nach der angegebenen Position der angegebenen Log-Datei an (oder vom Anfang des Logs an).
(3) Nachdem der Master die E/A-Prozessanforderung vom Slave erhalten hat, liest der für die Replikation verantwortliche E/A-Prozess die Protokollinformationen nach der angegebenen Position des angegebenen Protokolls gemäß den Anforderungsinformationen und gibt sie an die E/A des Slaves zurück. Zusätzlich zu den im Protokoll enthaltenen Informationen umfassen die zurückgegebenen Informationen auch den Namen der Binärprotokolldatei, die an die Masterseite gesendet wurde, und den Speicherort des Binärprotokolls.
(4) Nachdem der E/A-Prozess des Slaves die Informationen empfangen hat, fügt er den empfangenen Protokollinhalt der Reihe nach an das Ende der Relay-Protokolldatei des Slaves an und zeichnet den Dateinamen und den Speicherort des vom Master gelesenen Binärprotokolls in der Master-Infodatei auf.
(5) Nachdem der SQL-Prozess des Slaves den neuen Inhalt im Relay-Protokoll erkennt, analysiert er den Inhalt des Relay-Protokolls sofort und führt ihn auf sich selbst aus.

4. Zentralisierter Modus der MySQL-Replikation

In Versionen nach MySQL 5.1 besteht die Verbesserung der Replikation in der Einführung einer neuen Replikationstechnologie – der zeilenbasierten Replikation. Diese Technologie konzentriert sich auf die Datensätze, die sich in der Tabelle geändert haben, und nicht auf den vorherigen Binlog-Modus. Ab MySQL 5.1.12 kann dies mithilfe der folgenden drei Modi erreicht werden.

(1) SQL-Anweisungsbasierte Replikation (SBR)
(2) Zeilenbasierte Replikation (rbr)
(3) Mixed-Mode-Replikation (mbr)

Entsprechend gibt es drei Binärlog-Formate: Anweisung, Zeile und gemischt. Im Mbr-Modus ist der Sbr-Modus die Standardeinstellung. Das Binlog-Format kann zur Laufzeit dynamisch geändert werden. Die Methode zum Einstellen des Master-Slave-Replikationsmodus ist sehr einfach. Fügen Sie einfach einen weiteren Parameter basierend auf der vorherigen Replikationskonfiguration wie folgt hinzu:

binlog_format = "Anweisung"
#binlog_format="Zeile"
#binlog_format=”gemischt”

Natürlich können Sie das Binlog-Format auch zur Laufzeit dynamisch ändern

Mysql> Sitzung festlegen binlog_format="Anweisung"

5. Kontrollieren Sie den Hauptserverbetrieb

Meister: 192.168.11.139
Sklave: 192.168.11.130

(1) Primärserver:

mysql> Variablen wie „%datadir%“ anzeigen;
+------------------+--------------------------+
| Variablenname | Wert |
+------------------+--------------------------+
| Datenverzeichnis | /Anwendung/mysql/Daten/ |
+------------------+--------------------------+

Aktivieren Sie die binäre Protokollierung auf dem primären Server:

mysql> Variablen wie „log_bin“ anzeigen;
+---------------+-------+
| Variablenname | Wert |
+---------------+-------+
| log_bin | AUS |
+---------------+-------+
Zeile im Satz (0,00 Sek.)

OFF bedeutet, dass die Binärprotokollierung geschlossen ist.

Schritte zum Aktivieren von Protokoll 3:

①Öffnen Sie das MySQL-Installationsverzeichnis/my.cnf
② Suchen Sie das Tag [mysqld] und fügen Sie in der Zeile darunter die folgende Anweisung hinzu:

log_bin[Dateiname]

In dieser Anweisung gibt log-bin an, dass eine Binärdatei geöffnet werden soll; Dateiname ist der Name des Binärprotokolls. Wenn nicht angegeben, ist der Standard der Hostname, gefolgt von -bin als Dateiname, und die Speicherung erfolgt standardmäßig im Verzeichnis datadir. Wenn Sie hier binary_log angeben, um Binärdateien nur für die angegebene Datenbank zu generieren, müssen Sie die folgende Anweisung hinzufügen

Binlog-do-db=db_name (Datenbankname)

Wenn Sie keine Binärdateiprotokolle für die angegebene Datenbank generieren, müssen Sie die folgende Anweisung hinzufügen

Binlog-ignore-db-db_name (Datenbankname)

③Starten Sie den MySQL-Dienst neu. Sie können die Datei „binary_log.digital number“ im MySQL-Installationsverzeichnis/Datenordner sehen, z. B. binary_log.00001. Bei jedem Neustart des MySQL-Dienstes wird die Binärdatei neu generiert und die Nummer im Dateinamen erhöht sich.

Nachdem der Bootvorgang erfolgreich war, ändern Sie die MySQL-Konfigurationsdatei my.cnf und legen Sie die Server-ID fest. Der Code lautet wie folgt

Server-id=1
Binlog-do-db=xscj
Binlog-ignore-db=mysql
Server-ID=1: Jedem Datenbankserver muss eine eindeutige Server-ID zugewiesen werden, für den Master-Server normalerweise 1. Die Server-IDs des Master- und des Slave-Servers dürfen nicht identisch sein.
Binlog-do-db: Gibt die Datenbank an, die kopiert werden muss. Hier wird xscj als Beispiel verwendet. Binlog-ignore-db: Gibt die Datenbank an, die nicht kopiert werden muss.

Erstellen Sie die für die Replikation erforderlichen Benutzer auf dem Master

mysql> gewähre rep_user@'%' Replikations-Slave auf *.*;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
mysql> Berechtigungen leeren;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.

mysql> Masterstatus anzeigen\G
*************************** 1. Reihe ***************************
      Datei: binary_log.000001
    Position: 303
  Binlog_Do_DB: 
Binlog_Ignore_DB: 
Zeile im Satz (0,00 Sek.)

Sichern Sie die Daten des Master-Hosts, speichern Sie sie in der Datei /data/binary_dump.txt und importieren Sie sie dann auf den Slave-Computer. Die spezifische Ausführungsanweisung lautet wie folgt

[root@localhost bin]# mysqldump -h localhost>/data/binary_dump.txt

(2) Steuern Sie den Betrieb des Slave-Servers

Ändern Sie die Datenbankkonfigurationsdatei des Slave-Servers und konfigurieren Sie sie wie folgt:

Server-id=2 ##Legen Sie die Slave-Server-ID fest
Master-Host = 192.168.11.129
Master-Benutzer=rep_user
Master-password= ##Legen Sie das Kennwort für die Verbindung mit dem Master-Server fest Replicate-do-db ##Legen Sie die Datenbank fest, die Sie synchronisieren möchten. Sie können mehrere festlegen Master-port=<port> ##Konfigurieren Sie die Portnummer Starten Sie den Slave neu und führen Sie den folgenden Befehl auf dem MySQL des Slave-Hosts erneut aus, um den Slave-Dienst herunterzufahren Mysql>stop slave;
Stellen Sie den Slave so ein, dass er replikationsbezogene Informationen implementiert, und führen Sie den folgenden Befehl aus: Mysql>change master to
>master_host='',
>master_user='',
>master_password='',
>master_log_file='binary_log.000007',
>master_log_pos=120;

Eingabe: show slave status\G wird verwendet, um wichtige Parameterinformationen über den Slave-Server-Thread bereitzustellen.

Häufig verwendete Befehle sind wie folgt

Dies ist der gesamte Inhalt dieses Artikels zur detaillierten Analyse der Replikation in MySQL. Ich hoffe, er wird für alle hilfreich sein. Bitte lesen Sie hierzu: Einführung in die Fuzzy-Abfragemethode mit instr in MySQL, Codeanalyse von Benutzervariablen in MySQL-Abfrageanweisungen, detaillierte Erläuterung von JSON-Datentypoperationen in MySQL-Operationen usw. Wenn es irgendwelche Mängel gibt, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen. Wenn es Probleme gibt, können wir sie beheben. Die Dinge sind nicht statisch.