Maison > base de données > tutoriel mysql > 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

WBOY
Libérer: 2022-04-15 18:29:01
avant
3133 Les gens l'ont consulté

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.

Explication détaillée de l'instance de réplication MySQL de la réplication GTID

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

  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 du 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 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
Copier après la connexion

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
Copier après la connexion

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)
Copier après la connexion

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
Copier après la connexion

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)
Copier après la connexion

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)
Copier après la connexion

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

mysql> insert into t_order values(4,"V");
Copier après la connexion

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)
Copier après la connexion

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");
Copier après la connexion

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)
Copier après la connexion

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.
Copier après la connexion

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';
Copier après la connexion

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

mysql> show variables like '%uuid%';
Copier après la connexion

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!

Étiquettes associées:
source:csdn.net
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal