MASTERSelepas melaksanakan transaksi yang diserahkan oleh pelanggan, nod tidak segera mengembalikan hasilnya kepada pelanggan, tetapi menunggu di sekurang-kurangnya satu nod HAMBA untuk diterima dan Ia ditulis pada log geganti sebelum dikembalikan kepada klien.
Berbanding dengan replikasi tak segerak, separa penyegerakan meningkatkan keselamatan data, tetapi juga menyebabkan tahap kelewatan tertentu ini ialah sekurang-kurangnya satu masa pergi balik TCP. Oleh itu, replikasi separa segerak paling baik digunakan dalam rangkaian kependaman rendah.
MySQL telah menyokong replikasi separa segerak sejak versi 5.5 replikasi separa segerak telah dipertingkatkan dalam versi 5.7.2 strategi separa segerak yang asal ialah AFTER_COMMIT dan strategi yang dipertingkatkan ialah Perbezaannya antara AFTER_SYNC dan kedua-duanya ialah masa tindak balas ACK nod SLAVE kepada MASTER adalah berbeza.
AFTER_COMMIT Pengenalan mod
MASTER menulis setiap transaksi pada log binari dan Flush dan simpan, dan hantar urus niaga ke SLAVE pada masa yang sama, kemudian serahkan urus niaga ke enjin storan untuk pemprosesan dan penyerahan, dan kemudian tunggu SLAVE mengembalikan maklumat pengesahan Selepas menerima maklumat pengesahan, MASTER mengembalikan hasilnya kepada pelanggan , dan kemudian pelanggan semasa boleh Terus bekerja.
AFTER_SYNC Pengenalan mod
MASTER menulis setiap transaksi ke log perduaan dan mengepam cakera untuk menyimpannya Pada masa yang sama, ia menghantar urus niaga kepada SLAVE, dan kemudian menunggu SLAVE untuk mengembalikan maklumat pengesahan Selepas menerima maklumat pengesahan, transaksi diserahkan kepada enjin storan untuk pemprosesan dan penyerahan, dan hasilnya dikembalikan kepada pelanggan, dan kemudian pelanggan semasa boleh terus berfungsi.
Untuk kaedah AFTER_COMMIT pertama, pelanggan semasa hanya akan menerima data selepas pelayan menyerahkan data kepada enjin storan dan menerima pengesahan yang dikembalikan oleh HAMBA. Hasil dikembalikan daripada transaksi. Sebelum menerima maklumat pengesahan daripada SLAVE selepas transaksi diserahkan, pelanggan lain boleh melihat maklumat transaksi yang diserahkan oleh pelanggan semasa pada masa ini.
Jika nod SLAVE tidak menerima transaksi yang diluluskan oleh nod MASTER disebabkan rangkaian dan sebab lain, dan nod MASTER ranap pada masa ini. HA melakukan failover dan pelanggan disambungkan ke nod SLAVE Pada masa ini, transaksi yang sebelum ini dilihat pada nod MASTER tidak dilihat pada nod SLAVE, dan kerugian transaksi berlaku.
Untuk kaedah AFTER_SYNC kedua, apabila transaksi disahkan oleh SLAVE dan MASTER melakukan transaksi di peringkat enjin storan, semua pelanggan boleh melihat perubahan data yang disebabkan oleh transaksi. Oleh itu, semua pelanggan melihat data yang sama pada MASTER pada masa yang sama.
Apabila nod MASTER ranap, semua transaksi yang diserahkan pada MASTER akan disalin ke SLAVE (disimpan dalam log geganti). Pelayan MASTER ranap secara tidak dijangka. Pada masa ini, selepas HA gagal ke SALVE, data yang dilihat oleh pelanggan adalah lossless kerana SLAVE adalah yang terkini.
Namun, ambil perhatian bahawa dalam kes ini, MASTER tidak boleh dipulihkan secara langsung untuk digunakan kerana log binarinya mungkin mengandungi urus niaga tanpa komitmen, yang boleh menyebabkan konflik dengan SLAVE apabila log binari dipulihkan dan digunakan untuk keperluan perniagaan.
Kaedah 1: Separa penyegerakan wujud dalam bentuk pemalam Kami boleh mendayakannya secara terus dalam talian (ini kaedah digunakan kali ini)
Nod induk bermula:
[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; Query OK, 0 rows affected (0.02 sec)
Nod hamba bermula:
[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; Query OK, 0 rows affected (0.02 sec)
PS: Secara amnya, semua nod menggunakan pemalam induk dan hamba secara serentak, yang menjadikannya lebih mudah untuk mengendalikan failover
Kaedah 2: Dayakannya dalam konfigurasi my.cnf
Kedua-dua nod induk dan hamba dikonfigurasikan secara serentak dan didayakan:
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
Kaedah 1: Pemalam pertanyaan
Paparan nod induk:
[root@GreatSQL][test]>show plugins; | rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
Paparan nod hamba:
rreee Kaedah 2: Pertanyaaninformation_schema.pluginsMaklumat yang lebih komprehensif
Maklumat nod induk:
[root@GreatSQL][(none)]>show plugins; | rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |
Oleh kerana pemalam dipasang dalam talian, pemalam Selepas pemasangan selesai, perkhidmatan perlu dimulakan
Dayakan replikasi separa segerak pada nod induk:
(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 secDayakan replikasi separa segerak pada nod hamba:
[root@GreatSQL][test]>SET GLOBAL rpl_semi_sync_master_enabled = on; Query OK, 0 rows affected (0.00 sec)
Selepas tetapan di atas selesai, mulakan semula benang IO daripada nod hamba
t@GreatSQL][(none)]>SET GLOBAL rpl_semi_sync_slave_enabled = on; Query OK, 0 rows affected (0.00 sec)
Nod induk:
(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)
Nod hamba:
[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)
Semak ralat nod induk.log Dapat dilihat bahawa nod hamba telah mendayakan replikasi separa segerak
[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)
Di atas, replikasi separa segerak MySQL telah selesai.
Maklumat parameter nod induk:
# 关键信息 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).
Penerangan ringkas beberapa parameter:
Maklumat parameter nod hamba:
[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)
Penerangan ringkas beberapa 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内，收到了从库的响应，则主从又重新恢复为半同步复制。
[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)
Atas ialah kandungan terperinci Bagaimana untuk melaksanakan replikasi separuh segerak dalam MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
