MySQL 复制方式对比、复制参数
上两小节从实战的角度介绍了如何搭建异步复制和增强半同步复制，我想您肯定会有疑问，都是 MySQL的主从复制，它们之间究竟有啥不同呢。本小节我们一起来学习 MySQL 复制方式的对比，以及相对比较重要的复制参数。
1. 复制方式对比
除了异步复制和增强半同步复制之外，介于它们之间其实还有一种复制方式，叫半同步复制，只是从MySQL 5.7开始，逐渐被增强半同步所替代。那么这三种复制方式之间有什么异同呢？请参考如下表格
| 异步复制 | 半同步复制 | 增强半同步复制 | |
|---|---|---|---|
| 部署难度 | 低 | 低 | 低 |
| 维护难度 | 低 | 中 | 中 |
| 数据丢失 | 中 | 中低 | 极低 |
| 性能影响 | 低 | 中 | 中 |
1.1 异步复制
在传统的复制中，binlog 的复制是异步的，啥时候复制到从库，以及是否复制成功，MySQL 是不管的，存在丢失数据的风险：
1.2 半同步复制
半同步复制的执行步骤如下：
- SQL 解析，会话T1(insert into t1 values(1000);)；
- 存储引擎处理；
- 写 binlog；
- 提交至存储；
- 等待从库成功接收 binlog 的返回信号；
- 反馈至客户端。
这种同步方式的最大缺点是会出现丢失数据的风险，在步骤 4 之后，主库出现会话 T2(select * from t1;)，可以读取到 1000 这个值，但如果此时步骤 5 失败，从库是不能成功接收到 1000 这个值的，也就意味着表 t1 的 1000 在从库是丢失的。
1.3 增强半同步复制
增强半同步复制的执行步骤如下：
- SQL 解析，会话 T1(insert into t1 values(1000);)；
- 存储引擎处理；
- 写 binlog；
- 等待从库成功接收 binlog 的返回信号；
- 提交至存储；
- 反馈至客户端。
增强半同步复制，号称无损半同步复制。在步骤 3 之后，如果主库出现会话 T2(select * from t1;)，是读取不到 1000 这个值的。如果步骤 4 失败，主从都一样，不能成功提交 1000 这个值，确保数据的一致性。
2. 重要的复制参数
2.1 主库
log-bin
binlog文件名前缀，可以是全路径，不可以动态修改
log-bin = /mysql/3306/log
server-id
唯一区别 ID，同一个集群内不可重复，从 5.6 开始可以动态修改
推荐使用ip+端口号，1013306
server-uuid
唯一区别 ID，同一个集群内不可重复，从 5.6 开始可以动态修改：
32位的GUID，文件路径/mysql/3306/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 丢失。