Heim >Datenbank >MySQL-Tutorial >So implementieren Sie eine halbsynchrone Replikation in MySQL
So implementieren Sie eine halbsynchrone Replikation in MySQL
- PHPznach vorne
- 2023-05-26 15:57:001267Durchsuche
1. Einführung in die Halbsynchronisation
Der
MASTER-Knoten gibt die Ergebnisse nicht sofort an den Client zurück, nachdem er die vom Client übermittelte Transaktion ausgeführt hat, sondern wartet auf den Empfang durch mindestens einen SLAVE-Knoten und schreiben Sie es in das Relay-Protokoll, bevor Sie zum Client zurückkehren.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
Im Vergleich zur asynchronen Replikation verbessert die Halbsynchronisation die Datensicherheit, verursacht aber auch eine gewisse Verzögerung. Diese Verzögerung beträgt mindestens eine TCP-Roundtripzeit. Daher eignet sich die halbsynchrone Replikation am besten für Netzwerke mit geringer Latenz.
MySQL unterstützt die halbsynchrone Replikation seit Version 5.7.2; die ursprüngliche halbsynchrone Strategie ist AFTER_COMMIT und die verbesserte Strategie ist AFTER_SYNC Der Zeitpunkt der ACK-Antwort des SLAVE-Knotens auf den MASTER ist unterschiedlich. 2. Einführung in die beiden ModiAFTER_COMMIT Einführung in den Modus
MASTER schreibt jede Transaktion in das Binärprotokoll und speichert sie gleichzeitig durch Leeren der Festplatte Senden Sie die Transaktion an SLAVE und senden Sie sie dann zur Verarbeitung und Übermittlung an die Speicher-Engine. Warten Sie dann, bis SLAVE Bestätigungsinformationen zurückgibt. Nach Erhalt der Bestätigungsinformationen gibt MASTER das Ergebnis an den Client und dann an den aktuellen Client zurück kann weiterarbeiten.AFTER_SYNC
Modus-EinführungMASTER schreibt jede Transaktion in das Binärprotokoll und speichert sie auf der Festplatte. Gleichzeitig sendet er die Transaktion an SLAVE und wartet dann darauf, dass SLAVE Bestätigungsinformationen zurückgibt , übermittelt es die Transaktion an die Speicher-Engine. Verarbeiten und übermitteln, die Ergebnisse werden an den Client zurückgegeben, und der aktuelle Client kann weiterarbeiten. 3. Vergleich der beiden MethodenBei der ersten AFTER_COMMIT -Methode empfängt der aktuelle Client die Transaktion erst, nachdem der Server Daten an die Speicher-Engine übermittelt und die von SLAVE zurückgegebene Bestätigung erhalten hat Ergebnisse. Bevor nach der Übermittlung der Transaktion Bestätigungsinformationen von SLAVE empfangen werden, können andere Kunden die vom aktuellen Kunden zu diesem Zeitpunkt übermittelten Transaktionsinformationen sehen.
Wenn der SLAVE-Knoten die vom MASTER-Knoten übergebene Transaktion aus Netzwerk- und anderen Gründen nicht empfängt und der MASTER-Knoten in diesem Moment abstürzt. HA führt ein Failover durch und die Clients werden mit dem SLAVE-Knoten verbunden. Zu diesem Zeitpunkt wird die zuvor auf dem MASTER-Knoten angezeigte Transaktion nicht auf dem SLAVE-Knoten angezeigt und die Transaktion geht verloren.
AFTER_SYNC-Methode können alle Clients die durch die Transaktion verursachten Datenänderungen sehen, wenn die Transaktion von SLAVE bestätigt wird und MASTER die Transaktion auf der Ebene der Speicher-Engine festschreibt. Daher sehen alle Clients gleichzeitig die gleichen Daten auf dem MASTER. Wenn der MASTER-Knoten abstürzt, werden alle auf dem MASTER übermittelten Transaktionen auf den SLAVE kopiert (im Relay-Protokoll gespeichert). Der MASTER-Server ist unerwartet abgestürzt. In diesem Moment sind die vom Client gesehenen Daten nach dem Failover von HA auf SALVE verlustfrei, da SLAVE die neueste Version ist.
Beachten Sie jedoch, dass MASTER in diesem Fall nicht direkt zur Verwendung wiederhergestellt werden kann, da sein Binärprotokoll möglicherweise nicht festgeschriebene Transaktionen enthält. Wenn das Binärprotokoll zu diesem Zeitpunkt wiederhergestellt und für geschäftliche Zwecke verwendet wird, kann es zu einem Konflikt kommen mit SKLAVE.
4. So aktivieren Sie die Halbsynchronisation
Methode 1:
Die Halbsynchronisation liegt in Form eines Plug-Ins vor (diesmal verwenden wir diese Methode)Masterknotenaktivierung : ?? 2:
In meiner Open in .cnf-KonfigurationSowohl Master- als auch Slave-Knoten sind so konfiguriert, dass sie sich synchron öffnen:
(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 5. Überprüfen Sie den Plug-in-Öffnungsstatus
Methode 1: 
Query-Plugin
Master Knotenansicht:
[root@GreatSQL][test]>SET GLOBAL rpl_semi_sync_master_enabled = on; Query OK, 0 rows affected (0.00 sec)
Slave-Knotenansicht:
t@GreatSQL][(none)]>SET GLOBAL rpl_semi_sync_slave_enabled = on; Query OK, 0 rows affected (0.00 sec)
Methode 2:
information_schema.plugins für umfassendere Informationen 🎜🎜🎜Master-Knoteninformationen: 🎜🎜(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)🎜 6. Drehen zur Halbsynchronisationsfunktion 🎜🎜Da es sich hier um eine Online-Installation des Plug-Ins handelt, muss der Dienst nach Abschluss der Plug-In-Installation gestartet werden🎜🎜🎜 Aktivieren Sie die halbsynchrone Replikation auf dem Masterknoten : 🎜🎜
[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)🎜🎜 Aktivieren Sie die halbsynchrone Replikation auf dem Slave-Knoten: 🎜🎜
[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)🎜Nachdem die oben genannten Einstellungen abgeschlossen sind, starten Sie den IO-Thread auf dem Slave-Knoten neu🎜
# 关键信息 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).🎜 7. Überprüfen Sie, ob Semi-Sync läuft🎜🎜🎜 Master-Knoten: 🎜🎜
[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)🎜🎜 Slave-Knoten: 🎜🎜
[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)🎜 Überprüfen Sie das Fehlerprotokoll des Master-Knotens. Sie können sehen, dass der Slave-Knoten die halbsynchrone Replikation aktiviert hat 🎜
[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)🎜 Oben ist die halbsynchrone MySQL-Replikation eingerichtet! 8. Halbsynchrone Parameterinformationen einiger Parameter : 🎜🎜 🎜🎜🎜
九、半同步状态信息
主节点查看：
[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内，收到了从库的响应，则主从又重新恢复为半同步复制。
1.从节点暂时先关掉IO线程
[root@GreatSQL][(none)]>STOP SLAVE IO_THREAD; Query OK, 0 rows affected, 1 warning (0.02 sec)
2.主节点写入几条测试数据
[root@GreatSQL][test]>insert into ptype values(4,'4','4'),(5,'5','5'),(6,'6','6'); Query OK, 3 rows affected (0.02 sec)
3.等待10s后查看复制状态，半同步已经关掉了
[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)
4.从节点开启IO线程
[root@GreatSQL][(none)]>START SLAVE IO_THREAD; Query OK, 0 rows affected, 1 warning (0.02 sec)
5.再次查看复制状态，半同步复制自动开启了
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)
Das obige ist der detaillierte Inhalt vonSo implementieren Sie eine halbsynchrone Replikation in MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!