本文介绍了MySQL主从复制的默认异步模式及其流程，探讨了在主库宕机时可能导致的数据丢失问题。为解决此问题，提出了半同步和全同步复制策略，分析了它们的特点和适用场景。半同步复制确保至少一个从库接收到binlog，而全同步复制则要求所有从库执行完毕。这两种方式在数据一致性和系统性能之间做出了不同权衡。
一般情况下，线上每个 Redis 实例都包含从库，用来做读写分离，减轻主库的压力
MySQL 的主从复制默认是异步的，其主要流程如下：
- 从节点的 I/O 线程连接主节点，并请求指定 bin log file 指定 position 之后的日志内容
- 主节点收到请求后，读取并返回。返回信息除了包含日志内容外还包含 bin log file 信息和 position 信息
- 从节点的 I/O 线程收到返回后，将接收到的日志内容更新到 relay log，并将 bin log file 信息和 position 信息 记录到 master-info 文件中，以便下一次读取的时候接上上次的进度继续
- 从节点的 SQL 线程检测到 relay log 中新值了欣荣，解析日志内容，并在数据库执行
异步复制场景下，主库突然宕机，此时从库还有部分数据未同步，可能导致数据丢失，为了解决该问题，可以改使用半同步复制或全同步复制：
半同步复制：对于客户端的请求，sql 写入 bin log 后，不会立即返回，而是通过 log-dump thread 主动发送从节点，从节点收到并 relay log 后返回主节点 ACK，主节点只有收到 ACK 后再返回客户端执行成功
特点
- 确保 bin log 至少传输到一个从库
- 不保证从库完成这个事务的 binlog，写入 relay log 就返回
- 性能有影响，响应时间更差
- 万一从库宕机，主库只能等待超时或从库恢复
全同步复制：主节点和所有从节点全部执行了该事务并确认才会向客户端返回成功。
全同步复制相对效率更差，因为它需要所有从库都同步完成才返回客户端 ACK
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
