MysqL 复制方式对比、复制参数

上两小节从实战的角度介绍了如何搭建异步复制和增强半同步复制，我想您肯定会有疑问，都是 MysqL的主从复制，它们之间究竟有啥不同呢。本小节我们一起来学习 MysqL 复制方式的对比，以及相对比较重要的复制参数。

1. 复制方式对比

除了异步复制和增强半同步复制之外，介于它们之间其实还有一种复制方式，叫半同步复制，只是从MysqL 5.7开始，逐渐被增强半同步所替代。那么这三种复制方式之间有什么异同呢？请参考如下表格

	异步复制	半同步复制	增强半同步复制
部署难度	低	低	低
维护难度	低	中	中
数据丢失	中	中低	极低
性能影响	低	中	中

1.1 异步复制

在传统的复制中，binlog 的复制是异步的，啥时候复制到从库，以及是否复制成功，MysqL 是不管的，存在丢失数据的风险：

1.2 半同步复制

半同步复制的执行步骤如下：

1. sql 解析，会话T1(insert into t1 values(1000);)；
2. 存储引擎处理；
3. 写 binlog；
4. 提交至存储；
5. 等待从库成功接收 binlog 的返回信号；
6. 反馈至客户端。

这种同步方式的最大缺点是会出现丢失数据的风险，在步骤 4 之后，主库出现会话 T2(select * from t1;)，可以读取到 1000 这个值，但如果此时步骤 5 失败，从库是不能成功接收到 1000 这个值的，也就意味着表 t1 的 1000 在从库是丢失的。

1.3 增强半同步复制

增强半同步复制的执行步骤如下：

1. sql 解析，会话 T1(insert into t1 values(1000);)；
2. 存储引擎处理；
3. 写 binlog；
4. 等待从库成功接收 binlog 的返回信号；
5. 提交至存储；
6. 反馈至客户端。

增强半同步复制，号称无损半同步复制。在步骤 3 之后，如果主库出现会话 T2(select * from t1;)，是读取不到 1000 这个值的。如果步骤 4 失败，主从都一样，不能成功提交 1000 这个值，确保数据的一致性。

2. 重要的复制参数

2.1 主库

log-bin

binlog文件名前缀，可以是全路径，不可以动态修改

log-bin = /MysqL//log

server-id

唯一区别 ID，同一个集群内不可重复，从 5.6 开始可以动态修改

推荐使用ip+端口号，

server-uuid

唯一区别 ID，同一个集群内不可重复，从 5.6 开始可以动态修改：

位的GUID，文件路径/MysqL//auto.cn

• log-bin-index

binlog索引文件前缀，也可以是全路径，不可以动态修改

• binlog_format

binlog日志格式：statement、row、mixed三种，可以动态修改

• binlog_cache_size

binlog写入的buffer，推荐1M-4M就足够，可以动态修改

• max_binlog_size

限制每个binlog的大小，默认是1G，推荐128M或256M，可以动态修改

• expire_logs_days

表示多少天后自动删除binlog，可以动态修改

2.2 从库

• server-id：唯一区别ID，同一个集群内不可重复，从5.6开始可以动态修改，推荐使用ip+端口号，1013306；

• server-uuid：唯一区别ID，同一个集群内不可重复，从5.6开始可以动态修改；32位的GUID，文件路径/MysqL/3306/auto.cn；

• relay-log：relaylog文件名前缀，可以是全路径，不可以动态修改；复制进程io_thread读取过来存到本地的日志；

• relay-log-index：relaylog 索引文件前缀，也可以是全路径，不可以动态修改；

• read-only：设置从库是否只读，但对super权限的用户不起作用，可以动态修改；

• log-slave-updates：将 master 传输过来的变更操作，再次记录成本地 binlog，用于做二次复制，当做中继分发节点，不可以动态修改；

• max_relay_log_size：限制每个 relaylog 的大小，推荐 128M 或 256M，可以动态修改。

3. 小结

本小节主要介绍了三种复制方式的异同点，以及一些比较重要的复制参数。

在实际应用场景中，MysqL 复制是使用最为广泛的，用来提高系统可用性、扩展性的设计手段，也是MysqL 迅速流行的关键原因。一般来说，从 MysqL 5.7 开始，都推荐使用增强半同步的复制方式，基本可以实现数据 0 丢失。