Maison > Article > base de données > Explication détaillée de l'instance de réplication MySQL de la réplication GTID
Explication détaillée de l'instance de réplication MySQL de la réplication GTID
- WBOYavant
- 2022-04-15 18:29:013096parcourir
Cet article vous apporte des connaissances pertinentes sur mysql, qui présente principalement les problèmes liés à la réplication GTID. Le GTID est le numéro d'une transaction soumise et est un numéro unique au monde. Examinons-le ensemble. J'espère que cela aidera tout le monde.
Apprentissage recommandé : Tutoriel vidéo mysql
À partir de MySQL 5.6.5, une nouvelle méthode de réplication basée sur GTID a été ajoutée. GTID garantit que chaque transaction soumise sur la base de données principale possède un identifiant unique dans le cluster. Cette approche renforce les capacités de cohérence de la sauvegarde principale, de récupération après panne 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. TID représente le nombre de transactions qui ont été validées sur cette instance et augmente de façon monotone à mesure que les transactions sont validées.
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 le numéro de séquence de transaction de la même instance MySQL comporte plusieurs plages, séparez les plages par des 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. De plus, la réplication basée sur GTID peut ignorer les transactions déjà exécutées, réduisant ainsi le risque d'incohérence des donné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 lorsqu'il y a un maître et un esclave. Cependant, pour les structures avec plus de 2 maîtres, les avantages sont extrêmement évidents et le nouveau maître peut être changé 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 toujours à 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
- 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.
- Une fois le binlog transféré à l'esclave et stocké dans le relaylog de l'esclave, lisez la valeur du GTID et définissez la variable gtid_next, qui indique à l'esclave la prochaine valeur GTID à exécuter.
- 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.
- S'il y a un enregistrement, cela signifie que la transaction avec le GTID a été exécutée et l'esclave l'ignorera.
- S'il n'y a pas d'enregistrement, l'esclave exécutera la transaction GTID et enregistrera le GTID dans son propre binlog. 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
Le contenu du fichier de configuration my.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 de l'esclave
Le contenu du fichier de configuration my.cnf est cohérent avec celui du maître. Attention à modifier l'identifiant du serveur en. gardez-le 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.
Apprentissage recommandé : Tutoriel vidéo mysql
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!