Vorteile und Prinzipien der MySQL-Replikation im Detail erklärt

Bei der Replikation werden die DDL- und DML-Operationen der Masterdatenbank über Binärprotokolle auf die Slavedatenbank übertragen und anschließend auf der Slavedatenbank wiederholt, sodass die Daten in der Slavedatenbank und der Masterdatenbank synchronisiert bleiben. MySQL kann gleichzeitig von einer Masterdatenbank auf mehrere Slavedatenbanken replizieren, und eine Slavedatenbank kann auch als Masterdatenbank für andere Slavedatenbanken dienen, um eine Kettenreplikation zu erreichen.

Vorteile der MySQL-Replikation:

• Bei einem Ausfall der Master-Datenbank kann der Dienst schnell auf die Slave-Datenbank umgestellt werden.
• Führen Sie Abfragevorgänge auf der Slave-Datenbank aus, um den Zugriffsdruck auf die Master-Datenbank zu verringern.
• Führen Sie eine Sicherung der Slave-Datenbank durch, um eine Beeinträchtigung der Master-Datenbank während der Sicherung zu vermeiden.

MySQL-Replikationsprinzip

1. Wenn eine Transaktion festgeschrieben wird, zeichnet die MySQL-Masterdatenbank Datenänderungen als Ereignisse im Binlog auf. Der Parameter sync_binlog in der Masterdatenbank steuert das Leeren des Binlog-Protokolls auf die Festplatte.

2. Die Master-Datenbank überträgt Ereignisse im Binärprotokoll in das Relay-Protokoll der Slave-Datenbank. Die Slave-Datenbank wiederholt dann die Ereignisse basierend auf dem Relay-Protokoll und erreicht durch logische Replikation Datenkonsistenz zwischen der Master- und der Slave-Datenbank.

MySQL verwendet drei Threads, um die Datenreplikation zwischen der Master- und der Slave-Datenbank abzuschließen: Der Binlog-Dump-Thread wird auf der Master-Datenbank ausgeführt, und der I/O-Thread und der SQL-Thread werden auf der Slave-Datenbank ausgeführt. Beim Starten der Replikation auf dem Slave wird zunächst ein I/O-Thread erstellt, um eine Verbindung zum Master herzustellen. Der Master erstellt dann einen Binlog-Dump-Thread, um Datenbankereignisse zu lesen und an den I/O-Thread zu senden. Nachdem der I/O-Thread die Ereignisdaten erhalten hat, aktualisiert er sie im Relay-Protokoll des Slaves. Anschließend liest der SQL-Thread auf dem Slave die aktualisierten Datenbankereignisse im Relay-Protokoll und wendet sie an.

Wie in der folgenden Abbildung dargestellt:

Sehen Sie sich die Hauptbibliothek an:

mysql> Prozessliste anzeigen\G; 
*************************** 1. Reihe *************************** 
   ID: 3 
  Benutzer: root 
  Gastgeber: 10.24.33.187:54194 
   db: NULL 
Befehl: Schlafen 
  Zeit: 176 
 Zustand:  
  Info: NULL 
*************************** 2. Reihe *************************** 
   ID: 4 
  Benutzer: root 
  Gastgeber: 10.24.33.187:54195 
   db: NULL 
Befehl: Schlafen 
  Zeit: 176 
 Zustand:  
  Info: NULL 
*************************** 3. Reihe *************************** 
   ID: 8 
  Benutzer: root 
  Host: localhost 
   db:test 
Befehl: Abfrage 
  Zeit: 0 
 Status: beginnend 
  Info: Prozessliste anzeigen 
*************************** 4. Reihe *************************** 
   ID: 12 
  Benutzer: repl 
  Gastgeber: dsz884.hcg.homecredit.net:39731 
   db: NULL 
Befehl: Binlog Dump --Binlog Dump Thread Zeit: 87 
 Status: Der Master hat das gesamte Binärprotokoll an den Slave gesendet; wartet auf weitere Updates – Daraus können wir ersehen, dass die Synchronisierung im „Push“-Verfahren erfolgt. Info: NULL 
