Comment appliquer la réplication MySQL GTID

Depuis MySQL 5.6.5, une méthode de réplication basée sur l'identifiant de transaction global (GTID) a été introduite. GTID garantit que chaque transaction soumise à la base de données principale du cluster possède un identifiant unique. Cette méthode renforce les capacités de cohérence primaire et secondaire, de récupération des pannes et de tolérance aux pannes de la base de données.

Qu'est-ce que GTID

GTID (Global Transaction ID) est le numéro d'une transaction soumise et est un numéro unique au monde. GTID est en fait composé de UUID+TID. L'UUID est l'identifiant unique d'une instance MySQL. La valeur de TID augmente de manière monotone avec chaque transaction soumise, enregistrant le nombre de transactions qui ont été soumises sur cette instance.

Voici la forme spécifique d'un GTID : 3E11FA47-71CA-11E1-9E33-C80AA9429562:23. Les deux points séparent l'uuid à l'avant et le TID à l'arrière.

La collection GTID peut contenir des transactions de plusieurs instances MySQL, séparées par des virgules.

Si les plages de plusieurs numéros de séquence de transactions proviennent de la même instance MySQL, chaque plage doit être séparée par deux points. Par exemple : e6954592-8dba-11e6-af0e-fa163e1cf111:1-5:11-18,e6954592-8dba-11e6-af0e-fa163e1cf3f2:1-27.

Quelles sont les améliorations apportées au GTID

Dans la réplication binaire d'origine basée sur les journaux, la bibliothèque esclave doit informer la bibliothèque maître à partir de quel décalage effectuer la synchronisation incrémentielle. Si l'erreur spécifiée est spécifiée, les données seront omises. ce qui entraîne une incohérence des données. Avec l'aide du GTID, en cas de basculement maître-esclave, les autres bases de données esclaves de MySQL peuvent trouver automatiquement l'emplacement de réplication correct sur la nouvelle base de données maître, ce qui simplifie grandement la maintenance du cluster dans des topologies de réplication complexes et réduit l'apparition de réglage manuel des emplacements de réplication. Risque de mauvaise utilisation. L'utilisation de la réplication basée sur GTID réduit le risque d'incohérence des données en excluant les transactions déjà exécutées.

Basée sur l'ensemble gtid, la base de données principale peut savoir avec précision quelles données manquent dans la base de données esclave et ne fournira pas plus ou moins de données à la base de données esclave, évitant ainsi le gaspillage de bande passante réseau.

La structure maître-esclave MySQL n'a aucun avantage pour GTID dans le cas d'un maître et d'un esclave. Cependant, les avantages de la structure avec plus de 2 maîtres sont extrêmement évidents, et le nouveau maître peut être commuté sans perte de données.

Remarque : Avant de créer la réplication maître-esclave, effectuez certaines opérations (telles que le nettoyage des données, etc.) sur une instance qui deviendra le maître. Grâce à la réplication GTID, ces opérations avant l'établissement du maître-esclave seront également. copié sur l'esclave sur le serveur, provoquant l'échec de la réplication. Autrement dit, la réplication via GTID démarre à partir du premier journal de transactions, même si ces opérations sont effectuées avant la réplication. Par exemple, si vous effectuez des opérations de nettoyage de suppression et de suppression sur le serveur1, puis effectuez une opération de modification sur le serveur2, le serveur2 effectuera également des opérations de nettoyage sur le serveur1.

Comment fonctionne le GTID

1. Lorsqu'une transaction est exécutée et soumise du côté de la bibliothèque principale, un GTID est généré et enregistré dans le journal binlog.

2. Une fois le binlog transféré à l'esclave et stocké dans le relaylog de l'esclave, lisez la valeur de ce GTID et définissez la variable gtid_next, qui indique à l'esclave la prochaine valeur GTID à exécuter.

3. Le thread SQL obtient le GTID à partir du journal du relais, puis compare le binlog du côté esclave pour voir si le GTID existe.

4. S'il y a un enregistrement, cela signifie que la transaction avec le GTID a été exécutée et l'esclave l'ignorera.

5. S'il n'y a pas d'enregistrement, l'esclave exécutera la transaction GTID et enregistrera le GTID dans son propre journal binaire. Avant de lire et d'exécuter la transaction, il vérifiera d'abord si d'autres sessions détiennent le GTID pour s'assurer qu'il n'est pas exécuté. à plusieurs reprises.

