原创做者: 管长龙 译算法
做者:Ricardo Ferreira 翻译:管长龙 标签:Group Replication, High Availability安全
随着 MySQL 8.0.16 的发布,咱们为 MGR 添加了一些功能,以加强其高可用性。其中一个功能是可以在某些状况下启用已离开组的成员自动从新加入,而无需用户干预。服务器
为了理解这个功能的好处以及如何使用它,咱们将快速查看它背后的概念以及它首先存在的动机。网络
MGR 容许 MySQL 用户轻松管理高可用组,并完成保证系统高可用所需的全部特征,例如容错或故障检测。架构
MGR 中提供的基本保证之一是该组呈现给用户的是一个不可分割的总体,这意味着一旦成员加入或离开该组,该更改将当即被其余成员得知。默认状况下,组内的数据自己最终是一致的,尽管能够被修改。为了实现这种保证,MGR 使用组成员服务,以及经过一致性算法检测有冲突的事务并停止它们。MGR 的这一方面超出了本文的范围,与成员自动从新加入功能并不彻底相关,本文不做赘述。分布式
组内新成员必须符合一些条件。其中新成员须要在事务方面遇上组进度(是经过选择组内一个成员来将已处理的事务流式传输给他,在 MGR 中称为“捐赠”)。最后,只要在此“分布式恢复”过程当中没有遇到任何错误,组内新成员将被声明为 ONLINE 状态。性能
MGR 依靠组通讯层 (GCS) 来管理组。该层实现了用于解决冲突事务的一致性算法,并强制执行一些通讯特性。对于实现前面提到的组的不可分割视图,这些特性相当重要,如消息的总顺序、安全传递或视图同步等。spa
GCS 须要可以检测组中哪些成员失效或看起来失效。一旦这些成员被检测为失效,就将其从该组中移除,以便保持该组正常使用。为此 GCS 在每一个成员中引入了一个故障检测器,用于分析组内交换的消息。若是它在一段时间内没有收到来自指定成员的消息,则故障检测器将对该成员产生“怀疑”,并认为该成员可能已经失效。成员从“怀疑”到真正失效的等待时间是能够配置的。线程
从新加入成员存在的问题翻译
咱们已经了解 MGR 必须为了高可用提供的策略,以及它如何实现,接下来请看示例:
一个小组由三个成员组成,其中一个成员偶尔会遇到丢失数据包、断连或者其它致使没法解决的错误状况的影响组内通讯。还要考虑这些错误持续时间超过 group_replication_member_expel_timeout 的值。
其中一个组员发生故障,小组的其余成员将决定踢出该成员。问题是,一旦该成员从新入组,他将被组驱逐加入失败,须要经过手动干预。
若是该成员的驱逐超时属性设置不为 0,则它将在被驱逐前等待知足该时间量(将超时设置为 0 意味着他将永远等待)。超时后成员将被驱逐并从新创建链接,而且没法从新加入旧组,须要再次手动干预。
于此,当存在网络故障时,显然须要手动干预。
在 MySQL 8.0.16 中,咱们引入了自动从新加入组的功能,一旦成员被驱逐出组,它就会自动尝试从新加入该组,直到达到预设的次数为止。有时每次重试之间至少等待5分钟。
如何启动自动从新加入?
能够经过将 group_replication_autorejoin_tries 设置为所需的重试次数来开启并使用自动从新加入功能。
SET GLOBAL group_replication_autorejoin_tries = 3
默认值为 0,表示服务器禁用自动从新加入。
如何验证自动从新加入?
与 MySQL 中的许多功能同样,自动从新加入过程是能够监测的。自动从新加入的可检测性依赖于性能模式基础架构,阶段式收集有关数据。
他们获取如下信息:
事件发生的线程ID(THREAD_ID)
活动名称(EVENT_NAME)
起止时间戳以及事件的总持续时间(TIMER_START,TIMER_END 和 TIMER_WAIT)
在事件中止以前完成的工做单位和预估工做单位(WORK_COMPLETED,WORK_ESTIMATED)
所以,当自动从新加入过程开始时,它将在 performance schema 中注册一个 名为“stage / grouprpl / Undergoing auto-rejoin procedure”的事件。使用表 performance_schema.events_stage_current, performance_schema.events_stages_summary_global_by_event_name 和performance_schema.events_stages_history_long 咱们能够观察到如下内容:
是否正在进行自动从新加入程序
到目前为止,已经减小重试的次数
直到下一次重试的估计剩余时间
自动从新加入过程状态
能够经过过滤包含“auto-rejoin”字符串的活动事件来查找自动从新加入过程状态(即,是否正在进行):
SELECT COUNT(*) FROM performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%'; COUNT(*) 1
查询结果存在,证实服务器上运行了自动从新加入过程。
到目前为止的重试次数
若是正在进行自动从新加入程序,咱们能够经过选择阶段事件上的工做单元数来检查到目前为止尝试的重试次数:
SELECT WORK_COMPLETED FROM performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%'; WORK_COMPLETED 1
在这个例子中,到目前为止只有一次尝试。
预计到下次重试的剩余时间
在每次从新加入尝试之间,服务器将处于 5 分钟的可中断睡眠中。 从新加入尝试直到成功或失败之间的时间是没法估计的。 所以,为了粗略估计剩余时间,咱们能够将到目前为止尝试的重试次数乘以 5 分钟,并减去到目前为止的阶段事件所花费的时间,以估计咱们还须要多长时间:
SELECT (300.0 - ((TIMER_WAIT*10e-12) - 300.0 * num_retries)) AS time_remaining FROM (SELECT COUNT(*) - 1 AS num_retries FROM performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%') AS T, performance_schema.events_stages_current WHERE EVENT_NAME LIKE '%auto-rejoin%'; time_remaining 30.0
因此在这个例子中,在下一次从新加入以前还有 30 秒。注意性能模式表中的全部时间记账都以微秒精度保持,所以咱们将 TIMER_WAIT 缩放为秒。
使用自动从新加入与驱逐超时的权衡
到目前为止,在这篇文章中咱们只关注自动从新加入。实际上,有两种不一样的方法能够实现离开组的成员的从新加入:
设置自动从新加入尝试次数来实现自动从新加入
设置该成员的驱逐超时时间而后配合手动干预
能有延缓删除组内可疑成员,而且若是配置为足够长的驱逐超时时间,则增长了从新创建链接的机会,再次与组进行交互。
虽然这两个功能实现了相同的目标,但它们的工做方式是不一样的,而且须要权衡。经过使用驱逐超时,您能够维护组中可疑的成员,其缺点是您没法添加或删除成员或选择新的主机。若是经过使用自动从新加入,该成员将再也不是该组的正常组员,将保持在 superreadonly 模式,直到从新加入该组。但在此期间,从新加入成员的同步旧数据的可能性将增长。自动从新加入过程可监控,而驱逐超时不是真正可监控的。
因此,总结一下:
- 该成员一直在该组内
- 可能更适合足够小的网络故障
- 在怀疑某个成员时,没法在该组上添加/删除成员
- 在怀疑某个成员时,没法选择新的主机
- 您没法监控此过程
- 该组将在没有从新加入成员的状况下运行,您能够添加/删除成员并选择新的主机
- 您能够监控该过程
- 您增长了从新加入成员上过期读取的可能性
- 可能不适合足够小的网络故障
总而言之,我从启用自动从新加入中得到了什么?
经过启用自动从新加入,您能够减小对MySQL实例的手动干预的须要。您的系统
更加适应瞬间网络故障,同时知足对容错性和高可用的保证。
咱们引入了一个名为 group_replication_autorejoin_tries 的新系统变量,容许用户设置 MGR 成员在被驱逐或与组的大多数人失去联系后尝试从新加入组的次数。
默认状况下,此自动从新加入过程处于关闭状态。它能帮助用户在面对瞬间网络故障时避免对 MGR 成员进行手动干预。