mysql 架构篇系列 4 复制架构一主一从搭建(半同步复制)
一.概述
在mysql 5.5之前，mysql 的复制是异步操作，主库和从库的数据之间存在一定的延时，这样存在一个隐患：当主库上写入一个事务并提交成功，而从库尚未得到主库推送的Binlog日志时，主库down机了，事务Binlog丢失了，此时从库就缺失了这个事务，从而造成主从不一致。
为了解决这个问题，mysql5.5 引入了半同步复制，在mysql 5.5之前的异步复制时，主库执行完Commit提交操作后，在主库写入Binlog日志后即可成功返回客户端，无需等待Binlog日志传送给从库，异步复制流程如下图所示：
对于半同步复制，能保证主库上的每一个Binlog事务都能被可靠的复制到从库上，主库在每次事务成功提交时，并不及时反馈给前端应用用户，而是等待其中一个从库也接收到Binlog事务并成功写入中继日志后，主库才返回Commit操作成功给客户端。 半同步复制保证了事务成功提交后，至少有两份日志记录，一份在主库的Binlog日志上，另一份在至少 一个从库的中继日志relay log上，从而更进一步保证的主从数据的一致性。半同步复制流程如下图所示：
在半同步复制模式下，假设步骤(1,2,3)的任何一个步骤中主库宕机，则事务并没有提交成功，从库也没收到事务binlog日志，所以主从数据是一致的。假如步骤(4)传送Binlog日志到从库时，从库宕机或者网络故障，导致binlog并没有及时传送到从库上，此时主库上的事务会等待一段时间(由参数rp1_semi_sync_master_timeout毫秒决定)， 如果binlog在这段时间内都无法成功推送到从库上，则mysql自动调整复制为异步复制模式。事务正常返回提交结果给客户端。
二. 半同步（Semi-sync）复制配置步骤
下面半同步复制的配置步骤是基于前面第二篇 "一主一从搭建(异步复制)" 基础之上。半同步模式作为mysql5.5的一个插件来实现的，主库和从库使用不同的插件，需要安装
(1)判断mysql服务器是否支持动态增加插件
SELECT @@have_dynamic_loading
(2) 检查mysql的安装目录下是否存在插件，主库插件是semisync_master.so，从库插件是semisync_slave.so。
-- 主库插件位置： SHOW VARIABLES LIKE 'plugin_dir';
-- 从库插件位置 SHOW VARIABLES LIKE 'plugin_dir';
--在主库上安装插件 semisync_master.so，安装完从plugin表查看 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so' SELECT * FROM mysql.`plugin`
--在从库上安装插件 semisync_slave.so ,安装完从plugin表查看 INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so' SELECT * FROM mysql.`plugin`
(3) 需要分别在主库和从库上配置参数打开半同步semi-sync, 默认半同步设置是打不开的，主库上配置全局参数。
-- 主库上配置启用。设置主库传送到从库的Binlog日志，最大超时时间。 SET GLOBAL rpl_semi_sync_master_enabled=1; SET GLOBAL rpl_semi_sync_master_timeout=3000; -- 从库上 SET GLOBAL rpl_semi_sync_slave_enabled=1;
注意之前配置的复制是异步复制，所以需要重启一下从库上的I/O线程。
-- 从库停掉I/O 线程，再启动 STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
(4) 同半步配置完毕后，下面验证一下
-- 主库上查看当前半同步复制的一些状态值 SHOW STATUS LIKE '%semi_sync%'
在上面的状态信息中，重点先来了解3个状态值：
Rpl_semi_sync_master_status： 值为ON, 代表半同步复制目前处于打开状态。
Rpl_semi_sync_master_yes_tx： 值表示主库当前有多少事务是通过半同步复制到从库的。
Rpl_semi_sync_master_no_tx： 值表示当前事务不是半同步下从库及时响应的(主从不同步时体现)。
-- 在主库上执行一个事务，再检查主库复制状态 UPDATE testbackup2 SET `name`='小李2' WHERE id=12
如上图所示，此时Rpl_semi_sync_master_yes_tx的值计数增加1，在查从库时刚修改的数据已同步。
三. 半同步复制参数信息说明
3.1 主库上semi_sync状态信息(SHOW STATUS LIKE '%semi_sync%')
|
状态名称 |
状态值 |
描述 |
|
Rpl_semi_sync_master_clients |
1 |
有多少个Semi-sync(半同步)的从库 |
|
Rpl_semi_sync_master_net_avg_wait_time |
0 |
事务提交后，等待slave响应的平均时间 |
|
Rpl_semi_sync_master_net_wait_time |
0 |
总的网络等待时间 (等待slave) |
|
Rpl_semi_sync_master_net_waits |
2 |
等待网络响应的总次数 (等待slave) |
|
Rpl_semi_sync_master_no_times |
0 |
一共有几次从Semi-sync跌回普通状态， 通俗叫:关闭半同步复制的次数 |
|
Rpl_semi_sync_master_no_tx |
0 |
slave未及时响应的事务数 |
|
Rpl_semi_sync_master_status |
ON |
主库上Semi-sync是否正常开启 |
|
Rpl_semi_sync_master_timefunc_failures |
0 |
时间函数未正常工作的次数 |
|
Rpl_semi_sync_master_tx_avg_wait_time |
1222 |
开启Semi-sync，事务返回需要等待的平均时间 |
|
Rpl_semi_sync_master_tx_wait_time |
2445 |
事务等待备库响应的总时间 |
|
Rpl_semi_sync_master_tx_waits |
2 |
事务等待备库响应的总次数 |
|
Rpl_semi_sync_master_wait_pos_backtraverse |
0 |
改变当前等待最小二进制日志的次数 |
|
Rpl_semi_sync_master_wait_sessions |
0 |
当前有几个线程在等备库响应 |
|
Rpl_semi_sync_master_yes_tx |
2 |
Semi-sync模式下，成功的事务数。也叫主库成功接收到slave的回复的次数。 |
3.2 主库上semi_sync环境信息(SHOW VARIABLES LIKE '%semi%')
|
环境名称 |
值 |
描述 |
|
rpl_semi_sync_master_enabled |
ON |
是否自动开启半同步复制 |
|
rpl_semi_sync_master_timeout |
3000 |
主库传送到从库的Binlog日志，最大超时时间 |
|
rpl_semi_sync_master_trace_level |
32 |
用于开启半同步复制模式时的调试级别，默认是32。 net wait level (more information about network waits) |
|
rpl_semi_sync_master_wait_for_slave_count |
1 |
至少有N个slave接收到日志 |
|
rpl_semi_sync_master_wait_no_slave |
ON |
是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on |
|
rpl_semi_sync_master_wait_point |
AFTER_SYNC |
控制 master 在哪个环节接收 slave ack，master 接收到 ack 后返回状态给客户端。 |
3.3 从库上semi_sync环境信息(SHOW VARIABLES LIKE '%semi%';)
|
环境名称 |
值 |
描述 |
|
rpl_semi_sync_slave_enabled |
ON |
从库是否自动开启半同步复制 |
|
rpl_semi_sync_slave_trace_level |
32 |
同上 |
3.4 从库上semi_sync状态信息(SHOW STATUS LIKE '%semi_sync%')
|
Rpl_semi_sync_slave_status |
ON |
从库上Semi-sync是否正常开启 |
扩展：
建议备库设置成只读（readonly）模式。这样做，有以下几个考虑：
有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操作；
防止切换逻辑有 bug，比如切换过程中出现双写，造成主备不一致；
可以用 readonly 状态，来判断节点的角色。
备库设置成只读了，还怎么跟主库保持同步更新呢？这个问题，你不用担心。因为 readonly 设置对超级 (super) 权限用户是无效的，而用于同步更新的线程，就拥有超级权限。
如果你的线上 MySQL 设置的 binlog 格式是 statement 的话，那基本上就可以认为这是一个不合理的设置。你至少应该把 binlog 的格式设置为 mixed。现在越来越多的场景要求把 MySQL 的 binlog 格式设置成 row。这么做的理由有很多，我来给你举一个可以直接看出来的好处：恢复数据。