Création d'une copie GTID maître et esclave

Planification de l'hôte :

• maître : docker, port 3312

• esclave : docker, port 3313

configuration principale fichier de configuration mon. Le contenu de cnf est le suivant :

$ cat /home/mysql/docker-data/3313/conf/my.cnf
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html

[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
#datadir=/home/mysql/docker-data/3307/data
#socket=/home/mysql/docker-data/3307/mysql.sock

character_set_server=utf8
init_connect='SET NAMES utf8'

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

#log-error=/home/mysql/docker-data/3307/logs/mysqld.log
#pid-file=/home/mysql/docker-data/3307/mysqld.pid
lower_case_table_names=1
server-id=1403311
log-bin=mysql-bin
binlog-format=ROW
auto_increment_increment=1
auto_increment_offset=1
# 开启gtid
gtid_mode=ON
enforce-gtid-consistency=true

#rpl_semi_sync_master_enabled=1
#rpl_semi_sync_master_timeout=10000

Créez une instance docker :

$ docker run --name mysql3312 -p 3312:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3312/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3312/data/:/var/lib/mysql -v /home/mysql/docker-data/3312/logs/:/var/log/mysql -d mysql:5.7

Ajoutez un utilisateur pour la réplication et autorisez :

mysql> GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO 'repluser'@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

configuration esclave

Le contenu du fichier de configuration my.cnf est cohérent avec celui du maître. modifiez l'identifiant du serveur pour le garder unique.

Créer une instance Docker :

$ docker run --name mysql3313 -p 3313:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3313/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3313/data/:/var/lib/mysql -v /home/mysql/docker-data/3313/logs/:/var/log/mysql -d mysql:5.7

Activer la synchronisation GTID :

mysql> change master to master_host='172.23.252.98',master_port=3310,master_user='repluser',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

Afficher l'état :

mysql> show master status;
+------------------+----------+--------------+------------------+----------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                      |
+------------------+----------+--------------+------------------+----------------------------------------+
| mysql-bin.000008 |      154 |              |                  | cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1 |
+------------------+----------+--------------+------------------+----------------------------------------+
1 row in set (0.00 sec)

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.23.252.98
                  Master_User: repluser
                  Master_Port: 3312
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000006
          Read_Master_Log_Pos: 419
               Relay_Log_File: 5dfbef024732-relay-bin.000003
                Relay_Log_Pos: 632
        Relay_Master_Log_File: mysql-bin.000006
             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: 419
              Relay_Log_Space: 846
              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: 1403311
                  Master_UUID: cd2eaa0a-7a59-11ec-b3b4-0242ac110002
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1
            Executed_Gtid_Set: cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

Insérer les données dans la table master.order :

mysql> insert into t_order values(4,"V");

Découvrir que les données ont été synchronisées avec l'esclave :

mysql> select * from order.t_order;
+------+------+
| id   | name |
+------+------+
|    4 | V    |
+------+------+
3 rows in set (0.00 sec)

Arrêter le esclave d'abord, puis dans le maître Insérez les données dans la table .order :

mysql> insert into t_order values(5,"X");

Démarrez ensuite l'esclave et constatez que les données ont été automatiquement synchronisées :

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> select * from order.t_order;
+------+------+
| id   | name |
+------+------+
|    4 | V    |
+------+------+
3 rows in set (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

mysql> select * from order.t_order;
+------+------+
| id   | name |
+------+------+
|    4 | V    |
|    5 | X    |
+------+------+
4 rows in set (0.00 sec)

Problèmes rencontrés

Afficher l'état de l'esclave sur le serveur esclave :

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

Vérifiez d'abord si les server_id du maître et de l'esclave sont cohérents. Si modifiez de manière cohérente le champ server_id dans le fichier my.cnf :

mysql> show variables like 'server_id';

Vérifiez ensuite si les uuid du maître et de l'esclave sont cohérents :

mysql> show variables like '%uuid%';

Si l'uuid est cohérent, modifiez le fichier auto.cnf dans le répertoire data, copiez l'intégralité du répertoire data et mettez auto Le fichier cnf a également été copié, qui enregistre l'uuid de la base de données. L'uuid de chaque bibliothèque doit être différent.

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!