老生常谈：MySQL 高可用，java 泛型原理

一主一备：

=====

MySQL 的各种高可用架构，都脱离不了 MySQL 实例之间的数据同步，因此，我们先介绍下最简单的一主一备架构下 MySQL 的数据同步流程。

上图是主从数据同步的一个示意图。

• Master 节点有 Dump 进程把 binlog 中的数据发送到 Slave 节点，

• Slave 节点有 IO 进程接收数据写入 relay log，

• Slave 节点的 SQL 进程根据 relay log 写入数据。

这里还要延伸一点，binlog 存在三种形式：Statement、Row、Mixed。

• Statement：就是把每一条 SQL 记录到 binlog 中。

• Row：是把每一行修改的具体数据记录到 binlog 中。

• Mixed：MySQL 会灵活的区分，需要记录 sql 还是具体修改的记录。

只记录 SQL 的话 binlog 会比较小

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

，但是有些 SQL 语句在主从同步数据的时候，可能会因为选择不同的索引在数据同步过程中出现数据不一致。记录 Row 的话就可以保证主从同步不会存在 SQL 语意偏差的问题，同时 Row 类型的日志在做数据恢复的时候也比较容易，但是 Row 会导致 binlog 过大。

MySQL 主从同步的几种模式：

===============

• 异步模式：

在这种同步策略下，主库按照自己的流程处理完数据，会直接返回结果，不会等待主库和从库之间的数据同步。 优点：效率高。 缺点：Master 节点挂掉之后，Slave 节点会丢失数据。

• 全同步模式： 主库会等待所有从库都执行完 sql 语句并 ACK 完成，才返回成功。 优点：有很好的数据一致性保障。 缺点：会造成数据操作延迟，降低了 MySQL 的吞吐量。

• 半同步模式：主库会等待至少有一个从库把数据写入 relay log 并 ACK 完成，才成功返回结果。 半同步模式介于异步和全同步之间。

半同步的复制方案是在 MySQL5.5 开始引入的，普通的半同步复制方案步骤如下图：

• Master 节点写数据到 Binlog，并且执行 Sync 操作。

• Master 发送数据给 Slave 节点，同时 commit 主库的事务。

• 收到 ACK 后 Master 节点把数据返回给客户端。

这种数据提交模式叫： after_commit

after_commit 模式存在问题： 主库等待 ACK 时，事务已经 commit，主库的其他事务可以读到 commit 的数据，这个时候如果 Master 崩溃，slave 数据丢失，发生主从切换，会导致出现幻读。 为了解决这个问题 MySQL5.7 提出了新的半同步复制模式： after_sync

把主库的事务提交放到了 ACK 之后，避免了上述问题。 MySQL5.7 还引入了 enhanced multi-threaded slave （简称 MTS）模式, 当 slave 配置 slave_parallel_workers >0 并且 global.slave_parallel_type ＝‘LOGICAL_CLOCK’,可支持一个 schema 下，slave_parallel_workers 个 worker 线程并发执行 relay log 中主库提交的事务，极大地提高了主从复制的效率。 MySQL5.7 半同步功能可以通过 rpl_semi_sync_master_wait_slave_count 参数配置 slave 节点 ACK 的个数，认为主从同步完成。

基于 MySQL 主从同步数据越来越完善，效率越来越高，也就引出了第一种 MySQL 的高可用架构： 基于 MySQL 自身的主从同步方案，常用的一种部署架构是： 用户通过 VIP 访问 Master 和 Slave 节点，每个节点采用 keepalved 探索。配置主从关系，进行数据同步。