Tutoriel d'exemple de soumission de groupe MySQL5.7 et de réplication parallèle

Depuis la version 5.5 de MySQL, le mécanisme de réplication parallèle a été introduit, ce qui est une fonctionnalité très importante de MySQL.

MySQL 5.6 commence à prendre en charge la réplication parallèle avec le schéma comme dimension. Autrement dit, si l'événement de ligne binlog opère sur des objets de schémas différents, la réplication parallèle peut être réalisée s'il est déterminé qu'il n'y a pas de DDL ni d'étranger. dépendances clés.

La communauté a également introduit une version de réplication parallèle avec des tables comme dimensions ou des enregistrements comme dimensions. Qu'il s'agisse d'un schéma, d'une table ou d'un enregistrement, elle s'appuie sur la base de données esclave analysant les événements au format ligne en temps réel. pour le jugement, en s'assurant qu'il n'y a pas de conflits, la distribution est effectuée pour réaliser le parallélisme.

Réplication parallèle de MySQL5.7, l'esclave multithread est MTS, il est prévu de maximiser le parallélisme de la base de données principale. La façon d'y parvenir est d'ajouter les informations nécessaires à l'événement binlog afin que l'esclave. Le nœud peut réaliser le parallélisme sur la base de cette copie d'informations.

La réplication parallèle de MySQL 5.7 est basée sur une validation de groupe. Toutes les instructions préparées qui peuvent être complétées sur la base de données principale indiquent qu'il n'y a pas de conflit de données et peuvent être répliquées en parallèle sur le nœud esclave.

Concernant la soumission de groupe de MySQL5.7, nous devons examiner les paramètres suivants :

mysql> show global variables like '%group_commit%';+-----------------------------------------+-------+| Variable_name | Value |+-----------------------------------------+-------+| binlog_group_commit_sync_delay | 0 || binlog_group_commit_sync_no_delay_count | 0 |+-----------------------------------------+-------+2 rows in set (0.00 sec)

binlog_group_commit_sync_delay Ce paramètre contrôle le temps d'attente pour la soumission du journal avant de vider le disque. La valeur par défaut est 0, ce qui signifie que le disque est vidé immédiatement après la soumission. Lorsqu'il est défini au-dessus de 0, il permet aux collègues du journal de plusieurs éléments de soumettre. vidage en même temps. C'est ce que nous appelons la soumission de groupe. La soumission de groupe est la base de la réplication parallèle. Si nous définissons cette valeur supérieure à 0, cela signifie que la fonction de soumission de groupe est activée. La valeur maximale ne peut être définie que sur 1 000 000 microsecondes.

binlog_group_commit_sync_no_delay_count, ce paramètre signifie que pendant le temps d'attente de binlog_group_commit_sync_delay, si le nombre de choses atteint le paramètre défini par binlog_group_commit_sync_no_delay_count, une soumission de groupe sera déclenchée. Si cette valeur est définie sur 0, là. n'aura aucune influence. Si l'heure est atteinte mais que le nombre de transactions n'a pas été atteint, une opération de soumission groupée sera également effectuée.

La soumission de groupe est une manière plus amusante. Nous pouvons voir sur quoi repose la soumission de groupe sur la base du binlog de MySQL :

[root@mxqmongodb2 log]# mysqlbinlog mysql-bin.000005 |grep last_committed
#170607 11:24:57 server id 353306 end_log_pos 876350 CRC32 0x92093332 GTID last_committed=654 sequence_number=655#170607 11:24:58 server id 353306 end_log_pos 880406 CRC32 0x344fdf71 GTID last_committed=655 sequence_number=656#170607 11:24:58 server id 353306 end_log_pos 888700 CRC32 0x4ba2b05b GTID last_committed=656 sequence_number=657#170607 11:24:58 server id 353306 end_log_pos 890675 CRC32 0xf8a8ad64 GTID last_committed=657 sequence_number=658#170607 11:24:58 server id 353306 end_log_pos 892770 CRC32 0x127f9cdd GTID last_committed=658 sequence_number=659#170607 11:24:58 server id 353306 end_log_pos 894757 CRC32 0x518abd93 GTID last_committed=659 sequence_number=660#170607 11:37:46 server id 353306 end_log_pos 895620 CRC32 0x99174f95 GTID last_committed=660 sequence_number=661#170607 11:37:51 server id 353306 end_log_pos 895897 CRC32 0xb4ffc341 GTID last_committed=661 sequence_number=662#170607 11:38:00 server id 353306 end_log_pos 896174 CRC32 0x6bcbc492 GTID last_committed=662 sequence_number=663#170607 11:39:40 server id 353306 end_log_pos 896365 CRC32 0x1fe16c7c GTID last_committed=663 sequence_number=664

