Pratique de réplication maître-esclave MySQL - Explication détaillée des exemples de codes de réplication basés sur les points de journalisation

Cet article présente principalement l'explication détaillée de la pratique de réplication maître-esclave MySQL - la réplication basée sur les points de journalisation, qui a une certaine valeur de référence. Les amis intéressés peuvent s'y référer.

Réplication basée sur les points de log

1. Établissez des comptes de réplication dédiés sur la base de données maître et la base de données esclave

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

Faites attention à la production. le mot de passe doit être conforme aux spécifications pertinentes pour atteindre une certaine force de mot de passe, et il est stipulé que la bibliothèque principale n'est accessible que sur un segment de réseau spécifique sur la bibliothèque esclave

2 Accorder des autorisations de copie sur la bibliothèque principale. bibliothèque et la bibliothèque esclave

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

3. Configurez la bibliothèque principale

Notez que l'activation des journaux binaires nécessite le redémarrage du service et que server_id est un paramètre dynamique qui peut être combiné avec la ligne de commande. et le fichier de configuration pour obtenir la persistance sans redémarrer la configuration. Notez que server_id est unique dans le cluster

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

REMARQUE : C'est une bonne habitude de séparer les journaux des données. il est préférable de les placer dans différentes partitions de données

4. Configurez l'option log_slave_update de la bibliothèque esclave

pour décider de stocker ou non le journal de relais relay_log dans le binlog local si la réplication de lien est configurée. , cette option est obligatoire. Notez que server_id est unique dans le cluster

[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. Initialisez les données de la base de données esclave

Mysqldump est utilisé ici pour sauvegarder la base de données principale. En production, il est recommandé d'utiliser xtrabackup pour une sauvegarde à chaud sans verrouillage (basée sur le moteur innodb).

Sauvegardez les données de la base de données des employés sur la base de données principale

Le code est la suivante :

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

Montez le fichier de sauvegarde backup.sql sur la base de données via scp ou docker volume depuis le serveur et importez-le dans la bibliothèque esclave

mysql -u root -p < backup.sql

6. Démarrez le lien de réplication

Les master@172.20.0.2 et slave@172.20.0.3 existants ont été transférés via mysqldump Les données sont synchronisées avec la base de données esclave. Configurez maintenant le lien de réplication sur le serveur esclave

.

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)

Démarrez le lien de réplication sur la base de données esclave

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

7. Sur la base de données esclave Vérifiez l'état de l'esclave

Slave_IO_Running et Slave_SQL_Running doivent être OUI Si une erreur se produit. , vous devez lire les informations d'invite de Last_IO_Error ou Last_SQL_Error en détail

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. Vérifiez le thread de vidage dans la bibliothèque principale

Vérifiez si le thread de vidage du journal binlog a été démarré correctement

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

Vous pouvez voir que la commande pour Binlog Dump est démarrée sur la ligne 2, prouvant que le fil de copie a été démarré avec succès

9. Résumé

Avantages

1. Technologie mature, relativement peu de BUG

2. Il n'y a aucune restriction sur SQLrequête, par exemple, tout le SQL ne peut pas être utilisé lors d'une copie basée sur GTID
   

Inconvénients

1. Il est difficile d'obtenir à nouveau le décalage de journal du nouveau maître lors du basculement

Dans un environnement mono-maître multi-esclave, si l'ancien maître tombe en panne, le cluster un nouveau Le maître est élu et les autres bibliothèques esclaves doivent resynchroniser le nouveau maître Étant donné que le journal binaire de chaque base de données existe indépendamment, il est difficile de trouver le point de journalisation où la synchronisation commence

.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!