Mysql组复制（MGR）—

本文提供mysql组复制相关的更多技术细节。

一. 组复制插件架构

Mysql组复制是一个mysql插件，且其构建于已有mysql复制架构之上，其利用了类似二进制日志，基于行的日志及全局事务标识符等的特点。组复制与当前mysql框架集成到一起，像性能模式或插件和服务架构。下图提供了描述mysql组复制整体架构的框图。

图1-1 组复制插件框图

Mysql组复制包含一套用于控制插件如何与mysql服务器进行交互的捕获、应用和生命周期的API。有使信息从服务器流向插件或相反方向的接口。这些接口将mysql服务器从组复制插件隔离开，且几乎为放置于事务执行管道中的吊钩。在一个方向，从服务器到插件，有事件的通知，像服务器启动、服务器恢复、服务器准备接受连接，及服务器打算提交事务。在另一个方向，插件指示服务器执行类似提交或中断正在进行事务的行动，或在中继日志中排队事务。

组复制插件架构中的下一层是一套组件，其在通知路由到它们是做出反应。捕获组件负责对正在执行事务的上下文进行跟踪。应用组件负责远程数据库上的执行。恢复组件管理分布式恢复，且负责加入复制组的服务器选择捐赠者并追上其他组成员，其安排追赶过程给并对捐赠者失败做出反应。

沿着栈继续往下，复制协议模块包含复制协议的特定逻辑。其处理冲突探测，并接收和传播组内的事务。

组复制组件的最后两层是组通信系统（GCS）API，及基于Paxos组通信引擎的实施。GCS API是一个高级API，其抽取构建一个复制状态机器所需的属性。因此，其从插件的其他更高层面将信息层的实施进行了解耦。组通信引擎处理与复制组其他成员的通信。

二. 组

Mysql组复制中，一套服务器形成了一个复制组。每个组有一个名字，其采取UUID的形式。组是动态的且服务器能在任何时候离开（自愿或非自愿）和加入复制组。无论何时服务器加入或离开，组自己都会进行调整。

如果一个服务器加入组，其通过从一个现有服务器获取丢失的状态来达到最新状态，例如：关闭服务器进行维护，其余服务器注意到该服务器已经离开并对组自动进行重新配置。

三. 数据操作语句

由于任何特定数据集没有任何主服务器，组内的每个服务器任何时候都允许执行事务，甚至允许改变状态的事务（RW事务）。

任何服务器无需预先协调就可以执行一个事务。但在提交时，其将与组内的其他服务器进行协调以得到该事务命运相关的决定。该协调服务器有两个目的：（i）检查该事务是否将提交；（ii）对该变更进行传播以便其他服务器也能应用该事务。

由于事务通过原子广播进行发送，组内的所有服务器都接收或都不接收该事务。如果接收，那么，它们都按照之前被发送其他事务的相关顺序接收该事务。冲突探测通过检查和比较事务的写集合进行。这样，其按照行级进行探测。冲突解决遵循先提交赢的规则。如果t1和t2在不同地点同时执行，因为t2排在t1前面，且两个事务都修改相同数据行，那么，t2将在冲突中获胜，而t1被中止。换句话说，t1试图改变t2提供的陈旧数据。

--注：

1）如果两个事务经常发生冲突，将其在同一个服务器上执行时很好的办法。这样，它们将有机会通过本地锁管理器进行同步，而非复制协议中的中止后者。

四. 数据定义语句

组复制拓扑中，当执行常被称为数据定义语言（DDL）的数据定义语句时需要小心。Mysql并不支持原子或事务DDL，不能乐观地执行DDL语句并稍后按需回滚。因此，缺乏原子性而不适合直接进行组复制基于的乐观复制规范。

所以，当复制数据定义语句时需要更加小心。当模式操作还没在所有地方完成复制时，模式改变和对象包含数据的改变需要通过相同服务器进行处理。否则，该操作失败将会导致数据不一致。

--注：

1）如果组部署于单主模式，那么，这不会有问题，因为所有变更会通过同一主服务器执行。

