Introduction détaillée à la méthode de configuration de la réplication maître-esclave multithread sur les nœuds esclaves Mysql5.7

Cet article présente principalement les informations pertinentes sur la réplication maître-esclave multithread de la configuration du nœud esclave Mysql. L'introduction dans l'article est très détaillée et a une certaine valeur de référence pour tous les amis qui en ont besoin. pouvez venir nous rejoindre.

Avant-propos

Mysql utilise le multithreading pour la réplication, qui est pris en charge à partir de Mysql 5.6, mais il y a des défauts dans la version 5.6. Bien qu'il prenne en charge plusieurs threads, chaque base de données ne peut avoir qu'un seul thread, c'est-à-dire que si nous n'avons qu'une seule base de données, un seul thread fonctionnera pendant la réplication maître-esclave. C'est l'équivalent du thread unique précédent. À partir de Mysql 5.7, la réplication parallèle maître-esclave sous la même base de données est prise en charge. Cependant, par défaut, il s'agit toujours d'une seule base de données et d'un seul thread. Si vous devez utiliser plusieurs threads, vous devez le configurer sur le nœud esclave.

Mysql 5.7 ajoute un type de réplication maître-esclave, il en existe deux types, comme suit :

• Réplication parallèle basée sur la bibliothèque DATABASE, Chaque base de données correspond à un thread de réplication

• LOGICAL_CLOCK Méthode de réplication parallèle basée sur la soumission de groupe, il peut y avoir plusieurs threads sous la même base de données
  

Configurez les étapes suivantes sur le nœud esclave.

Afficher la configuration actuelle

Avant de démarrer la configuration, jetons un œil au nombre de processus de réplication maître-esclave sous la configuration actuelle.

mysql> show processlist;
+----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
| Id | User  | Host  | db | Command | Time | State             | Info    |
+----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
| 1 | system user |   | NULL | Connect | 91749 | Waiting for master to send event      | NULL    |
| 2 | system user |   | NULL | Connect | 208 | Slave has read all relay log; waiting for more updates | NULL    |
| 37 | root  | localhost | NULL | Query |  0 | starting            | show processlist |
+----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

Il ressort de ce qui précède qu'il n'y a qu'un seul processus principal en attente de synchronisation.

Vérifiez le type de réplication et la configuration du numéro parallèle ci-dessous

mysql> show variables like 'slave_parallel_type';
+---------------------+----------+
| Variable_name  | Value |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.00 sec)

Le type de réplication actuel est DATABASE, qui se trouve sous le base de données unifiée Un seul thread effectue la copie, la copie parallèle n'est pas possible.

mysql> show variables like 'slave_parallel_workers';
+------------------------+-------+
| Variable_name   | Value |
+------------------------+-------+
| slave_parallel_workers | 0  |
+------------------------+-------+
1 row in set (0.01 sec)

Le nombre actuel de processus fonctionnant en parallèle est de 0

Configurer le multi-threading

1. Arrêtez la réplication à partir du nœud esclave

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

2. Définissez le type de réplication sur LOGICAL_CLOCK

<.>

mysql> set global slave_parallel_type='logical_clock';
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'slave_parallel_type';
+---------------------+---------------+
| Variable_name  | Value   |
+---------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
+---------------------+---------------+
1 row in set (0.01 sec)

3. Définissez le numéro parallèle sur 4

mysql> set global slave_parallel_workers=4;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'slave_parallel_workers';
+------------------------+-------+
| Variable_name   | Value |
+------------------------+-------+
| slave_parallel_workers | 4  |
+------------------------+-------+
1 row in set (0.00 sec)

4. Démarrez la réplication du nœud esclave

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

5. Vérifiez le nombre de threads qui fonctionnent actuellement

mysql> show processlist;
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
| Id | User  | Host  | db | Command | Time | State             | Info    |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
| 37 | root  | localhost | NULL | Query | 0 | starting            | show processlist |
| 38 | system user |   | NULL | Connect | 8 | Waiting for master to send event      | NULL    |
| 39 | system user |   | NULL | Connect | 7 | Slave has read all relay log; waiting for more updates | NULL    |
| 40 | system user |   | NULL | Connect | 8 | Waiting for an event from Coordinator     | NULL    |
| 41 | system user |   | NULL | Connect | 8 | Waiting for an event from Coordinator     | NULL    |
| 42 | system user |   | NULL | Connect | 8 | Waiting for an event from Coordinator     | NULL    |
| 43 | system user |   | NULL | Connect | 8 | Waiting for an event from Coordinator     | NULL    |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
7 rows in set (0.00 sec)

Enfin, pourquoi la réplication multi-thread est-elle nécessaire ? Puisqu'il y aura un délai de synchronisation entre le maître et l'esclave, le but du multithreading est de minimiser ce délai. Bien que l'optimisation maître-esclave soit une fonction du système et que différents scénarios nécessitent des solutions différentes, le multithreading peut au moins fondamentalement réduire la latence. De plus, selon la situation réelle de la base de données, si elle peut réellement réduire le délai et combien de threads configurer, vous devez tester à plusieurs reprises pour obtenir les données qui vous conviennent.

Résumé

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!