MySQL-Master-Slave-Replikationspraxis – detaillierte Erläuterung von Replikationscodebeispielen basierend auf Protokollpunkten

Dieser Artikel stellt hauptsächlich die detaillierte Erklärung der MySQL Master-Slave-Replikationspraxis vor – die Replikation basierend auf Protokollpunkten, die einen bestimmten Referenzwert hat.

Replikation basierend auf Protokollpunkten

1. Richten Sie dedizierte Replikationskonten in der Master-Datenbank und der Slave-Datenbank ein

MariaDB [employees]> create user 'repl'@'172.%' identified by '123456';

Achten Sie auf die Produktion Das Passwort muss den relevanten Spezifikationen entsprechen, um eine bestimmte Passwortstärke zu erreichen, und es ist festgelegt, dass auf die Hauptbibliothek nur über ein bestimmtes Netzwerksegment in der Slave-Bibliothek zugegriffen werden kann

2. Gewähren Sie Kopierberechtigungen für die Hauptbibliothek Bibliothek und die Slave-Bibliothek

MariaDB [employees]> grant replication slave on *.* to 'repl'@'172.%';

3. Konfigurieren Sie die Hauptbibliothek

Beachten Sie, dass für die Aktivierung von Binärprotokollen ein Neustart des Dienstes erforderlich ist und server_id ein dynamischer Parameter ist, der mit der Befehlszeile kombiniert werden kann und die Konfigurationsdatei, um Persistenz zu erreichen, ohne die Konfiguration neu zu starten

[mysqld]
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
binlog_format = row
server_id = 101

HINWEIS: Es ist eine gute Angewohnheit, Protokolle von Daten zu trennen Am besten platzieren Sie sie in verschiedenen Datenpartitionen

4. Konfigurieren Sie die Slave-Bibliothek

Option log_slave_update, um zu entscheiden, ob das Relay-Protokoll „relay_log“ im lokalen Binlog gespeichert werden soll, wenn die Link-Replikation konfiguriert ist , diese Option ist erforderlich.

[mysqld]
# replication
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
server_id = 102
# slaves
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 = ON
read_only

5. Initialisieren Sie die Daten aus der Slave-Datenbank.

Mysqldump wird hier zum Sichern der Hauptdatenbank verwendet. In der Produktion wird empfohlen, xtrabackup für ein sperrfreies Hot-Backup (basierend auf der Innodb-Engine) zu verwenden.

Sichern Sie die Daten der Mitarbeiterdatenbank in der Hauptdatenbank

Der Code ist wie folgt:

mysqldump --single-transaction --master-data=1 --triggers --routines --databases employees -u root -p >> backup.sql

Mounten Sie die Sicherungsdatei backup.sql über scp oder Docker-Volume vom Server in die Datenbank und importieren Sie sie in die Slave-Bibliothek

mysql -u root -p < backup.sql

6. Starten Sie den Replikationslink

Der vorhandene Master@172.20.0.2 und Slave@172.20.0.3 wurden über mysqldump übertragen. Die Daten werden mit der Slave-Datenbank synchronisiert. Konfigurieren Sie nun den Replikationslink auf dem Slave-Server-Slave

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='master', 
MASTER_USER='repl', 
MASTER_PASSWORD='123456', 
MASTER_LOG_FILE='mariadb-bin.000029', 
MASTER_LOG_POS=516;
Query OK, 0 rows affected (0.02 sec)

Starten Sie den Replikationslink auf der Slave-Datenbank

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.01 sec)

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

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

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
        Slave_IO_State: Waiting for master to send event
         Master_Host: master
         Master_User: repl
         Master_Port: 3306
        Connect_Retry: 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: Yes
      Slave_SQL_Running: Yes
       Replicate_Do_DB:
     Replicate_Ignore_DB:
      Replicate_Do_Table:
    Replicate_Ignore_Table:
   Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
          Last_Errno: 0
          Last_Error:
         Skip_Counter: 0
     Exec_Master_Log_Pos: 516
       Relay_Log_Space: 831
       Until_Condition: None
        Until_Log_File:
        Until_Log_Pos: 0
      Master_SSL_Allowed: No
      Master_SSL_CA_File:
      Master_SSL_CA_Path:
       Master_SSL_Cert:
      Master_SSL_Cipher:
        Master_SSL_Key:
    Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
        Last_IO_Errno: 0
        Last_IO_Error:
        Last_SQL_Errno: 0
        Last_SQL_Error:
 Replicate_Ignore_Server_Ids:
       Master_Server_Id: 101
        Master_SSL_Crl:
      Master_SSL_Crlpath:
          Using_Gtid: No
         Gtid_IO_Pos:
   Replicate_Do_Domain_Ids:
 Replicate_Ignore_Domain_Ids:
        Parallel_Mode: conservative
1 row in set (0.00 sec)

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

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

MariaDB [(none)]> show processlist \G
*************************** 1. row ***************************
   Id: 7
  User: root
  Host: 172.20.0.1:41868
   db: employees
 Command: Sleep
  Time: 56
  State:
  Info: NULL
Progress: 0.000
*************************** 2. row ***************************
   Id: 10
  User: repl
  Host: 172.20.0.3:45974
   db: NULL
 Command: Binlog Dump
  Time: 246
  State: Master has sent all binlog to slave; waiting for binlog to be updated
  Info: NULL
Progress: 0.000

Sie können sehen, dass der Befehl für Binlog Dump in Zeile 2 gestartet wird, was beweist, dass der Kopierthread erfolgreich gestartet wurde

9. Zusammenfassung

Vorteile

1. Ausgereifte Technologie, relativ wenige Fehler

2. Es gibt keine Einschränkungen bei SQLAbfragen, z. B. kann beim Kopieren basierend auf GTID nicht alle SQL-Anweisungen verwendet werden
   

Nachteile

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

Wenn in einer Ein-Master-Multi-Slave-Umgebung der alte Master ausfällt, wird der Cluster neu erstellt Der Master wird ausgewählt und andere Slave-Bibliotheken müssen den neuen Master neu synchronisieren. Da das Binlog jeder Datenbank unabhängig existiert, ist es schwierig, den Protokollpunkt zum Starten der Synchronisierung zu finden

Das obige ist der detaillierte Inhalt vonMySQL-Master-Slave-Replikationspraxis – detaillierte Erläuterung von Replikationscodebeispielen basierend auf Protokollpunkten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!