2）mysql DDL执行并非原子或事务的。服务器执行和提交前不会先获得组一致同意。这样，当DDL正执行并未复制到所有服务器时，您必须将同一对象的DDL和DML路由到同一服务器。

五. 分布式恢复

本部分描述一个成员加入复制组追上组内其他服务器的过程，称其为分布式恢复。

1. 分布式恢复基础

本部分是一个高级摘要。后续部分通过更详细描述该过程的各个阶段来提供另外的细节。

组复制分布式恢复能总结为一个服务器从复制组获取丢失的事务，以便其接着能加入其他组成员已处理同样一套事务的复制组。分布式恢复期间，加入该组的服务器当其接收从组申请的事务时，缓冲期间发生的任何事务和成员事件。一旦加入组的服务器已经接收了所有的组事务，其将应用恢复期间缓冲的事务。最后，服务器作为一个在线成员加入该复制组。

1）阶段1

第一阶段，加入复制组的服务器选择组内一个在线服务器作为其丢失状态的捐赠者。捐赠者负责为正加入组的服务器提供直到加入组时丢失的数据。这通过标准异步复制通道实现，该通道在捐赠者和正加入组的服务器间建立。通过该复制通道，捐赠者的二进制日志被复制，直到加入组的服务器变为组的一部分时视图变更发生的时间点为止。加入组的服务器接收捐赠者的二进制日志时对其进行应用。

复制二进制日志时，加入组的服务器也会缓冲组内交换的每个事物。换句话说，其对加入组后和应用来自捐赠者丢失状态期间发生的事务进行监听。当第一阶段结束并到捐赠者的复制通道关闭时，加入组的服务器接着开启阶段2：追赶。

2）阶段2

该阶段，加入组的服务器接着执行缓冲的事务。当排队等待执行的事务数最后达到零时，该成员将宣布在线。

3）弹力

当加入组的服务器从捐赠者获取二进制日志时，恢复进程将经受捐赠者失败。这种情况下，无论何时捐赠者在阶段1失败，加入组的服务器将切换到一个新的捐赠者并继续恢复。当这种情况发生时，加入组的服务器关闭到失败服务器的连接并打开到新捐赠者的连接。这些会自动发生。

2. 时间点恢复

为了将加入组的服务器与捐赠者同步到一个特定时间点，加入组的服务器和捐赠者利用mysql global transaction identifiers（GTIDs）机制。但是，GTIDs仅提供识别加入组服务器正丢失事务的方式，其并不会帮助标记加入组的服务器必须追到的时间点，也不会帮助传送认证信息。这是二进制日志视图标记器的工作，其标记二进制流中的视图变更，且还包含另外的元数据信息，为加入组的服务器提供丢失认证相关数据。

1）视图和视图变更

为了解释视图变更标记器的概念，理解什么是视图和视图变更很重要。

视图与当前配置中活动成员的组相对应，换句话说，在特定时间点，其在系统中是正常和在线的。

当修改组配置时，会发生视图变更，像一个成员加入或离开。任何组成员的变更会导致一个独立的视图变更，并在同一逻辑时间点通知所有成员。

视图鉴定符唯一识别一个视图。无论何时视图变更发生，就会生成视图鉴定符。

在组通信层，视图变更及其相关视图id是成员加入前后交换数据间的边界。该概念通过一个新二进制事件实施：“view change log event”。这样，视图 id也变为组成员变更前后传递事务的标记。

视图鉴定符本身也从两个部分构建：（i）随机产生的部分（ii）单向增长的整数。组创建时会产生第一部分，组内至少一个成员期间保持不变。每次发生视图变更时第二部分将会增加。组成视图id复合对的原因是，无论何时成员加入或离开，但也无论何时所有成员离开组且组所在的视图没有任何信息时，需要清楚地标记组变更。事实上，单独使用单调递增的鉴定符能导致整个组关闭后相同id的重用，从而破坏恢复数据依赖的二进制日志标记的唯一性。总之，第一部分标识复制组开始的时间，而递增部分标识从该点往后变更的时间。

3. 视图变更

本部分解释控制试图变更鉴定符如何包装进二进制事件并写入日志的过程，采取如下步骤：