4 Zeilen im Satz (0,00 Sek.) 
 
FEHLER:  
Keine Abfrage angegeben

Zeigen Sie die Sicherungsbibliothek an:

mysql> Prozessliste anzeigen\G; 
*************************** 1. Reihe *************************** 
   ID: 1 
  Benutzer: Systembenutzer 
  Gastgeber:  
   db: NULL 
Befehl: Verbinden 
  Zeit: 4427 
 Status: Wartet darauf, dass der Master ein Ereignis sendet 
  Info: NULL 
*************************** 2. Reihe *************************** 
   ID: 2 
  Benutzer: Systembenutzer 
  Gastgeber:  
   db: NULL 
Befehl: Verbinden 
  Zeit: 2044 
 Status: Slave hat alle Relay-Logs gelesen; wartet auf weitere Updates 
  Info: NULL

Daraus ist ersichtlich, dass die MySQL-Replikation asynchron ist und zwischen der Slave-Datenbank und der Master-Datenbank eine gewisse Verzögerung auftritt.

Zugehörige Protokolle kopieren

1. BinlogBinlog zeichnet alle Datenänderungsvorgänge in MySQL auf. Sie können das Format von Binlog auf folgende Arten anzeigen. Es gibt drei Typen: Anweisung, Zeile und Gemischt:

mysql> Variablen wie „%binlog_format%“ anzeigen; 
+---------------+-------+ 
| Variablenname | Wert | 
+---------------+-------+ 
| binlog_format | REIHE | 
+---------------+-------+ 
1 Zeile im Satz (0,00 Sek.)

2. Relay-Protokoll Das Dateiformat und der Inhalt des Relay-Protokolls sind dieselben wie bei Binlog. Der einzige Unterschied besteht darin, dass der SQL-Thread auf dem Slave das Relay-Protokoll automatisch löscht, um Speicherplatz freizugeben, nachdem der SQL-Thread auf dem Slave die Ereignisse im aktuellen Relay-Protokoll ausgeführt hat. Um sicherzustellen, dass der E/A-Thread und der SQL-Thread des Slaves nach einem Absturz und Neustart des Slaves immer noch wissen, wo die Replikation beginnen soll, erstellt der Slave standardmäßig zwei Protokolldateien, master.info und relay-log.info, um den Replikationsfortschritt zu speichern. Diese beiden Dateien zeichnen den Fortschritt des E/A-Threads des Slaves auf, der derzeit das Binlog des Masters liest, und den Fortschritt des SQL-Threads, der das Relay-Log anwendet.

mysql> Slave-Status anzeigen \G; 
*************************** 1. Reihe *************************** 
        Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet 
         Master_Host: 10.24.33.186 – Hauptdatenbank-IP 
         Master_User: repl -- Benutzerkonto der Masterdatenbank, das für die Master-Slave-Replikation verwendet wird Master_Port: 3306 -- Port der Masterdatenbank Connect_Retry: 60  
       Master_Log_File: mysql-bin.000005 --Der Dateiname des Binlogs der Master-Bibliothek, das derzeit vom I/O-Thread der Slave-Bibliothek gelesen wird. Read_Master_Log_Pos: 4356 --Die Position des Binlogs der Master-Bibliothek, das vom I/O-Thread der Slave-Bibliothek gelesen wird. Relay_Log_File: strong-relay-bin.000006 --Das Relay-Log, das vom SQL-Thread angewendet wird. 
        Relay_Log_Pos: 320 --Speicherort des Relay-Protokolls Relay_Master_Log_File: mysql-bin.000005 --Binlog entsprechend dem Relay-Protokoll 
       Slave_IO_Running: Ja 
      Slave_SQL_Running: Ja 
       Replicate_Do_DB:  
     Replikat_Ignorieren_DB:  
      Tabelle_replizieren:  
    Tabelle_Ignorieren_replizieren:  
   Wild_Do_Tabelle replizieren:  
 Tabelle_Wild_Ignore_replizieren:  
          Last_Errno: 0 
          Letzter_Fehler:  
         Skip_Counter: 0 
     Exec_Master_Log_Pos: 4356 --SQL-Thread wendet den Speicherort des Relay-Protokolls an, der dem Speicherort des Binlog-Relay_Log_Space entspricht: 1153 
       Until_Condition: Keine 
        Bis_Log_Datei:  
        Bis_Log_Pos: 0 
      Master_SSL_Allowed: Nein 
      Master_SSL_CA_Datei:  
      Master_SSL_CA_Pfad:  
       Master_SSL_Zertifikat:  
      Master_SSL_Chiffre:  
        Master_SSL_Schlüssel:  
    Sekunden_Hinter_Master: 0 
