面对Semi-Synchronous复制

上个月我进行了审查雷竞技下载官网Percona运营商MySQL服务器仍然是α。运营商是基于Percona MySQL服务器,并使用雷竞技下载官网标准的异步复制,选择激活semi-synchronous复制获得更高级别的节点之间的数据的一致性。

整个解决方案是由:

另外,协调器(https://github.com/openark/orchestrator)是用于管理的拓扑和设置来启用复制节点,如果需要semi-synchronous的旗帜。虽然我们没有过多的说当使用标准异步复制,我想写几句话的需求和期望semi-synchronous (semi-sync)解决方案。

一个看着Semi-Synchronous

异步和Semi-sync之间的区别。

异步:

上面的图代表标准异步复制。预计该方法通过设计,对源事务提交不在场的副本。的应该是复制品赶上在可能的情况下。

同样重要的是要理解,在复制有两个步骤:

数据复制,它通常是非常快。数据从binlog复制源到中继日志的副本(IO_Thread)。
数据应用,数据从继电器读取登录数据库本身内部的副本节点和书面(SQL_Thread)。这一步通常是瓶颈,虽然有一些参数来优化,应用交易的效率取决于许多因素,包括模式设计。

生产部署,利用异步的解决方案通常是用来管理可能不一致的情况给出数据来源是不应该在副本提交。同时,分配给这个解决方案的高可用性水平低于我们通常与(几乎)获得同步复制,我们可能需要等待复制给补上的差距累积前relay-logs执行故障转移。

Semi-sync:

上面的图代表了Semi-sync复制方法。semi-sync的引入增加了检查一步源之前将确认返回给客户端。这一步的时刻发生在数据复制,因此,当数据从Binary-log复制源到Relay-log复制品。

这很重要,没有机制来确保一个更有弹性或有效的数据复制,只有一个额外的步骤,告诉源给定的时间等待答案从N副本,然后返回应答或超时并返回给客户端。

引入这种机制可能的显著延迟服务,不给一个100%的保证数据一致性。

而言,可用性的服务,在存在高负载时,这种方法可能导致停止供应来源请求在等待应答,大大减少了服务本身的可用性。

同时,唯一可以接受的设置对rpl_semi_sync_source_wait_point AFTER_SYNC(默认)是因为:在源出现故障时,所有交易承诺在源已经复制到副本(保存到它的中继日志)。意外退出的源服务器复制和故障转移是无损的,因为是最新的复制品。

都清楚了吗?没有?我简化了的事情。

在标准的复制,你有两个时刻(我简化)
- 将数据从源复制到副本
- 应用中的数据复制节点
没有认证的数据应用的一致性与源
与异步任务是编写数据来源binlog和忘记
与semi-sync源binlog写数据和等待T秒收到一个承认从N服务器收到的数据。

使semi-sync你遵循以下步骤:https://dev.mysql.com/doc/refman/8.0/en/replication-semisync-installation.html

简而言之:

注册插件
启用源rpl_semi_sync_source_enabled = 1
使复制品rpl_semi_sync_replica_enabled = 1
- 如果复制正在运行停止/启动IO_THREAD复制品

这里有趣的开始,许多“做好准备等待whaaat ?”。

什么是T和N我刚刚上面提到的?

T是一个超时,您可以设置为避免源永远等待副本承认。默认值是10秒。如果源多等待超时?
rpl_semi_sync_source_timeout控制源在提交等待多久从副本之前超时和承认恢复到异步复制。

谨慎的措辞!手册说源,所以它不是MySQL恢复到异步的,事务或连接,它是整个服务器。

现在分析工作日志(见https://dev.mysql.com/worklog/task/?id=1720和更多的引用)源应该尽快恢复semi-synchronous所有涉及副本是一致的。

然而,检查代码(见https://github.com/mysql/mysql-server/blob/beb865a960b9a8a16cf999c323e46c5b0c67f21f/plugin/semisync/semisync_source.cc L844和后),我们可以看到,我们没有100%的保证源能够切换。

还在代码中:
但是,它不是那么容易检测到副本了。这是由于这样的事实,MySQL的复制协议是异步的,也就是说,如果源不使用semi-sync协议,不会发送任何复制品来源。

在所有的运行测试,无法切换。简而言之,正从semi-sync,这是源永远,没有回滚。请记住,当我们继续。

我上面提到的N是什么?它代表了副本的数量必须提供应答。

如果你有10个节点的集群,您可能需要参与semi-sync只有他们两个,不需要包括他们所有人。但是如果你有三个节点的集群,一个是源,只依靠一个复制品,它不是真正的安全。我的意思是,如果你选择semi-synchronous确保数据复制,它支持一个节点是不够的,如果该节点崩溃,你注定失败,这样你至少需要两个节点semi-sync。

总之,关键是如果一个副本需要超过T回答,可能整个机制停止工作,直到永远。

正如我们以上所见,让semi-sync来源我们操纵全局变量的值rpl_semi_sync_source_enabled。

然而,如果我检查的价值rpl_semi_sync_source_enabled当源转移到简单的异步复制,因为超时:

选择@@rpl_semi_sync_source_enabled;

选择@@rpl_semi_sync_source_enabled;+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | @@rpl_semi_sync_source_enabled | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 1 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

选择 @@rpl_semi_sync_source_enabled;

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

|@@rpl_semi_sync_source_enabled|

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

|1|

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

正如你所看到的全局变量的报告值为1,这意味着semi-sync如果不是很活跃。

在文档中,据报道,监控semi-sync活动我们应该检查Rpl_semi_sync_souraybet雷竞技竞猜在线官网rce_status。这意味着你可以吗Rpl_semi_sync_source_status = 0和rpl_semi_sync_source_enabled = 1在同一时间。

这是一个错误吗?根据文档:

当源开关之间异步或semisynchronous复制由于commit-blocking超时或复制品迎头赶上,它集Rpl_semi_sync_source_status的价值或适当Rpl_semi_sync_master_status状态变量。从semisynchronous自动回退到异步复制的源意味着有可能rpl_semi_sync_source_enabled或rpl_semi_sync_master_enabled系统变量的值1在源端即使semisynchronous复制实际上是不操作。您可以监视Rplraybet雷竞技竞猜在线官网_semi_sync_source_status或Rpl_semi_sync_master_status状态变量来确定源目前使用异步或semisynchronous复制。

这不是一个错误。然而,由于你记录它,它不会改变事实这是一个奇怪的/友好/违反直觉的方法,提出了许多,许多可能的问题。特别是你知道源可能无法开关semi-synch回来。

这一部分,我们可以总结如下:

你激活semi-sync设置一个全局变量
服务器/源可以禁用它(默默地)不改变变量
服务器将不会自动恢复semi-sync
检查如果semi-sync的工作方式是使用状态变量
当Rpl_semi_sync_source_status = 0和rpl_semi_sync_source_enabled = 1你有超时和源现在在异步复制工作
重新激活semi-sync的方法是设置rpl_semi_sync_source_enabled第一然后rpl_semi_sync_source_enabled =。
与semi-sync副本可以设置开/关但除非你不停止/启动Replica_IO_THREAD的状态变量可以与服务器的状态不一致。

会出现什么问题?