Mysql组复制（MGR）—

该部分描述部署组复制的不同模式，解释管理组的常见操作，并提供关于如何调整组的信息。

一.部署多主或单主模式

组复制按照如下不同模式进行操作：

1）单主模式。

2）多主模式。

默认模式为单主模式。组成员不可能部署在不同的模式，例如：一个配置为多主模式而另一个为单主模式。

为了在两个模式间进行切换，组而非服务器需要以不同操作配置重启。不管部署模式，组复制并不处理客户端失败切换，那必须有应用自己进行处理，类似代理或路由器的连接器或中间件框架。

当以多主模式部署时，语句被检查以确定其余该模式兼容。当组复制以多主模式部署时将进行下列检查：

1）如果事务以串行（SERIALIZABLE）隔离级别执行，那么，当与组同步时，其提交将失败。

2）如果事务对一个有层级约束外键的表执行时，那么，当与组同步时，该事务提交将失败。

这些检查能通过将选项group_replication_enforce_update_everywhere_checks设置为FALSE进行禁用。当以单主模式部署时，该选项必须设置为FALSE。

1.单主模式

该模式下，该组有单主服务器设置为读写模式。组内所有其他成员设置为只读模式（super-read-only=ON）。这些会自动发生。主服务器是启动组的第一个服务器，所有加入的其他服务自动了解主服务器并设置为只读。

图1-1 新主服务器选举

单主模式时，多主模式中的某些检查被禁用，因为系统强制仅组内的单个服务器可以写。例如：对有层级外键的表可改变，而在多主模式这是不允许的。主成员失败时，一个自动主成员选举机制会选出新的主成员。选举过程通过查看新视图和按照group_replication_member_weight值排序潜在新主成员来进行。假设所有成员运行同样 mysql版本的组正进行操作，那么，group_replication_member_weight值最高的成员将被选举为新主成员。 group_replication_member_weight值相同的多服务器场景中，服务器按照server_uuid字典顺序按优先级排序，并挑出第一个。一旦新主成员选出，其自动被设置为读写且其他次服务器仍然为次级，因此，为只读。

如果组成员运行不同版本的mysql，那么，选举过程可能受影响。例如：如果某些成员不支持group_replication_member_weight，那么，主成员基于server_uuid顺序从较低主版本的成员选出。另外，如果所有运行不同mysql版本的成员支持group_replication_member_weight，主成员基于group_replication_member_weight值从较低主版本的成员中选出。

实践中，将客户端应用重新路由到新主成员前，等新主成员应用其复制相关relay-log是比较好的。

2.多主模式

多主模式中，没有单主的概念。由于没有服务器扮演任何特殊角色，因此，没必要进行一个选举过程。

图1-2 客户端失败切换

所有服务器加入组时设置为读写模式。

3.发现主成员

下列例子显示单主模式中如何发现哪个服务器目前为主成员。

mysql> SHOW STATUS LIKE 'group_replication_primary_member'

二．调整恢复

无论何时新成员加入复制组时，其连接到合适的捐赠者并获取其丢失的数据，直到其声明上线的时间点。组复制中这个关键组件是容错和可配置的。下列部分解释恢复如何工作及如何调整该设置。

1.捐赠者选择

一个随机捐赠者从组内现存的在线成员选出。该方式有一个好处，那就是当多个成员进入组时，同样的服务器不会被多次选择。

如果连接选出捐赠者时失败，会自动试图连接一个新的候选捐赠者。一旦达到连接重试限制，恢复过程终止并报错。

--注：

1）捐赠者随机从当前视图的在线成员列表中挑出。

2.增强自动捐赠者切换

整个恢复过程另一个值得关注的点是确信其拷贝失败。然而，组复制提供健壮的错误探测机制。较早版本的组复制中，当连接捐赠者时，恢复仅能探测到因为认证问题或某些其他问题的连接错误。这类问题场景的反应是切换到一个新的捐赠者，这样其会连接到一个不同的成员。