Ce qui précède est un journal sans soumission de groupe activée. Nous pouvons voir qu'il y a deux paramètres last_commit et séquence_number dans le binlog. Nous pouvons voir que la chose suivante est

Après avoir configuré la soumission de groupe. dans la bibliothèque principale, nous devons ajouter les paramètres suivants à la bibliothèque esclave : last_commit est toujours égal au numéro de séquence de l'élément précédent. C'est également facile à comprendre, car les choses sont soumises séquentiellement, ce n'est donc pas surprenant à comprendre.

Voici un aperçu des choses en mode soumission de groupe :

[root@mxqmongodb2 log]# mysqlbinlog mysql-bin.000008|grep last_commit
#170609 10:11:07 server id 353306 end_log_pos 75629 CRC32 0xd54f2604 GTID last_committed=269 sequence_number=270#170609 10:13:03 server id 353306 end_log_pos 75912 CRC32 0x43675b14 GTID last_committed=270 sequence_number=271#170609 10:13:24 server id 353306 end_log_pos 76195 CRC32 0x4f843438 GTID last_committed=270 sequence_number=272

Nous pouvons voir les deux dernières choses Le dernier_commis est le même. Qu'est-ce que cela signifie ? Cela signifie que deux choses sont soumises en tant que groupe. Les deux choses obtiennent le même dernier_commis par troncature effectuée et ne s'affectent pas l'une l'autre. C’est ce qu’on appelle la soumission de groupe.

#MTS
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8 #太多的线程会增加线程间同步的开销，建议4-8个slave线程
master_info_repository=TABLErelay_log_info_repository=TABLErelay_log_recovery=ONslave-parallel-type有两个之，DATABASE和LOGICAL_CLOCK，DATABASE： 默认值，兼容5.6以schema维度的并行复制， LOGICAL_CLOCK： MySQL 5.7基于组提交的并行复制机制。

En résumé, la réplication parallèle de MySQL5.7 est basée sur le commit de groupe de la bibliothèque principale et la configuration des paramètres suivants de la bibliothèque esclave : mysql> affiche des variables comme '% slave_para%';

+------------------------+---------------+| Variable_name | Value |+------------------------+---------------+| slave_parallel_type | LOGICAL_CLOCK || slave_parallel_workers | 8 |+------------------------+---------------+2 rows in set (0.01 sec)

Pour utiliser la réplication parallèle de MySQL5.7, vous devez d'abord définir binlog_group_commit_sync_delay supérieur à 0 dans la bibliothèque principale, puis définissez le fil dans la bibliothèque esclave Numéros et méthodes associées. Ce que nous avons défini ci-dessus est 8, et vous pouvez voir dans la bibliothèque esclave que

mysql> show processlist;+----+-------------+--------------------+------+---------+--------+--------------------------------------------------------+------------------+| Id | User        | Host               | db   | Command | Time   | State                                                  | Info             |+----+-------------+--------------------+------+---------+--------+--------------------------------------------------------+------------------+|  1 | system user |                    | NULL | Connect | 373198 | Waiting for master to send event                       | NULL             ||  2 | system user |                    | NULL | Connect |   1197 | Slave has read all relay log; waiting for more updates | NULL             ||  4 | system user |                    | NULL | Connect |   4292 | Waiting for an event from Coordinator                  | NULL             ||  5 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             ||  6 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             ||  7 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             ||  8 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             ||  9 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             || 10 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             || 11 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             || 16 | root        | 10.103.16.34:37263 | NULL | Query   |      0 | starting                                               | show processlist |+----+-------------+--------------------+------+---------+--------+--------------------------------------------------------+------------------+

la bibliothèque esclave aura huit threads en attente de traitement des transactions, au lieu d'un seul.

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!