MySQL半同步复制的搭建和配置原理

406次阅读

共计 2872 个字符，预计需要花费 8 分钟才能阅读完成。

半同步复制：

什么是半同步复制？我们知道在默认情况下，MySQL 的复制是异步的，这意味着主服务器及其从服务器是独立的。异步复制可以提供最佳的性能，因为主服务器在将更新的数据写入它的二进制日志（Binlog）文件中后，无需等待验证更新数据是否已经复制到从服务器中，就可以自由处理其它进入的事务处理请求。但这也同时带来了很高的风险，如果在主服务器或从服务器端发生故障，会造成主从数据的不一致，甚至在恢复时造成数据丢失。

半同步复制是从 MySQL5.5 开始引入了一种半同步复制功能，该功能可以确保主服务器和访问链中至少一台从服务器之间的数据一致性和冗余。在这种配置结构中，一台主服务器和其许多从服务器都进行了配置，这样在复制拓扑中，至少有一台从服务器在父主服务器进行事务处理前，必须确认更新已经收到并写入了其中继日志（Relay Log）。当出现超时，源主服务器必须暂时切换到异步复制模式重新复制，直到至少有一台设置为半同步复制模式的从服务器及时收到信息。

下面我们看一下怎么从普通复制转化为半同步复制。假设我们已经搭建完成一主两从的 GTID 复制环境：

MySQL1：172.16.16.35:3306

MySQL2：172.16.16.35:3307

MySQL3：172.16.16.34:3306

这个环境因为我之前测试 MHA 的时候已经是搭建好了，就不在强调怎么去搭建一个普通的 GTID 复制环境了，下面我们看一下怎么安装

（1）安装插件，三台 MySQL 服务器都要执行：

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

我们可以通过以下语句查看是否安装成功：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
+----------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE |
| rpl_semi_sync_slave | ACTIVE |
+----------------------+---------------+
2 rows in set (0.00 sec)

在三台 MySQL 的配置文件当中添加如下的参数：

rpl_semi_sync_master_enabled=1 #开启半同步复制
rpl_semi_sync_slave_enabled=on; #打开半同步复制

然后重启数据库，不安装 semisync_master.so 的话是不能识别这个参数的，所以说这个参数要等安装完以后在重启。

(2) 重启完成后，默认就是半同步复制了，开始看一下半同步相关的参数：

下面我们看一下这些参数具体是有什么含义：

rpl_semi_sync_master_enabled：主库是否打开半同步复制

rpl_semi_sync_master_timeout：毫秒为单位，当主库等待从库 ACK 的实践超过这个值，就会自动转化为异步复制

rpl_semi_sync_master_trace_level：master 的 trace 级别，分为四个（1,16,32,64），分别记录不同的信息，32 能够输出更详细的网络延迟等信息，也是默认值

rpl_semi_sync_master_wait_for_slave_count：至少有 N 个 slave 接收到日志，一主多从的情况下只要有一个 slave 的 ACK 返回给了主库，就会进行 commit

rpl_semi_sync_master_wait_no_slave：默认为 ON，当半同步复制转换为异步复制后，如果从库的日志追赶上了主库，会自动转换为半同步复制，设置为 OFF 的话就不会再进行转换。

rpl_semi_sync_slave_enabled：从库是否打开半同步复制功能

rpl_semi_sync_slave_trace_level：trace 级别

rpl_semi_sync_master_wait_point：这是 MySQL5.7 新增的功能，可以设置两个值 AFTER_SYNC 和 AFTER_COMMIT，AFTER_COMMIT 的模式下 master 将每个事务写入 binlog , 传递到 slave 刷新到磁盘 (relay log)，同时主库提交事务。master 等待 slave 反馈收到 relay log，只有收到 ACK 后 master 才将 commit OK 结果反馈给客户端。AFTER_SYNC 情况下 master 将每个事务写入 binlog , 传递到 slave 刷新到磁盘 (relay log)。master 等待 slave 反馈接收到 relay log 的 ack 之后，再提交事务并且返回 commit OK 结果给客户端。即使主库 crash，所有在主库上已经提交的事务都能保证已经同步到 slave 的 relay log 中。我们推荐使用默认 AFTER_SYNC 的情况，这样可以提高性能，减少等待时间。

此外在 MySQL5.7 的半同步复制当中还移除了 dump thread 对 binlog 的互斥锁，解决了在高并发环境下串行读取 binlog 的问题。

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-06/144608.htm

正文完

星哥玩云-微信公众号