该行为被扩展也包括其他失败场景：

1）清除数据场景：如果选择的捐赠者包含某些需要恢复过程的清除数据，则会发生错误。恢复探测到该错误并新选一个捐赠者。

2）重复数据：如果加入组的服务器恢复期间已包含某些与来自选出捐赠者数据冲突的数据，则会发生错误。这能被加入组的服务器中存在的错误事务引起。

有人可能会争论恢复应该失败而非切换到另一个新的捐赠者，但在异质组中，可能会发生其他成员成员共享冲突事务而其他则不会。因此，针对报错，恢复从组内选择另一个捐赠者。

3）其他报错：如果任何恢复线程失败了（接收或应用线程失败），则发生报错且恢复切换到一个新的捐赠者。

--注：

1）在持续失败甚至短暂失败的场景，恢复自动重试连接到同一捐赠者或新的捐赠者。

3.捐赠者连接重试

恢复数据传输依赖于二进制日志（binary logs）和现存的mysql复制框架，所以，某些短暂报错可能引起接收或应用线程错误。这种场景下，捐赠者切换进程有重试功能，类似于常规复制中发现的类似功能。

4.尝试次数

加入组的服务器连接到捐赠者池中一个捐赠者的尝试次数为10。这通过group_replication_recovery_retry_count插件变量进行配置。下列命令设置连接到捐赠者尝试的最大次数为10。

mysql> SET GLOBAL group_replication_recovery_retry_count= 10;

注意，加入组的服务器连接到每个适当捐赠者的全局尝试次数。

5.睡眠例程

group_replication_recovery_reconnect_interval插件变量定义恢复进程捐赠者连接尝试间睡眠的时间。该变量默认设置为60秒，且能动态修改。下列命令设置恢复捐赠者连接重试间隔为120秒。

mysql> SET GLOBAL group_replication_recovery_reconnect_interval= 120;

但是，注意并非每次捐赠者连接尝试后都会进入睡眠。当加入组的服务器正连接到不同服务器并非反复连接同一捐赠者时，其可能假设影响服务器A的问题并不会影响服务器B。这样，仅当恢复进程连接过所有可能的捐赠者后才会暂停。一旦加入组的服务器尝试连接组内所有合适的捐赠者且都没成功，恢复进程才会睡眠。

三.网络分区

无论何时需要复制的变更发生，组都需要达成共识。这是常规事务的场景，但组成员变更及某些保持组一致的内部信息也需要。共识要求大部分组成员对一个指定决定达成一致。当大部分组成员丢失时，组不能继续工作并阻塞，因为其不能得到大部分成员或法定人数。当多个非自愿失败发生时，也会失去法定人数，从而引起大部分服务器从组内突然移除。例如：一个5个服务器的组内，如果其中3个立刻变得没反应，大部分组成员缺失而不能达到法定人数。事实上，剩余2个组成员无法告诉其他3个服务器是否已崩溃或网络分区是否已将这2个服务器单独隔离，因此，该组不能自动进行重新配置。

另一方面，如果服务器自愿退出组，其指示组应该进行重新配置。实际上，这意味着一个离开的服务器告诉其他成员其将离开。这意味着其他成员能正确重新配置该组，成员的一致性得以维护且大部分成员被重新计算。例如：上述5个服务器中3个立刻离开的场景，如果3个离开的服务器警告该组起将离开，逐个的，那么，成员能够调整其自己从5个到2个，同时，期间得到了法定人数。

--注：

1）失去法定人数本身是不良计划的副作用。为预期失败数计划组规模（无论其是否连续，立刻发生或是零星发生。）

下属场景解释如果系统分区导致组内服务器不能自动获取法定人数时如何进行处理。

--注：

1）大部分成员丢失接着重配置后从组内排除的主成员可能包含不被新组包含的额外事务。如果这种场景发生，试图将从组内排除的成员添加回来导致一个错误，并报出如下信息：

