MySQL主从复制之增强半同步(无损复制)、延迟和并行复制

0    400    4

👉 本文共约3444个字,系统预计阅读时间或需13分钟。

简介

MySQL主从复制过程:

MySQL主从复制之增强半同步(无损复制)、延迟和并行复制

主从复制方式

MySQL有四种同步方式:
1、异步复制(Async Replication)
2、同步复制(sync Replication)
3、半同步复制(Async Replication)
4、增强半同步复制(lossless Semi-Sync Replication)、无损复制

1、异步复制(Async Replication)
主库将更新写入Binlog日志文件后,不需要等待数据更新是否已经复制到从库中,就可以继续处理更多的请求。Master将事件写入binlog,但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下,如果Master宕机,事务在Master上已提交,但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制,此时Slave也可能会丢失事务。MySQL复制默认是异步复制,异步复制提供了最佳性能。

2、同步复制(Sync Replication)
主库将更新写入Binlog日志文件后,需要等待数据更新已经复制到从库中,并且已经在从库执行成功,然后才能返回继续处理其它的请求。同步复制提供了最佳安全性,保证数据安全,数据不会丢失,但对性能有一定的影响。

3、半同步复制(Semi-Sync Replication)
主库提交更新写入二进制日志文件后,等待数据更新写入了从服务器中继日志中,然后才能再继续处理其它请求。该功能确保至少有1个从库接收完主库传递过来的binlog内容已经写入到自己的relay log里面了,才会通知主库上面的等待线程,该操作完毕。
半同步复制,是最佳安全性与最佳性能之间的一个折中。
MySQL 5.5版本之后引入了半同步复制功能,主从服务器必须安装半同步复制插件,才能开启该复制功能。如果等待超时,超过rpl_semi_sync_master_timeout参数设置时间(默认值为10000,表示10秒),则关闭半同步复制,并自动转换为异步复制模式。当master dump线程发送完一个事务的所有事件之后,如果在rpl_semi_sync_master_timeout内,收到了从库的响应,则主从又重新恢复为增强半同步复制。
ACK (Acknowledge character)即是确认字符。

4、增强半同步复制(lossless Semi-Sync Replication、无损复制)
增强半同步是在MySQL 5.7引入,其实半同步可以看成是一个过渡功能,因为默认的配置就是增强半同步,所以,大家一般说的半同步复制其实就是增强的半同步复制,也就是无损复制。
增强半同步和半同步不同的是,等待ACK时间不同
rpl_semi_sync_master_wait_point = AFTER_SYNC(默认)
半同步的问题是因为等待ACK的点是Commit之后,此时Master已经完成数据变更,用户已经可以看到最新数据,当Binlog还未同步到Slave时,发生主从切换,那么此时从库是没有这个最新数据的,用户看到的是老数据。
增强半同步将等待ACK的点放在提交Commit之前,此时数据还未被提交,外界看不到数据变更,此时如果发送主从切换,新库依然还是老数据,不存在数据不一致的问题。

图示如下:

MySQL主从复制之增强半同步(无损复制)、延迟和并行复制

异步复制示例

MySQL主从复制之1主2从异步复制搭建及同步测试参考:https://www.xmmup.com/dbbao64mysqlzhucongzhi1zhu2congyibufuzhidajianjitongbuceshi.html

如何配置半同步复制

延迟从库

延迟从库:从库落后于主库一段时间。
SQL线程延时:数据已经写入relaylog中了,只是让SQL线程"慢点"运行

MySQL延迟复制的好处主要有几点:
1.误删除时,能更快恢复数据。有时候手抖了,把线上数据给误删除了,或者误删除库、表、其他对象,或不加WHERE条件的更新、删除,都可以让延迟从库在误操作前的时间点停下,然后进行恢复。
2.把延迟从库作为专用的备份节点。虽然有一定的延迟,但并不影响利用该节点作为备份角色,也不影响生产节点数据库。
3.还可以把延迟从库当做一些问题、案例研究的对象。个别时候,可能有些Binlog Event在普通从库上会有问题(例如:早期版本中无主键会导致从库更新非常慢的经典问题),这时就有时间在延迟从库上慢慢琢磨研究了。

