MySQL 半同步复制的实现_数据库_开发者_运维开发者技术经验分享

一、半同步复制介绍

mysql基础复制有三种模式：异步复制/同步复制/半同步复制，3种模式各有利弊，下面对各种复制模式的优缺点做个简要的介绍：

异步复制（Asynchronous replicaton）

这是MySQL默认的复制模式，异步复制指主库写binlog、从库I/O线程读binlog并写入relaylog、从库SQL线程重放事务这三步之间是异步的。异步复制的优点是主库不需要关心备库的状态，主库不保证事务被传输到从库，如果主库崩溃，某些事务可能还未发送到从库，切换后可能导致事务的丢失。其优点是可以有更高的吞吐量，缺点是不能保持数据实时一致，不适合要求主从数据一致性要求较高的应用场景。

同步复制（Synchronous replicaton）

同步复制的模式下，主库在提交事务前，必须确认事务在所有的备库上都已经完成提交。即主库是最后一个提交的，在提交前需要将事务传递给从库并完成重放、提交等一系列动作。其优点是任何时候主备库都是一致的，主库的崩溃不会丢失事务，缺点是由于主库需要等待备库先提交事务，吞吐量很低。

半同步复制（Semisynchronous replicaiton）

MySQL从5.5开始引入了半同步复制，半同步复制介于异步复制和同步复制之间。主库在提交事务时先等待，必须确认至少一个从库收到了事件（从库将事件写入relaylog，不需要重放和提交，并向主库发送一个确认信息ACK），主库收到确认信息后才会正式commit。

与同步复制相比，半同步复制速度快很多，因为他只需要至少1个从库确认写入relaylog，并不需要完成在从库上的事务提交，同时又比异步复制更安全，因为主库在提交时，事务至少已经存在2个地方（主库的binlog和从库的relaylog）。由于半同步复制在提交事务前，需要从库返还确认信息，所以这里涉及到网编程客栈络的往返通信开销，因此半同步复制只适合在网络条件较好的且地理上距离不远的环境部署，否则可能会因为网络延迟大幅降低主库性能。

半同步复制的特点：

从库在连接主库时需要表明它是否支持半同步复制。
如果主库启用了半同步复制，且有一个支持半同步复制的从库，则主库上事务提交将等待至少一个从库确认已收到事务，或者直到发生超时。
默认只有在将事务写入其中继日志并刷新到磁盘后，主库才会提交事务（也可以配置成提交后等待确认）。
如果没有任何从库确认事务的情况下发生超时，则主库将退化为异步复制。当至少有一个半同步从库赶上时，主库恢复半同步复制。退化与恢复过程都是自动的。
必须在主库和从库上都启用半同步复制，否则使用异步复制。

二、搭建半同步复制

半同步复制是以插件的形式实现的，要使用半同步复制，要在主从分别安装相应的插件，并且通过参数来控制半同步复制。

在使用半同步复制前需要先满足下列条件：

服务器要支持动态加载，参数have_dynamic_loading要设置为True（MySQL8.0默认就是True）。
已经完成基础异步复制的配置。
不支持一从多主的复制（多通道）。

现以上一篇配置好的异步复制为基础来配置半同步复制

异步复制（Asynchronous replication）

2台数据库环境如下：

192.168.3.71（主库主机名master）
192.168.3.72（从库主机名slave01）

2.1 安装半同步插件

安装半同步插件时，需要在主库安装semisync_master.so（8.0.26 以后版本为semisync_source.so），在从库安装semisync_slave.so（8.0.26以后版本为semisync_replica.so）。执行安装命令时，插件必须在插件目录（参数plugin_dir）存在。

在主库安装插件：

install plugin rpl_sjavascriptemi_sync_master soname 'semisync_master.so';
或MySQL 8.0.26以上版本执行下面命令：
install plugin rpl_semi_sync_source soname 'semisync_source.so';

MySQL 半同步复制的实现

在备库安装插件：

install plugin rpl_s编程客栈emi_sync_slave soname 'semisync_slave.so';
或MySQL 8.0.26以上版本执行下面命令：
install plugin rpl_semi_sync_replica soname 'semisync_replica.so';

