mysql主从架构原理

---

前言

msyql是开源的关系数据库，个人或小公司主要以单机版为主。单机版存在问题是在高并发场景下无法做负载均衡，然后为了满足需求msyql官方提供了一种主-从复制的模型，将所有写（insert、update和delete）操作全部执行在主数据库，将所有查询操作执行从数据库，一般情况下是一个主数据库对应多个从数据库（架构模型有很多，一主多从是最常用，也是推荐的模型），本文也主要以这种模型来讨论。

原理

msyql的主从架构原理主要通过binary log（二进制日志）和 relay log（中继日志）来完成。复制步骤如下：

• 第一步 客户端通过session线程将写操作执行到master数据（主库）。
• 第二步 当客户端提交事务时master数据库将操作sql记录到binary log日志。
• 第三步 slave数据库（从库）开启IO线程向master数据库读取binary log日志增量数据保存到自己的relay log日志，且返回同步确认。
• 第四步 slave数据库开启SQL线程将relay log日志数据解析为sql并执行（标准执行sql流程）。

msyql在5.7以前提供了异步复制、同步复制和半同步复制 3种模式，直到5.7才新增一个无损复制下面详细讨论他们优缺点。

异步复制

客户端提交事务时，异步将操作sql记录到binary log日志，直接返回事务成功。这时slave节点还没有同步数据master节点就挂掉，导致数据丢失。

优点

异步处理性能高，如果对数据的一致性不是很高，推荐这个种模式
提高TPS

缺点

无法保证数据的一致性

同步复制

客户端提交事务时，将操作sql记录到binary log日志，且等待所有Slave数据库同步成功后才返回事务成功，否则事务失败，保证了数据的一致性，但是在等待Slave数据确认时间可能会很长导致性能下降。

优点

保证数据的一致性

缺点

性能低
降低TPS

半同步复制

客户端提交事务时，将操作sql记录到binary log日志，且等待所有Slave数据库同步状态，如果等待一段时间（一般是5秒）后任然没有得到确认消息，则将同步转为转异步等待且直接返回事务成功，这是一种折中方法，一定程度上保证了数据的一致性和性能。

优点

是同步复制和异步复制的一种优化方法，一定程度上既保证了数据的一致性和性能

缺点

当从同步转为异步后任然存在数据丢失的可能

无损复制

该模式需要全局唯一标识（全局事务ID），采用类似于Paxos的分布式一致性协议来实现。当客户端提交事务时，将数据记录到binary log日志，且等待过半的Slave数据库返回确认结果，返回事务成功。

优点

保证了数据的一致性和性能，5.7之后推荐这种模式

缺点

实现复杂

binary log（二进制日志）

binary log通常我们也叫做binlog，它是采用二进制格式记录数据库中所有事务的操作sql。比如我们使用insert新增一条数据，当提交事务时会往binlog日志中添加一条记录数据（记录sql语句）

relay log（中继日志）

mysql数据库（从数据库）开启一个IO线程向另个数据库（主数据库）读取binlog日志数据，然后将日志信息写入到自己的relay log日志，所以relay log日志是保存IO线程读写到的数据。

到这里原理讲完了，根据上面我们可知:

• 主库是基于事务来完成 ，master数据库建议将事务级别设置为读已提交（Read committed）
• 从库是基于IO线程和SQL线程来完成，slave数据库必须保证IO线程和SQL线程启动成功

总结

每一个同步模式都有自己的优缺点，对数据要求不是很高推荐使用异步复制模式，对性能要求不高且对数据一致性有强烈要求推荐使用同步复制模式，一般场景在mysql5.7之后推荐使用无损复制模式。