Master_SSL_Verify_Server_Cert: Nein 
        Last_IO_Errno: 0 
        Letzter_E/A-Fehler:  
        Last_SQL_Errno: 0 
        Letzter_SQL_Fehler:  
 Server-IDs replizieren_ignorieren:  
       Master_Server_Id: 1 
         Master_UUID: 2a3e3fd9-0587-11e8-bdb8-0800272325a8 
       Master_Info_Datei: /usr/local/mysql-5.7.21-el7-x86_64/data/master.info 
          SQL_Delay: 0 
     SQL_Remaining_Delay: NULL 
   Slave_SQL_Running_State: Slave hat alle Relay-Logs gelesen; wartet auf weitere Updates 
      Master_Retry_Count: 86400 
         Master_Bind:  
   Zeitstempel des letzten IO-Fehlers:  
   Letzter_SQL_Fehler_Zeitstempel:  
        Master_SSL_Crl:  
      Master_SSL_Crlpfad:  
      Abgerufenes_Gtid_Set:  
      Ausgeführtes_Gtid_Set:  
        Auto_Position: 0 
     DB replizieren_neu schreiben:  
         Kanalname:  
      Master_TLS_Version:  
1 Zeile im Satz (0,00 Sek.) 
 
FEHLER:  
Keine Abfrage angegeben 
 
MySQL>

MySQL-Replikationsmethode

Es gibt drei Binlog-Formate, entsprechend den drei Technologien der MySQL-Replikation.

MySQL-Replikationsarchitektur

Zu den gängigen Architekturen der MySQL-Replikation gehören die One-Master-Multiple-Slave-Replikationsarchitektur, die Multi-Level-Replikationsarchitektur und die Dual-Master-Replikationsarchitektur (Dual Master).

1. Architektur mit einem Master und mehreren Slaves In Szenarien, in denen der Leseanforderungsdruck der Masterdatenbank sehr hoch ist, wird eine Lese- und Schreibtrennung durch die Konfiguration einer Replikationsarchitektur mit einem Master und mehreren Slaves erreicht. Leseanforderungen, die keine hohe Echtzeitleistung erfordern, werden durch Lastausgleich auf mehrere Slave-Datenbanken verteilt, wodurch der Lesedruck der Masterdatenbank verringert wird, wie in der Abbildung dargestellt:

2. Mehrstufige Replikationsarchitektur Die Architektur mit einem Master, mehreren Slaves kann die Anforderungen der meisten Szenarien mit besonders hohem Leseanforderungsdruck erfüllen. Da die MySQL-Replikation darin besteht, dass die Masterdatenbank Binlog in die Slavedatenbank schiebt, steigen der E/A-Druck und der Netzwerkdruck der Masterdatenbank mit der Zunahme der Slavedatenbanken (jede Slavedatenbank verfügt über einen unabhängigen Binlog-Dump-Thread in der Masterdatenbank, um Binlog-Ereignisse zu senden). Die mehrstufige Replikationsarchitektur löst das Szenario mit zusätzlichem E/A- und Netzwerkdruck der Masterdatenbank im Szenario mit einem Master, mehreren Slaves, wie in der Abbildung dargestellt:

3. Dual Master Replication/Dual Master-Architektur Die Dual Master Replication/Dual Master-Architektur eignet sich besonders für Szenarien, in denen DBA zur Wartung zwischen Master und Slave wechseln muss. Diese Architektur vermeidet den Aufwand, wiederholt Slave-Bibliotheken zu erstellen, wie in der Abbildung dargestellt: