1.MySQL主从同步简介：
MySQL实例主从配置，可以实现数据同步、备份、读写分离、容灾:可以在主库挂掉后从备用从库中选举新Master进行数据恢复动作。
2.MySQL支持三种复制方式:
MySQL 5.6、5.7、8.0 版本支持三种复制方式：异步、半同步、强同步；5.5 版本支持异步方式
1) 异步复制(MySQL默认) : AP模型
Master不等待Slave同步，直接返回client => 性能最高，数据可能出现不一致；可用性优先: 适合对性能要求，能够容忍计算场景少量数据丢失场景
应用发起数据更新（含 操作）请求，insert、update、deleteMaster 在执行完更新操作后立即向应用程序返回响应，然后 Master 再向 Slave 复制数据。
数据更新过程中 Master 不需要等待 Slave 的响应，因此异步复制的数据库实例通常具有较高的性能，且 Slave 不可用并不影响 Master 对外提供服务。但因数据并非实时同步到 Slave，而 Master 在 Slave 有延迟的情况下发生故障则有较小概率会引起数据不一致
2)半同步复制: AP模型
Master等待Slave写入relaylog返回client & Slave宕机或网络中断，Master暂停10s 降级 异步复制，Slave恢复后 恢复半同步复制 => 性能居中，可用性优先，极端场景少量不一致；
应用发起数据更新（含 insert、update、delete 操作）请求，Master 在执行完更新操作后立即向 Slave 复制数据，Slave 接收到数据并写到 relay log 中（无需回放执行）后才向 Master 返回成功信息，Master 必须在接受到 Slave 的成功信息后再向应用程序返回响应。
仅在数据复制发生异常（Slave 节点不可用或者数据复制所用网络发生异常）的情况下，Master 会暂停（MySQL 默认10秒左右）对应用的响应，将复制方式降为异步复制。当数据复制恢复正常，将恢复为半同步复制。
3) 强同步复制: CP模型
Master等待Slave写入relaylog返回client; Slave宕机或网络中断，Master不会降级为 异步复制 => 保证强一致性，暂停对应用响应，直到Slave恢复正常 => 性能最差，强一致性 =>强一致性: 牺牲可用性，适合对一致性要求高，能够接收服务停机或暂时不可用，保证数据强一致性业务场景。
应用发起数据更新（含 insert、update、delete 操作）请求，Master 在执行完更新操作后立即向 Slave 复制数据，Slave 接收到数据并写到 relay log 中（无需执行） 后才向 Master 返回成功信息，Master 必须在接受到 Slave 的成功信息后再向应用程序返回响应。
在数据复制发生异常（Slave 节点不可用或者数据复制所用网络发生异常）的情况下，复制方式均不会发生降级，为保障数据一致性，此时 Master 会暂停对应用的响应，直至异常结束。
3.MySQL主从同步方案：
- 主库记录binlog日志
- 从库dump binlog日志
- 从库回放日志恢复数据
- 数据最终一致性
4.MySQL主从复制原理：
- Master主库将数据变更DataChanges记录 binlog日志中。
- Slave起一个I/O线程连接到Master，dump读取Master的binlog日志并写入到Slave的中继日志Relaylog中。
- Slave中的SQL线程读取中继日志Relaylog进行SQL回放执行操作，完成主从复制，保证主从最终一致性。
5.MySQL主从同步问题&优化：
1.MySQL 怎么保证数据强一致性?
需要保证强一致性场景建议 MySQL 采用强同步复制采用一主两备的架构，仅需其中一台 Slave 成功执行即可返回，避免了单台 Slave 不可用影响 Master 上操作的问题，提高了强同步复制集群的可用性。
2.MySQL 主从延迟如何解决?
主从同步机制决定本质上避免不了复制延迟问题, 只能缓解 。
主从延迟缓解方案:
- 硬件加速: SSD高性能硬盘
- 读写分离，分担主库压力
- Sharding分库分表
- 从库关闭binlog
- 并行复制加速(商业化版本)
- GTID 事务组复制
- 应用层架构优化: MQ异步消息解耦、多级缓存加速处理
主从延迟兜底策略：
核心业务强制读主库(注意读写压力不大可以)
如果想从根本上解决同步延迟问题：
需要采用强一致性协议处理: Paxos 强一致性算法处理(实现起来相对复杂) 推荐使用TiDB(Raft协议) ; 比如: NewSQL-TiDB 采用Raft协议保证强一致性并且能够兼容MySQL协议。
补充: 单线程复制造成延迟问题
#1.1. 主库记录日志-> 从库异步拉取日志-> 主从切换时新主丢日志（造成数据一致性问题）
#1.2 主库并发执行-> 从库单线程执行-> 主从同步延迟(幻读问题:主库新版本，从库老版本)
解决方案：
采用强同步复制 或 半同步复制
• 日志发送到从库落盘事务提交; 分组半同步
• 每个逻辑机房一个一致性群组
•异步ACK提升性能
#1.2 解决方案：并行复制
多worker并行复制原理：
• SQL线程负责解析日志
• 多Worker并发执行
• 行级别冲突检测(db+table+primary_key ):通过db+table+primary 唯一key做行级别冲突检测，如果已经消费则不再消费。
• 排队提交： 按照主库提交顺序排队提交，保持一致性。如：Master先更新A表再更新B表，Slave也应按照此顺序排队提交从而保持数据最终一致性。
• 消除主从同步延迟
我是架构师kimze，喜欢我的文章欢迎关注我,
我会坚持分享干货: 互联网微服务架构、云原生架构、行业动态、经典案例、技术趋势，
有问题欢迎关注私信或评论区回复交流
点赞、收藏、转发、评论 对我是一种支持，感谢！
加载中,请稍侯......
网友评论