1）开始：稳定的组（Begin: Stable Group ）

所有服务器在线并处理组输入的事务。某些服务器事务复制也许会延迟一点，但最终都会达成一致。组作为一个分布式分布式数据库进行活动。

图5-1 稳定的组

2）视图变更：成员加入（View Change: a Member Joins）

无论何时新成员加入组，因此，发生视图变更，每个在线服务器对视图变更时间进行排队和执行。之所以需要排队，是因为视图变更前几个事务可能在该服务器上排队应用，而这些事务属于旧视图。在其后对视图变更事件进行排队，保证了对其发生事件进行正确标记。

但是，加入组的服务器通过视图层的成员服务从在线服务器列中选出捐赠者。成员加入视图及在线成员向二进制日志写入视图变更事件。

图5-2 成员加入

3）状态转移：追赶（State Transfer: Catching Up）

一旦加入组的服务器选择组内的捐赠者服务器，两个服务器间新建一个异步复制连接，且开始状态转移（阶段1）。与捐赠者的交互继续，一直到加入组服务器的应用器线程对服务器加入组时触发视图变更的相应视图变更日志事件进行处理。换句话说，加入组的服务器从捐赠者进行复制，直到其达到匹配其已在视图标记的视图标识符的标记。

图5-3 状态转移：追赶

由于视图标识符在相同逻辑时间传送到组内的所有成员，加入组的服务器知道其在哪个视图标识符停止复制。这避免了复杂GTID集计算，因为视图id清楚的标记了数据所属的每个组视图。

当加入组的服务器从捐赠者复制时，其也会缓冲进入组的事务。最后，其停止从捐赠者复制并切换到应用缓冲的事务。

图5-4 排队的事务

4）完成：追上（Finish：Caught Up）

加入组的服务器认出希望视图标识符的视图变更日志事件，中止到捐赠者的连接并开始应用缓冲的事务。需要理解的一个重要知识点是最后的恢复过程。虽然其作为二进制日志中的标记，界定视图变更，视图变更日志事件也扮演另一个角色。当加入组的服务器进入组时，其传送所有服务器注意的认证信息，换句话说，就是最近的视图变更。否则，加入组的服务器将没有能认证（探测冲突）随后事务的必要信息。

追赶（阶段2）的时长是不确定的，因为其依赖负载和组中进来的事务率。该过程是完全在线的，且加入组的服务器当其正追赶时并不会阻止组内的任何其他服务器。所以，加入组的服务器当其移到阶段2时，其前面的事务数可能因此会变化，根据负载或多或少。

当加入组的服务器中没有排队事务时，其存储的数据与其他成员相同，其公共状态变更为在线。

图5-5 实例在线

5）分布式恢复的使用建议和限制

分布式恢复确实有一些限制。其基于传统的异步复制，且如果加入组的服务器不被提供或提供一个很旧的备份影响，这样，其将会非常慢。这意味着如果阶段1传输的数据量太大，服务器也许会花费很长时间才能恢复。这样，推荐的做法是向组添加一个服务器前，应该为其提供组内已有服务器的一个相当近的一个快照。这将阶段1的长度最小化，并减少了对捐赠者服务器的影响，因为，其必须保存和传输较少的二进制日志。

--注：

1）建议向组添加服务器前对其进行预配。这样，会将恢复步骤消耗的时间降到最低。

六. 观察性

组复制内建了很多自动化机制。尽管如此，您有时也许需要理解其内在机制。这就是组复制和性能模式体现重要性的地方。系统的整个状态（包括视图，冲突统计和服务状态）能通过performance_schema表进行查询。复制协议的分布式本质及服务器实例达成一致并同步事务和元数据的事实，使得检查组状态更加简单。例如：您能连接到组内的单个服务器上并通过对组复制相关的performance schema表发布select语句得到本地和全局信息。

七. 组复制性能

本部分解释如何使用可用的配置选项来得到复制组的最佳性能。

1. 精细调整组通信线程

