mariadb 10.4.12 半同步复制
概述
半同步复制仅等待一个从属服务器确认其已接收并记录了事件。因此，半同步复制会带来一些负面的性能影响，但会增加数据完整性。 在MariaDB 10.3和更高版本中，服务器中内置了半同步复制，因此可以在那些版本中立即启用它。 在MariaDB 10.2及更低版本中，半同步复制需要用户在主服务器和从服务器上都安装插件，然后才能启用它。
主从复制集群安装请参考前期文章。本文安装mariadb版本为 10.4.12不使用插件安装方式
配置半同步复制
- 在主节点配置
#修改配置文件
[mysqld]
rpl_semi_sync_master_enabled=ON
重启数据库或者通过SET GLOBAL rpl_semi_sync_master_enabled=ON;动态配置
[root@localhost ~]# mysql -uroot -p
Enter password:
MariaDB [(none)]> SET GLOBAL rpl_semi_sync_master_enabled=ON;
Query OK, 0 rows affected (0.000 sec)
- 在slave节点配置
#修改配置文件，增加rpl_semi_sync_slave_enabled=ON
[root@localhost ~]# vim /etc/my.cnf.d/server.cnf
[mysqld]
rpl_semi_sync_slave_enabled=ON
...
重启slave或者SET GLOBAL rpl_semi_sync_slave_enabled=ON;动态配置
[root@localhost ~]# mysql -uroot -p
Enter password:
MariaDB [(none)]> SET GLOBAL rpl_semi_sync_slave_enabled=ON;
Query OK, 0 rows affected (0.347 sec)
#重启IO线程，使之注册为半同步线程，否则salve依然为异步复制
MariaDB [(none)]> STOP SLAVE IO_THREAD;
Query OK, 0 rows affected (0.159 sec)
MariaDB [(none)]> START SLAVE IO_THREAD;
Query OK, 0 rows affected (0.001 sec)
半同步复制参数
在半同步复制中，仅在将事件写入中继日志并清除后，从服务器才确认收到事务事件。如果从属服务器在经过一定时间之前未确认事务，则将发生超时，而主服务器将切换到异步复制，并记录相关错误日志。发生这种情况时，Rpl_semi_sync_master_status状态变量将切换为OFF。至少有一个半同步从服务器追上时，将恢复半同步复制。这将反映在主服务器的错误日志中。发生这种情况时，Rpl_semi_sync_master_status状态变量将切换为ON。可以通过查看Rpl_semi_sync_master_no_times状态变量的值来检查关闭半同步复制的次数。
默认参数10000为10秒 SET GLOBAL rpl_semi_sync_master_timeout=20000;
可以在配置文件中修改: [mariadb] ... rpl_semi_sync_master_timeout=20000
配置主等待点Master Wait Point
在半同步复制中，主机可以在两个潜在点上等待从机确认接收到事务事件。这两个等待点具有不同的优缺点。
等待点由rpl_semi_sync_master_wait_point系统变量配置。支持的值为：
- AFTER_SYNC
- AFTER_COMMIT
可以使用进行动态设置SET GLOBAL。例如：
SET GLOBAL rpl_semi_sync_master_wait_point = 'AFTER_SYNC' ;
也可以在启动服务器之前在选项文件的服务器选项组中设置它。例如：
[mariadb]
...
rpl_semi_sync_master_wait_point = AFTER_SYNC
当此变量设置为时AFTER_SYNC，主机执行以下步骤：
- 在存储引擎中准备事务。
- 将事务同步到二进制日志。
- 等待从站的确认。
- 将事务提交到存储引擎。
- 向客户端返回确认。
AFTER_SYNC等待点的效果是：
- 所有客户端同时在主服务器上看到相同的数据；从属服务器确认后，并提交给主服务器上的存储引擎后。
- 如果主服务器崩溃，则故障转移应该是无损的，因为在主服务器上提交的所有事务都将被复制到从服务器。
- 但是，如果主服务器崩溃，则其二进制日志也可能包含由存储引擎准备并写入二进制日志的事务事件，但存储引擎从未真正提交过。作为服务器的自动崩溃恢复过程的一部分，服务器可能会在服务器重新启动时恢复这些准备好的事务。这可能导致崩溃的主机与从机不一致。因此，崩溃的主机可能需要重建。有关更多信息，请参见MDEV-19733。
当此变量设置为时AFTER_COMMIT，主机执行以下步骤：
- 在存储引擎中准备事务。
- 将事务同步到二进制日志。
- 将事务提交到存储引擎。
- 等待从站的确认。
- 向客户端返回确认。
AFTER_COMMIT等待点的效果是：
- 其他客户端可能会在提交客户端之前看到已提交的事务。
- 如果主服务器崩溃，则故障转移可能会导致一些数据丢失，因为主服务器可能已经提交了尚未被从服务器确认的事务。