Dans cet article, nous allons nous intéresser à la migration de la réplication traditionnelle vers GTID,
nous verrons comment le faire entièrement en ligne. Tout d'abord, discutons de certaines options de configuration liées au GTID. Le mode GTID détermine que le serveur utilise ou non les GTID, cela affecte non seulement la connexion binaire de réplication, car les journaux binaires contiendront des GTID. L'option d'application de la cohérence GTID garantit que le serveur n'autorise que les instructions pouvant être exécutées en toute sécurité en mode GTID. Les instructions qui ne sont pas sûres à exécuter sont comme créer une table en tant que sélection, il y en a quelques autres principalement autour, pour la valeur gtid_owned, elles peuvent surveiller les GTID sur les transactions en cours. Ceci est très utile lorsqu'ils désactivent les GTID en ligne.
Discutons-en quelques-uns et pour être exact, il ne s'agit que d'une variable d'état liée au GTID. Le ONGOING_ANONYMOUS_TRANSACTION_ COUNT est la contrepartie du GTID détenu mais en cas de migration comme à propos du ONGOING_ANONYMOUS_TRANSACTION_COUNT, il est appelé transaction anonyme car il n'a pas d'identifiant qui est le GTID.
Toutes les opérations doivent être effectuées sur l'un des nœuds de la topologie de réplication et éventuellement sur tous les nœuds. La meilleure pratique consiste à faire d'abord l'esclave et le maître, mais dans le cas d'un grand nombre d'opérations, l'ordre n'a pas vraiment d'importance tant qu'elles sont effectuées sur chaque instance de la topologie de réplication.
Dans cet environnement, j'ai trois machines virtuelles, deux d'entre elles sont des bases de données et l'une d'entre elles est une machine sysbench pour générer du trafic alors commençons.
Maître :192.168.66.5
Esclave : 192.168.66.7
Sur le nœud sysbench, exécutons la commande préparée pour créer une base de données sysbench, vous pouvez simplement la copier-coller ci-dessous.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password= password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare
Sur le nœud sysbench, une charge de travail est exécutée sur le maître que nous exécutons pendant la durée de la tâche.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --rate=10 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run
Démarrons le client MySQL sur tous les nœuds, tous les nœuds de la base de données. Vérifions la liste des processus d'affichage sur le maître afin que vous puissiez voir que cela s'exécute ici.
mysql> show processlist; +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 2350 | Waiting on empty queue | NULL | | 8 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 15 | syncstndby | 192.168.66.7:47894 | NULL | Binlog Dump | 156 | Master has sent all binlog to slave; waiting for more updates | NULL | | 17 | sbtest_user | 192.168.66.6:38130 | sbtest | Sleep | 0 | | NULL | | 18 | sbtest_user | 192.168.66.6:38132 | sbtest | Sleep | 1 | | NULL | | 19 | sbtest_user | 192.168.66.6:38134 | sbtest | Sleep | 0 | | NULL | | 20 | sbtest_user | 192.168.66.6:38136 | sbtest | Sleep | 0 | | NULL | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ 7 rows in set (0.00 sec)
D'accord, à partir de maintenant, nous travaillerons d'abord avec le baume et le maître.
Donc, d'abord, nous allons définir l'enforce_gtid_consistency ='warn' sur l'esclave, sur le maître esclave.
Esclave 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Maître 192.168.66.5
set global enforce_gtid_consistency = 'warn';
nous avons terminé ici et nous allons vérifier l'erreur MySQL voir le journal des erreurs cela devrait être bon; vous ne verrez aucune erreur dans le journal des erreurs. L'étape suivante consiste à exécuter set global apply_gtid_consistency='on' partout, puis à vérifier à nouveau la flèche.
Esclave 192.168.66.7
set global enforce_gtid_consistency='on';
Maître 192.168.66.5
set global enforce_gtid_consistency='on';
Ainsi, la prochaine étape consiste à définir global gtid_mode='off_permissive' ; donc encore une fois, je vais démarrer le client MySQL et le configurer. Et puis nous vérifions le journal des erreurs
Esclave 192.168.66.7
set global gtid_mode='off_permissive';
Maître 192.168.66.5
set global gtid_mode='off_permissive';
Sur chaque serveur, nous définirons le gtid_mode='on_permissive' ; de sorte que nous générons des transactions GTID à ce stade.
Esclave 192.168.66.7
set global gtid_mode='on_permissive';
Maître 192.168.66.5
set global gtid_mode='on_permissive';
Donc, c'est installé partout. Vérifions les journaux d'erreurs
Très bien, nous allons maintenant vérifier si l'un des nœuds a des transactions anonymes en cours, car si c'est le cas, lorsque nous définissons gtid_mode='on', le serveur n'accepte plus les transactions anonymes et nous obtiendrons des erreurs.
Esclave 192.168.66.7
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.22 sec)
Maître 192.168.66.5
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.04 sec)
Donc, les deux serveurs n'ont pas ce qui signifie que nous sommes prêts à activer les GTID. Je vais activer gtid_mode =on.
Maître 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Esclave 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Maintenant sur les esclaves, nous devons réinitialiser la réplication pour utiliser master-auto-position=1
Esclave 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Donc, qu'est-ce que cela fait, ce "change master" ici, si le thread salve était déjà configuré, alors si un paramètre n'est pas touché par la commande change master, il sera simplement laissé à la valeur actuelle.
Vérifions afficher l'état de l'esclave sur les esclaves et afficher l'état du maître sur le maître. tout devrait bien fonctionner.
mysql> show salve status\G; mysql> show master status;
La migration est maintenant terminée :
Comme nous savons qu'aucune mise à niveau ne réussit si vous n'avez pas de plan de restauration, pour revenir en arrière, veuillez cliquer sur le lien ci-dessous pour lire l'article suivant.
Revenir à la réplication traditionnelle à partir de GTID
