欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

MySQL - 异步复制,半同步复制,增强半同步复制,组复制

程序员文章站 2022-06-22 19:12:49
1.什么是主从复制主从复制,是用来建立一个和主数据库完全一样的数据库环境,称为从数据库。可以理解为,主数据库的数据的任何变化,从数据库都会跟着发生变化。2.主从复制的作用在从服务器可以执行查询工作,降低主服务器压力;(主库写,从库读,降压)读写分离在从主服务器进行备份,避免备份期间影响主服务器服务;容灾当主服务器出现问题时,可以切换到从服务器。提高可用性3.主从复制的基本原理步骤含义:SQL语句操作变化存入BinLog......

1. 什么是主从复制

主从复制,是用来建立一个和主数据库完全一样的数据库环境,称为从数据库。

可以理解为,主数据库的数据的任何变化,从数据库都会跟着发生变化。

2. 主从复制的作用

  1. 在从服务器可以执行查询工作,降低主服务器压力;(主库写,从库读,降压)读写分离

  2. 在从主服务器进行备份,避免备份期间影响主服务器服务;容灾

  3. 当主服务器出现问题时,可以切换到从服务器。提高可用性

 

3. 主从复制的基本原理

 

MySQL - 异步复制,半同步复制,增强半同步复制,组复制

 

步骤含义:

  1. SQL语句操作变化存入BinLog日志中

  2. slave上线,连接到master服务器,进行数据同步

  3. dump thread线程把Binlog数据发送到slave中

  4. slave启动之后,创建一个I/O线程,读取master传过来的Binlog内容并写入到Relay log.

  5. slave还会创建一个SQL线程,从Relay log里面读取内容,从Exec_Master_Log_Pos位置开始执行读取到的更新事件,将更新内容写入到slave的db.

 

3.1. 并行加速复制

传统的MySQL(5.6 版本之前)主从复制是单线程复制,即:1个dump thread线程,1个IO线程,1个SQL线程

想要提高复制的效率,很自然考虑多线程,虽然有3种线程可以扩展为多线程。但是MySQL只将SQL线程扩展为多线程

为什么Dump和IO线程不能多线程?

  1. dump线程和IO线程都是负责网络传输,如果将这里扩展为多线程那么会将一份Binlog日志分割为多份,并行传输,那么在slave端将会要额外的增加代码考虑如何将多份日志还原为原来的Binlog,大大增加难度。

  2. 性能瓶颈不在IO,扩展后也没有多大效率提升。

画外音:为什么Redis 6.0使用IO多线程增强性能,MySQL这里使用IO多线程却不行?

Redis是多个Client节点一个Server节点(暂且这么看),IO线程需要处理多个不同Client来源的请求;MySQL主从复制,本质上是1个Client端一个Server端,增大IO线程也无济于事。

 

SQL线程并行后的难点

相同两个事务的执行顺序。假设A,B两个事务,A先执行,B后执行,都同时改同一行数据,如果主从同步过程中,因为并行执行,B先执行,A后执行,那么将导致数据不一致问题。所以需要一个机制去防止此类事情的发生。

对于这个问题,MySQL会判断当前需要复制的事务Id和与之前复制完毕的事务id进行比对,判断是否处于当前执行完毕事务之后,否则只能等待前驱事务复制完毕。(大概原理,本文不是讲解并行复制,不深入讲解

 

4. MySQL主从复制的方式

4.1. 异步复制

MySQL - 异步复制,半同步复制,增强半同步复制,组复制

 

MySQL 默认的复制策略,Master处理事务过程中,将其写入Binlog就会通知Dump thread线程处理,然后完成事务的提交,不会关心是否成功发送到任意一个slave中

 

问题:一旦Master 崩溃,发送主从切换将会发送数据不一致性的风险。

画外音:性能最好

4.2. 半同步复制

MySQL - 异步复制,半同步复制,增强半同步复制,组复制

 

Master处理事务过程中,提交完事务后,必须等至少一个Slave将收到的binlog写入relay log返回ack才能继续执行处理用户的事务。

配置

rpl_semi_sync_master_wait_point = AFTER_COMMIT (什么时间点开始等ack)【这里MySQL 5.5并没有这个配置,MySQL5.7 为了解决半同步的问题而设置的,下文有讲解

rpl_semi_sync_master_wait_for_slave_count = 1 (最低必须收到多少个slave的ack)

rpl_semi_sync_master_timeout = 100(等待ack的超时时间)

 

问题:

  1. 一旦Ack超时,将退化为异步复制模式,那么异步复制的问题也将发送

  2. 性能下降,增多至少一个RTT时间

  3. 数据不一致性问题,因为等待ACK的点是Commit之后,此时Master已经完成数据变更,用户已经可以看到最新数据,当Binlog还未同步到Slave时,发生主从切换,那么此时从库是没有这个最新数据的,用户又看到老数据。

4.3. 增强半同步复制

 

MySQL - 异步复制,半同步复制,增强半同步复制,组复制

 

增强半同步和半同步不同是,等待ACK时间不同

rpl_semi_sync_master_wait_point = AFTER_SYNC唯一区别

半同步的问题是因为等待ACK的点是Commit之后,此时Master已经完成数据变更,用户已经可以看到最新数据,当Binlog还未同步到Slave时,发生主从切换,那么此时从库是没有这个最新数据的,用户又看到老数据。

增强半同步将等待ACK的点放在提交Commit之前,此时数据还未被提交,外界看不到数据变更,此时如果发送主从切换,新库依然还是老数据,不存在数据不一致的问题。

 

问题:

  1. 一旦Ack超时,将退化为异步复制模式,那么异步复制的问题也将发送

  2. 性能下降,增多至少一个RTT时间

  3. 如果超时时间设置很大,然后因为网络原来长时间收不到ACK,用户提交是被挂起的,可用性收到打击(半同步一样存在)

 

画外音:感觉MySQL因为直接提供增强半同步,半同步类似个过度产品

4.4. 组复制

MySQL Group Replication(MGR)

MySQL - 异步复制,半同步复制,增强半同步复制,组复制

 

MySQL在引擎层完成Prepare操作写Redo日志之后,会被MySQL的预设Hook拦截进入MGR层

MGR层将事务信息打包通过Paxos协议发送到全部节点上,只要集群中过半节点回复ACK,那么将告诉所有节点数据包同步成功,然后每个节点开始自己认证(certify)通过就开始写Binlog,提交事务或者写relay log,数据同步,如果认证不通过则rollback

 

什么是Certify?

在不同服务器上并发执行的事务之间可能存在冲突。这种冲突是通过检查和比较两个不同的并发事务的写入集来检测的,这个过程称为认证

在认证期间,冲突检测是在行级别执行的:如果在不同服务器上执行的两个并发事务更新了同一行,则存在冲突。

冲突解决过程指出,首先排序的事务将在所有服务器上提交,而第二次排序的事务将中止,因此将在原始服务器上回滚并被组中的其他服务器丢弃。

 

总结:MGR内部实现了分布式数据一致性协议,paxos通过其来保证数据一致性。

 

问题

  1. 性能不高

  2. TP999升高,吞吐量降低;增大20%~30%响应时间

 

5. 对比

我们考虑架构的时候,不应该过于关心它能干啥,应该考虑每一种方式它不能干啥

MySQL - 异步复制,半同步复制,增强半同步复制,组复制

本文地址:https://blog.csdn.net/qq_33330687/article/details/107496954