Detaillierte Erläuterung der MySQL Master-Slave-Replikationspraxis - Replikation basierend auf Protokollpunkten

Logpoint-basierte Replikation

1. Erstellen Sie ein dediziertes Replikationskonto auf der Master- und Slave-Datenbank

MariaDB [Mitarbeiter]> Erstellen Sie den Benutzer „repl“@„172.%“, identifiziert durch „123456“;

Beachten Sie, dass das Passwort in der Produktion den entsprechenden Vorgaben entsprechen muss, um eine gewisse Passwortstärke zu erreichen und es erforderlich ist, dass auf die Master-Datenbank nur über ein bestimmtes Netzwerksegment auf die Slave-Datenbank zugegriffen werden kann.

2. Erteilen Sie Replikationsberechtigungen für die Master- und Slave-Datenbanken

MariaDB [Mitarbeiter]> gewähren Sie Replikations-Slave auf *.* an „repl“@„172.%“;

3. Konfigurieren Sie die Hauptdatenbank

Beachten Sie, dass zum Aktivieren der binären Protokollierung ein Neustart des Dienstes erforderlich ist. Server_ID ist ein dynamischer Parameter, der mit Befehlszeilen und Konfigurationsdateien kombiniert werden kann, um eine dauerhafte Konfiguration ohne Neustart zu erreichen. Beachten Sie, dass Server_ID im Cluster eindeutig ist.

[mysqld]
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
binlog_format = Zeile
Server-ID = 101

HINWEIS: Es empfiehlt sich, Protokolle von Daten zu trennen, vorzugsweise in unterschiedlichen Datenpartitionen.

4. Konfigurieren Sie die Slave-Bibliothek

Die Option log_slave_update bestimmt, ob das Relay-Protokoll relay_log im lokalen Binlog gespeichert werden soll. Wenn eine Link-Replikation konfiguriert ist, ist diese Option erforderlich. Beachten Sie, dass server_id im Cluster eindeutig ist.

[mysqld]
# Replikation
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
Server-ID = 102
# Sklaven
relay_log = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
relay_log_info_file = /var/log/mysql/relay-bin.info
log_slave_updates = EIN
schreibgeschützt

5. Initialisieren Sie die Daten aus der Bibliothek

Hier verwenden wir mysqldump, um die Masterdatenbank zu sichern. In der Produktion empfehlen wir die Verwendung von xtrabackup für ein sperrenfreies Hot-Backup (basierend auf der InnoDB-Engine).

Sichern Sie die Daten der Mitarbeiterdatenbank auf der Hauptdatenbank

Mounten Sie die Sicherungsdatei backup.sql per SCP oder Docker-Volume auf dem Slave-Server und importieren Sie sie in die Slave-Bibliothek

mysql -u root -p < Backup.sql

6. Starten Sie den Replikationslink

Es gibt [email protected] und [email protected], und die Daten wurden über mysqldump mit dem Slave synchronisiert. Konfigurieren Sie nun den Replikationslink auf dem Slave-Server

MariaDB [(keine)]> ÄNDERN SIE MASTER IN MASTER_HOST='master', MASTER_USER='repl', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mariadb-bin.000029', MASTER_LOG_POS=516;
Abfrage OK, 0 Zeilen betroffen (0,02 Sek.)

Starten Sie den Replikationslink auf dem Slave

MariaDB [(keine)]> Slave starten;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

7. Überprüfen Sie den Slave-Status der Slave-Bibliothek

Slave_IO_Running und Slave_SQL_Running müssen JA sein. Wenn ein Fehler auftritt, lesen Sie die Eingabeaufforderungsinformationen von Last_IO_Error oder Last_SQL_Error im Detail.

MariaDB [(keine)]> Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
        Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
         Master_Host: Master
         Master_Benutzer: repl
         Master_Port: 3306
        Verbindungswiederholung: 60
       Master_Log_File: mariadb-bin.000029
     Read_Master_Log_Pos: 516
        Relay_Log_File: relay-bin.000002
        Relay_Log_Pos: 539
    Relay_Master_Log_File: mariadb-bin.000029
       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: 516
       Relay_Log_Space: 831
       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: 101
        Master_SSL_Crl:
      Master_SSL_Crlpfad:
          Using_Gtid: Nein
         Gtid_IO_Pos:
   Domänen-IDs replizieren:
 Domänen-IDs replizieren_ignorieren:
        Parallel_Mode: konservativ
1 Zeile im Satz (0,00 Sek.)

8. Überprüfen Sie den Dump-Thread in der Hauptbibliothek

Überprüfen Sie, ob der Binlog-Dump-Thread korrekt gestartet wurde

MariaDB [(keine)]> Prozessliste anzeigen \G
*************************** 1. Reihe ***************************
   ID: 7
  Benutzer: root
  Gastgeber: 172.20.0.1:41868
   db: Mitarbeiter
 Befehl: Schlafen
  Zeit: 56
  Zustand:
  Info: NULL
Fortschritt: 0.000
*************************** 2. Reihe ***************************
   ID: 10
  Benutzer: repl
  Gastgeber: 172.20.0.3:45974
   db: NULL
 Befehl: Binlog Dump
  Zeit: 246
  Status: Der Master hat das gesamte Binärprotokoll an den Slave gesendet. Wartet auf die Aktualisierung des Binärprotokolls.
  Info: NULL
Fortschritt: 0.000

Sie können sehen, dass in Zeile 2 der Befehl „Binlog Dump“ gestartet wird, was beweist, dass der Replikationsthread erfolgreich gestartet wurde.

9. Zusammenfassung

Vorteil

1. Die Technologie ist ausgereift und es gibt relativ wenige Fehler
2. Es gibt keine Einschränkungen für SQL-Abfragen. Beispielsweise können bei der Replikation auf Basis von GTID nicht alle SQL-Abfragen verwendet werden.
   

Mangel

1. Es ist schwierig, den Protokoll-Offset des neuen Masters während eines Failovers erneut abzurufen.

Wenn in einer Umgebung mit einem Master und mehreren Slaves der alte Master abstürzt und ein neuer Master im Cluster gewählt wird, müssen die anderen Slaves erneut mit dem neuen Master synchronisiert werden. Da das Binärprotokoll jeder Datenbank unabhängig existiert, ist es schwierig, den Protokollpunkt zu finden, um die Synchronisierung zu starten.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.