前言
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之后推荐使用无损复制模式。