Réplication GTID et gestion des problèmes

Tout d'abord, jetons un coup d'œil à ce qu'est le 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. Sur la base du GTID, vous pouvez savoir sur quelle instance la transaction a été initialement soumise, ce qui facilite le basculement.

Voyons ensuite comment ajouter rapidement un esclave en mode GTID :

Nous savons qu'avant qu'il n'y ait pas de réplication GTID, la réplication MySQL était basée sur le journal binaire et la position sont terminées. Pour la copie précédente, nous devons exécuter l'instruction de modification suivante :

CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='*****',MASTER_LOG_FILE='mysqlbinlog.000003',MASTER_LOG_POS=99721204;

Et nous pouvons exécuter l'instruction de modification suivante dans GTID :

CHANGE MASTER TO  MASTER_HOST='****', MASTER_USER='repl',  MASTER_PASSWORD='******',  MASTER_PORT=3306,  master_auto_position=1;

Nous pouvons voir que fondamentalement, la méthode de journalisation binaire d'origine nécessite de spécifier MASTER_LOG_FILE et MASTER_LOG_POS lors de la spécification de la réplication, mais la réplication GTID n'a pas besoin de les connaître. paramètres.

Voyons comment créer une réplication maître-esclave en mode GTID :

Comme vous pouvez le voir ci-dessus, en mode GTID, nous n'avons plus besoin de connaître les deux paramètres MASTER_LOG_FILE et MASTER_LOG_POS. En revanche, il suffit de spécifier le maître, ce qui est beaucoup plus simple pour créer une réplication. En mode GTID, nous devons connaître les deux

variables globales suivantes :

root@perconatest09:23:44>show global variables like 'GTID_%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24*************************** 2. row ***************************Variable_name: gtid_executed_compression_period
Value: 1000*************************** 3. row ***************************Variable_name: gtid_mode
Value: ON*************************** 4. row ***************************Variable_name: gtid_owned
Value:*************************** 5. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-12

Ce que nous avons principalement besoin de voir, ce sont les deux paramètres gtid_executed et gtid_purged

gtid_executed : Il s'agit d'une série de GTID de tout ce qui a été exécuté. le numéro de série des éléments qui ont été placés dans le journal binaire. Ce paramètre est en lecture seule et ne peut pas être défini.

gtid_purged : Cette séquence fait référence au numéro de séquence du GTID de la chose que nous supprimons

dans le journal binaire . Nous pouvons le configurer manuellement pour faciliter une certaine gestion.

Après avoir compris ces deux paramètres, voyons comment ajouter une base de données esclave avec réplication GTID :

(1) : Faire une sauvegarde complète de la base de données maître, et enregistrer la base de données maître base de données gtid_executed

(2) au moment de la sauvegarde de la bibliothèque : restaurez à partir de la bibliothèque et définissez le gtid_purged de la bibliothèque sur le gtid_executed

(3) du maître que nous avons obtenu dans le premier étape : exécutez l'instruction CHANGE MASTER.

Nous

utilisons mysqldump pour sauvegarder la base de données principale et restaurer la sauvegarde sur une nouvelle machine en tant que base de données esclave. Avant d'exécuter, jetez un œil aux paramètres dans la bibliothèque principale :

root@perconatest09:23:58>show global variables like 'GTID_e%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-242 rows in set (0.01 sec)
root@perconatest09:41:33>show global variables like 'GTID_p%'\G*************************** 1. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-121 row in set (0.01 sec)

Ensuite faites une sauvegarde dans la base de données principale :

mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --port=18675 --user=root--p > /home/sa/backup.sql

On peut jeter un oeil au fichier de sauvegarde :

[root@localhost sa]# head -30 backup.sql

On peut voir les paramètres suivants :

SET @@GLOBAL.GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

C'est-à-dire que lorsque nous restaurons, GTID_PURGED sera automatiquement défini, et cette valeur se trouve être le gtid_executed du maître, nous n'avons donc fondamentalement pas besoin de le spécifier après la restauration à partir de la bibliothèque .

Entrez la récupération des données de la base de données :

source backup.sql;

Nous savons qu'il n'est pas nécessaire de spécifier la valeur de GTID_PURGE Si vous n'êtes pas sûr. , vous pouvez le confirmer :

show global variables like 'gtid_executed';
show global variables like 'gtid_purged';

Il suffit de préciser la copie plus tard :

CHANGE MASTER TO MASTER_HOST="***", MASTER_USER="root", MASTER_PASSWORD="*****", MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;

Remplacer * par le hôte que vous devez spécifier. Les informations pertinentes de la bibliothèque sont OK.

Si une erreur se produit en mode de réplication maître-esclave GTID, comment devons-nous la récupérer ?

Si les logs de notre bibliothèque principale ont été purgés et que des opérations telles que

réinitialisation sont effectuées, notre bibliothèque esclave signalera l'erreur suivante :

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

nous indique que le journal est introuvable et que la réplication maître-esclave s'arrêtera. Jetons un coup d'œil au traitement. méthode :

(1) La bibliothèque principale effectue les opérations suivantes :

root@perconatest09:41:38>show global variables like 'GTID_EXECUTED';+---------------+---------------------------------------------------------------------------------------------------------------------------------+| Variable_name | Value |+---------------+---------------------------------------------------------------------------------------------------------------------------------+| gtid_executed | 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24 |+---------------+---------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.01 sec)

(2) De la bibliothèque

root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

Remarque, Avant de préciser, vous devez d'abord confirmer que cette valeur est vide, sinon nous devons faire ce qui suit :

root@(none)03:04:49>reset master;
root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';
root@(none)03:04:49>start slave;
root@(none)03:04:49>show slave status\G

La réparation est terminée, mais nous ferions mieux d'utiliser la somme de contrôle pour vérifier la cohérence des données maître-esclave.

Message d'erreur :

J'ai obtenu l'erreur fatale 1236 du maître lors de la lecture des données du journal binaire : "L'esclave se connecte en utilisant CHANGE MASTER TO MASTER_AUTO_POSITION = 1, mais le maître a purgé les journaux binaires contenant les GTID dont l'esclave a besoin

(Publié Message d'erreurAfin d'augmenter le nombre de vues)

Bien sûr, la méthode ci-dessus ne garantit pas la cohérence complète des données. Nous devons également vérifier à l'aide de pt-table-checksum et. pt-table-sync, mais ce n'est pas nécessairement le plus efficace. Le meilleur moyen est de faire une sauvegarde complète, puis de restaurer, puis de spécifier le maître comme indiqué précédemment. C'est le plus fiable.

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!