This member has more executed transactions than those present in the group。

1.探测分区

replication_group_members性能模式表从该服务器角度提供当前视图中每个服务器的状态。大部分时间系统并不会发生分区，所以，表显示组内所有服务器一致的信息。换句话说，当前视图中所有服务器都就该表中每个服务器的状态达成一致。但是，如果发生网络分区，失去法定人数，那么，对于那些失去联系的服务器，该表将显示其UNREACHABLE。该信息由组复制内建的本地失败探测器输出。

图2-1 法定人数丢失

为了理解这种类型的网络分区，下述部分描述一个最初有5个服务器一起正常工作，接着，组发生了仅剩2个服务器在线的变更。该场景图中做了描述。

这样，我们假设一个组有如下5个服务器：

1）服务器s1成员鉴定符为199b2df7-4aaf-11e6-bb16-28b2bd168d07。

2）服务器s2成员鉴定符为199bb88e-4aaf-11e6-babe-28b2bd168d07。

3）服务器s3 成员鉴定符为1999b9fb-4aaf-11e6-bb54-28b2bd168d07。

4）服务器s4成员鉴定符为19ab72fc-4aaf-11e6-bb51-28b2bd168d07。

5）服务器s5成员鉴定符为19b33846-4aaf-11e6-ba81-28b2bd168d07。

最初该组运行正常且服务器间通信正常。您能通过登录到s1并查看其replication_group_members性能模式表进行核实。例如：

此外，系统不能自己重新配置来变更成员，因此，大部分成员已经丢失。

2.解除分区阻止

组复制使您能通过强制制定配置来重置组成员。正如上述场景，其中，s1和s2是唯一在线的服务器，您能选择强制一个只包含s1和s2的成员配置。这要求检查s1和s2的某些信息，并接着使用group_replication_force_member变量。

图2-2 强制新成员配置

假设您回到组内仅剩s1和s2服务器的场景。服务器s3、s4和s5已经意外离开了组。为了使服务器s1和s2继续，您想强制一个仅包含s1和s2的成员配置。

--注：

1）该过程使用group_replication_force_members并将作为最后的补救措施。必须非常小心的使用且仅为了覆盖法定人数的丢失。如果被误用，其可能会创建一个人工脑裂场景或阻塞整个系统。

回想系统被阻塞且目前配置如下所示（正如s1上的本地失败探测器所示）：

mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| 127.0.0.1:10000 |
+-----------------------------------+
Then log in to s2 and do the same thing:
mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| 127.0.0.1:10001 |
+-----------------------------------+
一旦知道s1（127.0.0.1:10000）和s2（127.0.0.1:10001）的组通信地址，您能在两个服务器中的任意一个上用其注入一个新的成员配置，这样，覆盖已经丢失法定人数的现存配置。为了在s1上前述配置：

mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";
这通过强制一个不同配置解除了组阻塞。检查s1和s2上的replication_group_members来核实变更后的组成员。首先在s1上：

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+-----------
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STA
+---------------------------+--------------------------------------+-------------+-------------+-----------
| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | 127.0.0.1 | 13000 | ONLINE
| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1 | 13001 | ONLINE
+---------------------------+--------------------------------------+-------------+-------------+-----------
当强制一个新成员配置时，确信任何将被强制移出该组的服务器确实已被停止。在上述场景中，如果s3、s4和s5并非真正unreachable，而是都在线，它们也许已经形成了自己的功能分区（它们是5个中的3个，但它们谁大部分。）。这种场景下，强制包含s1和s2的组成员能创建一个人工脑裂场景。所以，强制新的组成员配置前，确信被排除的服务器确实关闭，否则，继续前先将其关闭。

四.组复制使用mysql enterprise backup