当组复制插件加载时，组通信线程（GCT）循环运行。GCT从组和插件接收信息，处理任务相关的法定人数和失败探测，发送保持活动信息并处理来自或发送到服务器/组的输入和输出事务。GCT等待队列中的输入信息。当没有信息时，GCT等待。通过将进入睡眠前的等待配置的较长（进行活动等待）证明在某些场景是有益的。这是因为其他方案是操作系统将GCT从处理器切换出并做上下文切换。

为了强制GCT进行活动等待，使用group_replication_poll_spin_loops选项，其使得GCT在实际从队列中获取下一个信息前进行配置数目的空循环。例如：

mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;

2. 信息压缩

当网络带宽成为瓶颈时，信息压缩能在组通信级别提供30-40%的吞吐改善。这对高负载巨大服务器组的场景尤其重要。

组内N个参与者间互联的TCP端到端特性使得发送者发送N次相同数量的数据。然而，二进制日志可能表现出一个高的压缩比。这使得压缩成为包含巨大事务负载的一个引人入胜的特性。

图7-1 压缩支持

压缩在数据传递到组通信线程前，发生于组通信引擎级别，因此，其发生于mysql用户会话线程上下文。事务有效负载送出到组前被压缩，接收时解压缩。压缩是有条件的，其依赖于配置的阀值。默认会开启压缩。

此外，不要求组内的所有服务器开压缩，以便其能一起工作。接收信息时，组成员会检查信息信封以确认其是否被压缩。如果需要，组成员则在将该事物传递给其上层级前对其进行解压。

所用压缩算法为LZ4。默认1000000字节将开启压缩。按字节的压缩阀值可以设置为比默认大的值。该场景下，只有比该阀值大的有效负载的事务被压缩。下列为一个如何设置压缩阀值的例子：

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 2097152;
START GROUP_REPLICATION;
这将压缩阀值设置为2MB。如果一个事务产生了一个大于2MB有效负载的复制信息，例如：大于2MB的二进制日志事务项，则将对其进行压缩。将该阀值设置为0将禁用压缩。

3. 流控

组复制确保事务仅在组内大部分成员已经接收且就其在并发发送所有事务中的相对顺序达成一致后才提交。

如果对组写总数不超过组内任何成员容量时，该方法能很好的工作。如果某些成员比其他成员有较少的写吞吐，尤其是比写入成员的吞吐较少，则这些成员将会落在写服务器之后。

某些成员落后会带来某些有问题的后果，尤其是，这些成员上读的数据会比较陈旧。根据成员落后于组内其他成员的原因，其也许必须保存或多或少的复制上下文来满足来自于该慢成员的潜在数据请求。

但是，按照应用事务，复制协议中有一个机制来避免慢成员比快成员落后很多。该机制称为流控。其尽力处理几个目标：

1）保持成员间足够近以便使得缓冲和成员间异步问题更小；

2）快速适应像组内不同负载或更多写操作等的变化场景；

3）为每个成员公平分配可用写容量；

4）不会将吞吐减少到比严格必须更少以避免资源浪费。按照组复制设计，是否进行节流也许考虑两个工作队列进行决定：（i）认证队列；（ii）二进制日志应用器队列。无论何时哪个队列大小超过用户定义的阀值，都将会触发节流机制。

只需配置：（i）是否在认证器层或应用器层，或两者做节流；（ii）每个队列的阀值是什么。

流控依赖两个基本机制：

1）对组成员进行监控以便收集所有成员吞吐和队列大小相关的某些统计信息，以便对每个组成员将承受的最大写压力进行有根据的猜测；

2）时刻对试图进行超过其平均可用容量写的成员进行限流。

1）探测和统计信息

该监控机制通过每个成员部署一套探测器收集其工作队列和吞吐相关信息进行工作。接着，其定期将这些信息传播到组以与其他成员进行数据共享。

该探测器分散到插件栈中且允许建立指标，例如：

认证器队列大小；
复制应用层队列大小；
认证事务的总数量；
成员中应用远程事务的总数量；
本地事务的总数据量。

一旦一个成员接收到另一个成员的统计信息，其对最近监控期内另外有关认证、应用和本地执行事务数等指标进行计算。

