Le nœud MASTER ne renvoie pas immédiatement les résultats au client après l'exécution de la transaction soumise par le client, mais attend qu'au moins un nœud SLAVE reçoive et écrivez-le dans le journal du relais avant de revenir au client. MASTER节点在执行完客户端提交的事务后不是立刻返回结果给客户端，而是等待至少一个SLAVE节点接收并写到relay log中才返回给客户端。
半同步相对于异步复制而言，提高了数据的安全性，同时也造成了一定程度的延迟，这个延迟最少是一个TCP往返的时间。所以，半同步复制最好在低延时的网络中使用。
MySQL从5.5开始就支持半同步复制，在5.7.2版本的时候对半同步复制进行了一次改进；原先的半同步策略为 AFTER_COMMIT 改进后的策略为 AFTER_SYNC 两者的差异在于SLAVE节点ACK应答MASTER的时机不同。
AFTER_COMMIT 模式介绍
MASTER将每个事务写入到二进制日志并刷盘保存，同时将事务发送给SLAVE，然后将事务提交给存储引擎处理并进行提交，然后等待SLAVE返回确认信息，在收到确认信息后，MASTER将结果返回给客户端，然后当前客户端可以继续工作。
AFTER_SYNC 模式介绍
MASTER将每个事务写入到二进制日志并刷盘保存，同时将事务发送给SLAVE，然后等待SLAVE返回确认信息，收到确认信息后，将事务提交给存储引擎处理并进行提交，并将结果返回给客户端，然后当前客户端可以继续工作。
对于第一种 AFTER_COMMIT 方式，当前客户端只有在服务器向存储引擎提交数据并收到SLAVE返回的确认后，才会收到事务的返回结果。在事务提交之后收到SLAVE返回确认信息之前，此刻其他客户端可以看到当前客户端提交的事务信息。
如果SLAVE节点由于网络等原因并未收到MASTER节点传递过来的事务，而MASTER节点此刻crash了。HA进行故障转移，客户端都连到SLAVE节点上，这时先前在MASTER节点看到的事务在SLAVE节点并未看到，就会发生事务丢失的情况。
对于第二种 AFTER_SYNC 方式，当事务被SLAVE确认后MASTER在存储引擎层面进行提交事务后，所有客户端才能看到事务造成的数据更改。因此，所有客户端在MASTER上同一时刻看到是相同的数据。
当MASTER节点crash的情况下，所有在MASTER上提交的事务都被复制到SLAVE(保存到中继日志中)。 MASTER服务器意外crash。此刻HA进行故障转移到SALVE后，客户端看到的数据是无损的，因为SLAVE是最新的。
注意，然而，在这种情况下，MASTER不能直接恢复使用，因为它的二进制日志可能包含未提交的事务，此刻当二进制日志恢复并用于业务需求时，可能会导致与SLAVE的冲突。
方式1：半同步以插件的形式存在，咱们可以直接在线开启即可（本次采用这次方式）
主节点开启：
[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; Query OK, 0 rows affected (0.02 sec)
从节点开启：
[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; Query OK, 0 rows affected (0.02 sec)
PS：一般情况下所有节点都同步部署master和slave插件，这样故障切换的时候会比较方便处理
方式2：在my.cnf配置中进行开启
主从节点都同步配置开启：
plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_sync_slave=semisync_slave.so" rpl_semi_sync_master_enabled=1 rpl_semi_sync_slave_enabled=1
方式1：查询plugin
主节点查看：
[root@GreatSQL][test]>show plugins; | rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
从节点查看：
[root@GreatSQL][(none)]>show plugins; | rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |
方式二：查询information_schema.plugins
Par rapport à la réplication asynchrone, la semi-synchronisation améliore la sécurité des données, mais entraîne également un certain degré de retard. Ce délai est d'au moins un temps d'aller-retour TCP. Par conséquent, la réplication semi-synchrone est mieux utilisée dans les réseaux à faible latence.
MySQL prend en charge la réplication semi-synchrone depuis la version 5.5. La réplication semi-synchrone a été améliorée dans la version 5.7.2 ; la stratégie semi-synchrone d'origine est AFTER_COMMIT et la stratégie améliorée est AFTER_SYNC. Le timing de la réponse ACK du nœud SLAVE au MASTER est différent. 2. Introduction aux deux modesAFTER_COMMIT Introduction au mode
MASTER écrit chaque transaction dans le journal binaire et le vide pour la sauvegarder En même temps, il l'envoie. la transaction à SLAVE, puis envoie la transaction Submit au moteur de stockage pour traitement et soumission, puis attend que SLAVE renvoie les informations de confirmation. Après avoir reçu les informations de confirmation, MASTER renvoie le résultat au client, puis le client actuel peut. continuer à travailler.AFTER_SYNC
Introduction au modeMASTER écrit chaque transaction dans le journal binaire et l'enregistre sur le disque. En même temps, il envoie la transaction à SLAVE, puis attend que SLAVE renvoie les informations de confirmation après avoir reçu les informations de confirmation. , il soumet la transaction au moteur de stockage Process and submit, renvoyant les résultats au client, et le client actuel peut continuer à travailler. 3. Comparaison des deux méthodesPour la première méthode AFTER_COMMIT , le client actuel ne recevra la transaction qu'après que le serveur aura soumis les données au moteur de stockage et reçu la confirmation renvoyée par SLAVE Return. résultats. Avant de recevoir les informations de confirmation de SLAVE après la soumission de la transaction, les autres clients peuvent voir les informations de transaction soumises par le client actuel à ce moment-là.
Si le nœud SLAVE ne reçoit pas la transaction transmise par le nœud MASTER pour des raisons de réseau et pour d'autres raisons, et que le nœud MASTER plante à ce moment-là. HA effectue un basculement et les clients sont connectés au nœud SLAVE. À ce stade, la transaction précédemment vue sur le nœud MASTER n'est pas vue sur le nœud SLAVE et la transaction sera perdue.
AFTER_SYNC, lorsque la transaction est confirmée par SLAVE et que MASTER valide la transaction au niveau du moteur de stockage, tous les clients peuvent voir les modifications de données provoquées par la transaction. Par conséquent, tous les clients voient les mêmes données sur le MASTER en même temps. 4. Comment activer la semi-synchronisation
Méthode 1 :
La semi-synchronisation existe sous la forme d'un plug-in Nous pouvons l'activer directement en ligne (cette fois nous utilisons cette méthode)(Thu Feb 17 03:03:12 2022)[root@GreatSQL][(none)]>select * from information_schema.plugins where plugin_name like "%semi%"\G;
*************************** 1. row ***************************
PLUGIN_NAME: rpl_semi_sync_master
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: ACTIVE
PLUGIN_TYPE: REPLICATION
PLUGIN_TYPE_VERSION: 4.0
PLUGIN_LIBRARY: semisync_master.so
PLUGIN_LIBRARY_VERSION: 1.10
PLUGIN_AUTHOR: Oracle Corporation
PLUGIN_DESCRIPTION: Semi-synchronous replication master
PLUGIN_LICENSE: GPL
LOAD_OPTION: ON
1 row in set (0.00 sec)
ERROR:
No query specified
# 从节点信息
(Thu Feb 17 16:05:19 2022)[root@GreatSQL][(none)]>select * from information_schema.plugins where plugin_name like "%semi%"\G;
*************************** 1. row ***************************
PLUGIN_NAME: rpl_semi_sync_slave
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: ACTIVE
PLUGIN_TYPE: REPLICATION
PLUGIN_TYPE_VERSION: 4.0
PLUGIN_LIBRARY: semisync_slave.so
PLUGIN_LIBRARY_VERSION: 1.10
PLUGIN_AUTHOR: Oracle Corporation
PLUGIN_DESCRIPTION: Semi-synchronous replication slave
PLUGIN_LICENSE: GPL
LOAD_OPTION: ON
1 row in set (0.00 sec[root@GreatSQL][test]>SET GLOBAL rpl_semi_sync_master_enabled = on; Query OK, 0 rows affected (0.00 sec)
PS : Généralement, tous les nœuds déploient les plug-ins maître et esclave simultanément, afin que le basculement soit plus pratique
Méthode 2 : Dans ma configuration Ouvrir dans .cnf
Les nœuds maître et esclave sont configurés pour s'ouvrir de manière synchrone :t@GreatSQL][(none)]>SET GLOBAL rpl_semi_sync_slave_enabled = on;
Query OK, 0 rows affected (0.00 sec)
Méthode 1 :
(Mon Feb 14 15:19:58 2022)[root@GreatSQL][(none)]> (Mon Feb 14 15:19:58 2022)[root@GreatSQL][(none)]>STOP SLAVE IO_THREAD; Query OK, 0 rows affected, 1 warning (0.01 sec) (Mon Feb 14 15:21:41 2022)[root@GreatSQL][(none)]>START SLAVE IO_THREAD; Query OK, 0 rows affected, 1 warning (0.01 sec)
[root@GreatSQL][test]>show status like 'Rpl_semi_sync_master_status'; +-----------------------------+-------+ | Variable_name | Value | +-----------------------------+-------+ | Rpl_semi_sync_master_status | ON | +-----------------------------+-------+ 1 row in set (0.00 sec)
information_schema.plugins pour des informations plus complètes 🎜🎜🎜Informations sur le nœud maître : 🎜🎜[root@GreatSQL][(none)]>show status like 'Rpl_semi_sync_slave_status'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | ON | +----------------------------+-------+ 1 row in set (0.01 sec)
# 关键信息 Start semi-sync binlog_dump to slave (server_id: 3306) 2022-02-14T02:16:35.411061-05:00 13 [Note] [MY-010014] [Repl] While initializing dump thread for slave with UUID <652ade08-8b1c-11ec-9f62-00155dcff90a>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(12). 2022-02-14T02:16:35.411236-05:00 13 [Note] [MY-010462] [Repl] Start binlog_dump to master_thread_id(13) slave_server(3306), pos(, 4) 2022-02-14T02:16:35.411263-05:00 13 [Note] [MY-011170] [Repl] Start asynchronous binlog_dump to slave (server_id: 3306), pos(, 4). 2022-02-14T02:16:35.411419-05:00 12 [Note] [MY-011171] [Repl] Stop asynchronous binlog_dump to slave (server_id: 3306). 2022-02-14T02:19:33.913084-05:00 9 [Note] [MY-011130] [Repl] Semi-sync replication initialized for transactions. 2022-02-14T02:19:33.913133-05:00 9 [Note] [MY-011142] [Repl] Semi-sync replication enabled on the master. 2022-02-14T02:19:33.913638-05:00 0 [Note] [MY-011166] [Repl] Starting ack receiver thread. 2022-02-14T02:21:46.899725-05:00 14 [Note] [MY-010014] [Repl] While initializing dump thread for slave with UUID <652ade08-8b1c-11ec-9f62-00155dcff90a>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(13). 2022-02-14T02:21:46.899894-05:00 14 [Note] [MY-010462] [Repl] Start binlog_dump to master_thread_id(14) slave_server(3306), pos(, 4) 2022-02-14T02:21:46.899953-05:00 14 [Note] [MY-011170] [Repl] Start semi-sync binlog_dump to slave (server_id: 3306), pos(, 4).
[root@GreatSQL][test]>show variables like '%Rpl%'; +-------------------------------------------+------------+ | Variable_name | Value | +-------------------------------------------+------------+ | rpl_read_size | 8192 | | rpl_semi_sync_master_enabled | ON | | rpl_semi_sync_master_timeout | 10000 | | rpl_semi_sync_master_trace_level | 32 | | rpl_semi_sync_master_wait_for_slave_count | 1 | | rpl_semi_sync_master_wait_no_slave | ON | | rpl_semi_sync_master_wait_point | AFTER_SYNC | | rpl_stop_slave_timeout | 31536000 | +-------------------------------------------+------------+ 8 rows in set (0.00 sec)
[root@GreatSQL][test]>show variables like '%Rpl%'; +---------------------------------+----------+ | Variable_name | Value | +---------------------------------+----------+ | rpl_read_size | 8192 | | rpl_semi_sync_slave_enabled | ON | | rpl_semi_sync_slave_trace_level | 32 | | rpl_stop_slave_timeout | 31536000 | +---------------------------------+----------+ 4 rows in set (0.00 sec)
[root@GreatSQL][test]> show status like '%Rpl_semi%'; +--------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | | Rpl_semi_sync_master_net_avg_wait_time | 0 | | Rpl_semi_sync_master_net_wait_time | 0 | | Rpl_semi_sync_master_net_waits | 0 | | Rpl_semi_sync_master_no_times | 0 | | Rpl_semi_sync_master_no_tx | 0 | | Rpl_semi_sync_master_status | ON | | Rpl_semi_sync_master_timefunc_failures | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 0 | | Rpl_semi_sync_master_tx_wait_time | 0 | | Rpl_semi_sync_master_tx_waits | 0 | | Rpl_semi_sync_master_wait_pos_backtraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 0 | +--------------------------------------------+-------+ 14 rows in set (0.00 sec)
show global status like '%semi%'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | ON | +----------------------------+-------+ 1 row in set (0.00 sec)
[root@GreatSQL][(none)]>STOP SLAVE IO_THREAD; Query OK, 0 rows affected, 1 warning (0.02 sec)
[root@GreatSQL][test]>insert into ptype values(4,'4','4'),(5,'5','5'),(6,'6','6'); Query OK, 3 rows affected (0.02 sec)
[root@GreatSQL][test]>show status like 'Rpl_semi_sync_slave_status'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | OFF | +----------------------------+-------+ 1 row in set (0.00 sec)
主节点查看：
[root@GreatSQL][test]> show status like '%Rpl_semi%'; +--------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | | Rpl_semi_sync_master_net_avg_wait_time | 0 | | Rpl_semi_sync_master_net_wait_time | 0 | | Rpl_semi_sync_master_net_waits | 0 | | Rpl_semi_sync_master_no_times | 0 | | Rpl_semi_sync_master_no_tx | 0 | | Rpl_semi_sync_master_status | ON | | Rpl_semi_sync_master_timefunc_failures | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 0 | | Rpl_semi_sync_master_tx_wait_time | 0 | | Rpl_semi_sync_master_tx_waits | 0 | | Rpl_semi_sync_master_wait_pos_backtraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 0 | +--------------------------------------------+-------+ 14 rows in set (0.00 sec)
部分参数用途简要说明：
从节点转态信息：
show global status like '%semi%'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | ON | +----------------------------+-------+ 1 row in set (0.00 sec)
参数简单说明：
半同步是否会降级为异步复制？是会的。
当半同步复制发生超时时（由rpl_semi_sync_master_timeout参数控制，单位是毫秒，默认为10000，即10s），会暂时关闭半同步复制，转而使用异步复制。
当MASTER DUMP 线程发送完一个事务的所有事件之后，如果在rpl_semi_sync_master_timeout内，收到了从库的响应，则主从又重新恢复为半同步复制。
[root@GreatSQL][(none)]>STOP SLAVE IO_THREAD; Query OK, 0 rows affected, 1 warning (0.02 sec)
[root@GreatSQL][test]>insert into ptype values(4,'4','4'),(5,'5','5'),(6,'6','6'); Query OK, 3 rows affected (0.02 sec)
[root@GreatSQL][test]>show status like 'Rpl_semi_sync_slave_status'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | OFF | +----------------------------+-------+ 1 row in set (0.00 sec)
[root@GreatSQL][(none)]>START SLAVE IO_THREAD; Query OK, 0 rows affected, 1 warning (0.02 sec)
t@GreatSQL][test]>show status like 'Rpl_semi_sync_slave_status'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | ON | +----------------------------+-------+ 1 row in set (0.00 sec)
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!
mysql modifier le nom de la table de données
MySQL crée une procédure stockée
La différence entre MongoDB et MySQL
Comment vérifier si le mot de passe MySQL est oublié
mysql créer une base de données
niveau d'isolement des transactions par défaut de MySQL
La différence entre sqlserver et mysql
mysqlmot de passe oublié
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