一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间。

启用延迟从库的方法也挺简单的:

并行复制

MySQL 5.6提供了并行复制,但是这种并行只是基于database的(slave-parallel-type=DATABASE)。如果用户的MySQL数据库实例中存在多个database,对于从库复制的速度的确可以有比较大的帮助。如果是基于单个database的复制依然无法做到真正的并行回放,这个阶段很多DBA将数据库进行垂直拆分,将一个database拆分成几个database,通过设置slave_parallel_workers=n,可以进行database级别的并行复制,但对于热点业务复制延迟依然无法解决。参数slave_parallel_workers默认值为0,表示禁用并行。

到了MySQL 5.7,才实现了真正的并行复制(slave-parallel-type=LOGICAL_CLOCK),复制效率提升很多。MySQL 5.7的并行复制,multi-threaded slave即MTS,期望最大化还原主库的并行度,实现方式是在binlog event中增加必要的信息,以便slave节点根据这些信息实现并行复制。

要开启 MySQL 5.7 并行复制需要以下2步:
1、首先在主库设置 binlog_group_commit_sync_delay 的值大于0 。

binlog_group_commit_sync_delay 全局动态变量,单位微妙,默认0,范围:0~1000000(1秒)。
表示 binlog 提交后等待延迟多少时间再同步到磁盘,默认0 ,不延迟。当设置为 0 以上的时候,就允许多个事务的日志同时一起提交,也就是我们说的组提交。组提交是并行复制的基础,我们设置这个值的大于 0 就代表打开了组提交的功能。
binlog_group_commit_sync_no_delay_count 全局动态变量,单位个数,默认0,范围:0~1000000。
表示等待延迟提交的最大事务数,如果上面参数的时间没到,但事务数到了,则直接同步到磁盘。若 binlog_group_commit_sync_delay 没有开启,则该参数也不会开启。

2、其次要在 Slave 主机上设置如下几个参数:

一、1主2从之增强半同步复制(无损复制)示例

MySQL主从复制之增强半同步(无损复制)、延迟和并行复制

半同步复制比异步复制多了如下步骤:

1、MySQL环境初始化

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

2、主库配置

执行过程:

3、从库1配置

4、从库2配置

5、主从查询

半同步复制查询:

Rpl_semi_sync_master_clients表示记录支持半同步的slave的个数

Rpl_semi_sync_master_status标记master现在是否是半同步复制状态

6、测试半同步复制

测试过程:

1、关闭从库io线程,模拟网络卡顿

2、主库插入数据,等待10秒,同步方式自动转换为异步模式

3、从库启动io线程

4、同步方式变为半同步模式

先关闭一个从库,我们测试1主1从的情况。

MySQL主从复制之增强半同步(无损复制)、延迟和并行复制

二、配置延迟复制示例

我们把从库2配置为延迟从库,如下所示:

三、配置并行复制示例

3.1、主库配置

3.2、从库2配置并行复制

只在从库2做配置,从库1不做配置。

3.3、主库压测测试并行复制

因为这里的架构为1主2从,我只配置了从库2为并行复制,从库1不是并行复制,那么接下来测试并行复制的效果。

首先,取消从库2的延迟复制功能:

首先,主库进行压测生成数据:

结果:

可以看到,从库2比从库1能至少快一倍。

若是将从库的slave_parallel_workers配置为16,则配置了并行复制的库基本无延迟,而没有配置并行复制的库,延迟会越来越严重

重新测试,可以看到从库2基本无延迟了:

    头像

    小麦苗

    学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

    您可能还喜欢...

    发表评论

    您的电子邮箱地址不会被公开。

    7 − 7 =

     

    嘿,我是小麦,需要帮助随时找我哦
    • 18509239930
    • 个人微信

    • 麦老师QQ聊天
    • 个人邮箱
    • 点击加入QQ群
    • 个人微店

    • 回到顶部
    返回顶部