监控数据周期性与组内其他成员共享。监控周期必须足够高以便允许其他成员决定当前写请求，但足够低以便其对组带宽有最小影响。每秒钟信息会共享，且该期间足以解决上述两个担忧。

2）组复制节流

基于从组内所有服务器收集的指标，节流机制生效并决定是否限制某个成员执行/提交新事务的速率。

因此，从所有成员获取的指标是计算每个成员容量的基础：如果某个成员队列很长（认证或应用线程），那么，执行新事务的容量应该与最近认证或应用之一接近。

组内所有成员的最低容量决定了该组的真实容量，同时，本地事务的数量决定了多少成员正在对其进行写，进而，多少成员参与分享可用容量。

这意味着每个成员有一个基于可用容量的写配额，换句话说，就是其接下来可以安全发布的事务数。如果认证器或二进制日志应用器队列大小超过了用户定义的阀值，节流机制将强制该写配额。

配额按照最近拖延事务数减少，接着，进一步减少10%以允许触发该问题的队列减少其大小。为了避免队列大小降到阀值以下吞吐上的巨大跳跃，之后每个期间仅允许吞吐增加同样的10%。

目前节流机制并不会对配额下的事务进行惩罚，但会拖延完成超过配额的事务，直到监控期间结束。结果，如果对发布写请求来说配额很小，某些事务也许在监控期间附近有延迟。

Mysql组复制（MGR）——技术细节相关推荐

Mysql组复制（MGR）——常问的问题
本文提供常被问到问题的答案. 1.复制组中最多能有多少个mysql服务器? 复制组最多包含9个mysql服务器.尝试向已有9个服务器的组添加另外的服务器将被拒绝. 2.组内服务器间如何连接? 组内服务 ...
Mysql组复制（MGR）——前提及限制
本文将对组复制的前提条件和限制进行列举和解释. 一.组复制前提想用组复制的服务器实例必须满足如下前提条件: 1.基础架构 1)InnoDB存储引擎.数据必须存储于InnoDB事务存储引擎.事务被乐观 ...
mysql组复制（MGR）——部署
mysql组复制作为插件提供给mysql服务器,组内的每个服务器都要求配置和安装该插件.本文提供创建一个至少3个服务器的复制组所需的详细步骤. 一.部署单主模式的组复制组内的每个服务器实例能运行在独 ...
mysql组复制（MGR）——背景
本文提供mysql组复制相关的背景信息. 创建容错系统的最常用方式是采用组件冗余方式,换句话说,就是组件能被移除且系统应该继续如期操作.这产生了一系列将系统复杂度上升到不同等级的挑战.特别是,复制数据 ...
MySQL组复制学习笔记(基于MySQL 8+) -- 使用篇
3.1. 启动/停止可以通过start/stop group_replication来启动停止组复制进程. mysql> start group_replication; /* 启动MySQL ...
MySQL内部开发人员如何看待MySQL组复制？
MySQL因为高性能.可扩展性和可用性被广泛应用于Web应用程序,成为支持高流量社交媒体.电商应用程序以及快速成长企业的IT平台基础.在MySQL 5.7.17版本中,MySQL Group Repl ...
使用MySQL组复制的限制和局限性
本节列出和解释了组复制相关的要求和限制. 1.组复制的要求要使用组复制,每个MySQL节点必须满足以下条件: 1.1 基本要求 InnoDB存储引擎:数据必须存储在事务型的InnoDB存储引擎中.事 ...
Mysql组复制故障恢复测试
在前面的两篇文章中,介绍了mysql组复制的特点及配置过程,本文演示mysql单组复制下的模拟故障测试. 一.组复制所有成员服务器宕机重启后的恢复连接所有的mysql实例查询当前的组复制成员情况,状 ...
mysql 组复制不一致_使用MySQL组复制的限制和局限性
本节列出和解释了组复制相关的要求和限制. 1.组复制的要求要使用组复制,每个MySQL节点必须满足以下条件: 1.1 基本要求 InnoDB存储引擎:数据必须存储在事务型的InnoDB存储引擎中.事 ...

Mysql组复制（MGR）——技术细节

Mysql组复制（MGR）——技术细节相关推荐

最新文章

热门文章