MySQL 半同步复制的实现

安装完成后可以用show plugins来查看是否安装成功，安装成功后插件列表中应该有下列类似信息：

show plugins;

MySQL 半同步复制的实现

2.2 启用半同步复制

确认主备的插件都成功安装后，使用下面命名调整参数，启用半同步复制。

主库执行：

set global rpl_semi_sync_master_enabled=1;
或MySQL 8.0.26以后版本执行：
set global rpl_semi_sync_source_enabled = 1;

MySQL 半同步复制的实现

备库执行：

set global rpl_semi_sync_slave_enabled=1;
或MySQL 8.0.26以后版本执行：
set global rpl_semi_sync_replica_enabled = 1;

MySQL 半同步复制的实现

为了防止配置不丢失，建议也将配置添加到my.cnf中：

主库配置文件添加：

[mysqld]
rpl_semi_s编程客栈ync_master_enabled=1
# 或8.026版本添加：
# rpl_semi_sync_source_enabled=1

主库配置文件添加：

[mysqld]
rpl_semi_sync_slave_enabled=1
# 或8.026版本添加：
# rpl_semi_sync_replica_enabled=1

如果在完成上面配置时异步复制正在运行，则需要重启从库的I/O线程来切换到半同步复制：

stop slave io_thread;
start slave io_thread;
show status like 'rpl_semi_sync_slave_status';    -- 查看备库半同步复制状态

MySQL 半同步复制的实现

查看主库半同步复制状态：

show status like 'rpl_semi_sync_master_status';

MySQL 半同步复制的实现

通过状态变量，我们看到主备的半同步都是处于工作状态，半同步复制的搭建完成。

三、配置半同步复制

当完成了半同步配置后，系统上和半同步相关的配置参数就可以使用了，这些参数可用来调整半同步复制的配置：

主库查看半同步相关配置参数：

show variables like 'rpl_semi_sync%';

MySQL 半同步复制的实现

如果使用的是8.0.26以上的版本，参数中的'master'会被替换为'source'，'slave'会被替换为'replica'，下面依次解释各参数设置含义：

rpl_semi_sync_master_enabled

用来控制是否开启半同步复制，ON代表开启，OFF代表关闭。

rpl_semi_sync_master_timeout

主库等待从库ACK超时的时长，单位是毫秒，默认是10000(10s)。

rpl_semi_sync_master_trace_level

半同步复制时主库的调试级别

rpl_semi_sync_master_wait_for_slave_count

主库需要收到多少个ACK才认为此次提交成功，否则就降级为异步复制，默认是1，即只要有1个从库确认即可提交。

rpl_semi_sync_master_wait_no_slave

为ON时（默认值），当状态变量Rpl_semi_sync_master_clients中的值小于rpl_semi_sync_master_wait_for_slave_count时（即编程从库数小于需要的最小确认数），Rpl_semi_sync_master_status依旧为ON，只有当事务提交后等待rpl_semi_sync_master_timeout超时后，Rpl_semi_sync_master_status才会变为OFF，即降级为异步复制；

为OFF时，当状态变量Rpl_semi_sync_master_clients中的值小于rpl_semi_sync_master_wait_for_slave_count时，Rpl_semi_sync_master_status立即显示为OFF，即立即降级为异步复制。

rpl_semi_sync_master_wait_point

控制主库上commit、接收ACK、返回控制给客户端的时间点。值为after_sync（默认）或after_commit。

after_sync：主库会等待从库的ACK后再提交事务，最后返还控制权给客户端。主库上所有会话同一时间看到提交的事务，如果发生failover，主从数据是一致的。
after_commit：主库会先提交事务，再等待ACK，最后返还控制权给客户端。主库会先提交，此时主库上其他会话可以看到已提交的事务，但执行事务的会话还未返还，依然在等待从库确认，如果从库因为崩溃没有处理这个事务，那么其他会话会在主从看到不一致的数据（主库事务提交了，从库的事务丢了）。