该部分讲解如何使用mysql enterprise backup备份及之后恢复组复制成员；可以使用同样技术快速为组添加一个新成员。一般来说，备份组复制成员与备份单个mysql实例没什么不同。推荐的过程是用mysql enterprise backup影像备份并随后进行恢复。

需要步骤总结如下：

1）使用mysql enterprise backup通过简单时间戳创建源服务器实例的备份。

2）将备份拷贝到目标服务器实例。

3）用mysql enterprise backup将备份恢复到目标服务器实例。

下述内容说明该过程。考虑下述组：

mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/backups/my.mbi_`date +%d%m_%H%M` \

--backup-dir=/backups/backup_`date +%d%m_%H%M` --user=root -pmYsecr3t \

--host=127.0.0.1 --no-history-logging backup-to-image
因为node2为次级成员，所以，使用—no-history-logging选项，并且，因为其为只读，所以，mysql enterprise backup不能向该实例写状态和元数据表。

假设主成员，node1，遇到无法化解的崩溃。一段时间后，该服务器实例被重建但该成员上的所有数据都将丢失。成员node2最近的备份能用于重建node1。这要求把备份文件从node2拷贝到node1，接着，用mysql enterprise backup将该备份恢复到node1。拷贝备份文件的具体方法与操作系统和您可用的工具相关。该例子中，我们假设linux服务器并用scp在服务器间拷贝文件：

node2/backups # scp my.mbi_2206_1429 node1:/backups
连接到目标服务器，这里为node1，通过mysql enterprise backup恢复备份是用如下命令：

mysqlbackup --defaults-file=/etc/my.cnf \

--backup-image=/backups/my.mbi_2206_1429 \

--backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log

备份恢复到目标服务器。

如果您的组使用多主模式，必须额外注意的是在mysql enterprise backup恢复阶段及组复制恢复期间避免对数据库进行写操作。

根据客户端访问组的方式，有可能在新加入的实例网络可访问的瞬间有DML在其上执行，这甚至在重新加入组前应用二进制日志之前。为了避免该情况发生，配置成员选项文件如下：

group_replication_start_on_boot=OFF
super_read_only=ON
event_scheduler=OFF
这确保组复制启动时并不开始启动，成员默认只读，且恢复期间成员追上组时关闭事件调度器。客户端必须配置足够的错误处理以识别临时避免该期间执行DML。启动服务器实例并连接一个SQL 客户端。恢复的备份有旧的二进制文件及备份实例相关的特定元数据。通过如下命令重置所有这些问题：

mysql> RESET MASTER;
恢复的备份有与源实例相关的中继日志文件（relay log files），这里是node2。所以，通过如下命令重置日志文件，元数据和所有复制通道相关的配置：

mysql> RESET SLAVE ALL;
为了恢复实例能用组复制内建的分布式恢复进行自动恢复，配置gtid_executed变量。

通过Mysql enterprise backup来自node2的备份包括backup_gtid_executed.sql文件，通常在datadir/meta/，其包含配置node1所需的信息。通过如下命令禁用二进制日志并用该文件配置gtid_executed变量：

mysql> SET SQL_LOG_BIN=OFF;
mysql> SOURCE datadir/meta/backup_gtid_executed.sql
mysql> SET SQL_LOG_BIN=ON;
配置和启动组复制，例如：

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' /
FOR CHANNEL 'group_replication_recovery';
mysql> START GROUP_REPLICATION;
该实例试图加入该组，从正确位置执行恢复的二进制日志。一旦实例完成与组的同步，其将作为次级成员加入组，且super_read_only=ON。

重置恢复期间发生的临时配置变更。运行过程中再次打开时间调度器：

mysql> SET global event_scheduler=ON;
编辑实例选项文件中的下述系统变量：

group_replication_start_on_boot=ON
super_read_only=ON
event_scheduler=ON

Mysql组复制（MGR）——操作相关推荐

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

Mysql组复制（MGR）——操作

Mysql组复制（MGR）——操作相关推荐

最新文章

热门文章