Mysql Master-Slave(MS)架构高可用概述

高可用Mysql是依赖复制(Replication)来实现的。复制解决的问题就是将一台数据库服务器上的数据同步到其他服务上。

Mysql数据库的复制有如下三个步骤:

1. 在主库上的数据更改记录到二进制日志(binary log)中。

2. 从库将主库上的binary log复制到自己的中级日志(relay log)中。

3. 从库读取relay log中的事件(Event),将其回放到从库上。

 

数据一致性使用RPO(Recover Point Objective)来衡量,Mysql的复制也一直在追求RPO=0的境界。

MS架构在实现高可用的同时面临着数据一致性问题,当高可用数据库在进行Failover时,可能数据还没复制完毕,这样就会出现数据不一致的问题。

Mysql MS架构Replication的变迁历史:异步复制(Asynchronous Replication)--> 半同步复制(Semisynchronous Replication) --> 增强型半同步复制(Enhenced Semisynchronous Replication) --> 组复制(MGR:Mysql Group Replication)。

异步复制(Asynchronous Replication)

 

  • 描述:Mysql默认的复制模式。主库在执行完用户提交的事务后,将事务事件写入到Binlog文件中,这时主库会通知Dump线程将Binlog文件同步到从库中,然后主库将继续处理用户的提交,而不保证Binlog传送到任何一个从库上。
  • 不足之处:
    • 若主库发生Crash,其上已经提交的事务可能没有同步到从库上,此时Failover会导致新主库上数据不完整,发生数据不一致问题。
    • 因为主库和从库的事务更新不同步,即便没有发生宕机,当业务的并发量上来时,因为slave需要顺序处理master批量事务,所以也会造成很大的延迟。

 半同步复制(Semisynchronous Replication)

 

  • 描述:
    1. 主库在事务线程提交后,阻塞等待从库的ACK。
    2. 从库将接收到的Binlog写入到Relay log之后,向主库返回ACK。
    3. 主库将commit OK返回给客户端。
  • 注意:
    • 主库等待从库返回ACK的时间点由参数rpl_semi_sync_master_wait_point=AFTER_COMMIT设置。
    • 等待几个从库返回ACK,由参数rpl_semi_sync_master_wait_for_slave_count=1设置。
    • 其中还有一个半同步超时的设置,由参数rpl_semi_sync_master_timeout=100控制,超时后半同步复制退化为异步复制。
    • 主库的Dump线程除了发送事务到从库上,还承担接收从库的ACK工作。
  • 优点:
    • 可以很明确地知道在事务提交成功之后,这个事务就至少会存在两个地方。
  • 不足:
    • 主库在等待从库ACK过程中,虽然没有返回客户端commit OK,但事务已经提交,其他客户端会读到已提交的事务。
    • 如果在主库等待ACK过程中,从库还未读到该事务的Events, 但此时主库Crash and Failover了,那么之前提交的数据会丢失。

增强型半同步复制(Enhanced Semisynchronous Replication)

  • 描述:
    1. 主库在事务提交之前,阻塞等待从库的ACK。
    2. 从库将接收到的Binlog写入到Relay log之后,向主库返回ACK。
    3. 主库接收到ACK后,提交事务。
  • 注意:
    • 与半同步复制不同的点在于增强型半同步等待从库返回ACK的时间点为commit之前。
    • 增强半同步复制等待备库ACK的时间点由参数rpl_semi_sync_master_wait_point=AFTER_SYNC。
  • 优点:
    • 主库只有在收到从库的ACK之后才会提交事务,即使主库crash,所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。
  • 不足:
    • 如果主库在提交事务之前发生了Crash,那么这次事务提交是失败的。但可能存在由于Binlog已经做了Sync操作,从库已经完成了Relay log的写入,那么从库上数据可能产生了变更。
    • 如果主库在写入Binlog之后,但尚未Sync到从库前发生了Crash and Failover,虽然新主库上的事务与原主库保持了一致,但当主机恢复后,由于原主库上的Binlog已经记录了最后的事务,造成了数据的不一致。

组复制(MRG)

// todo

 

 

 

参考资料

MRG:https://bbs.huaweicloud.com/blogs/115356

GTID:http://mysql.taobao.org/monthly/2020/05/09/

posted @ 2021-01-28 19:16  suffocat1ng  阅读(386)  评论(0)    收藏  举报