MYSQL--架构--MGR--理论--07--新节点如何加入组

MYSQL–架构–MGR–理论–07–新节点如何加入组

---

1、架构图

2、加入组

如果一个新的节点要加入组，它首先要将自己的数据和组内的数据保持同步

2.1、加入组的 指令

新节点要加组，在配置好配置文件后，只需执行以下3个过程等待成功返回就可以了。

# 设置通信管道
change master to 
        master_user='XXXX',
        master_password='YYYY'
        for channle 'group_replication_recovery';

# 安装插件
install plugin group_replication soname 'group_replication.so';
# 启动复制
start group_replication;

虽然操作很少，但这里涉及到一个很重要的过程：恢复过程。

3、恢复过程

1. 新节点和组中数据保持同步的过程称为恢复过程，也称为分布式恢复过程。
2. 它由架构图中的"Recovery"组件来完成。

4、数据同步

1. 新节点获取组中某个节点的Binlog，然后应用到自己身上，填补自己缺失的那部分数据
2. 通过异步复制完成的。

4.1、获取组中某个节点

1. 当新节点启动了它自己的组复制功能时，新节点会从组中选一个节点A来作为同步数据的供应节点，这个节点称为"donor"(供应者)
2. 新节点通过group_replication_group_seeds 选项的值来选择donor节点

4.1.1、group_replication_group_seeds 配置

loose-group_replication_group_seeds="192.168.100.21:20001,192.168.100.22:20002"

4.1.2、说明

1. 上面的配置中，两个节点都可以成为donor，它们称为"种子节点(seed)"。
2. 新节点从前向后逐一选择，当和第一个donor交互失败，就会选择第二个donor，直到选完最后一个donor，如果还失败，将超时等待一段时间后再从头开始选择。
3. 建议每个节点的配置文件中，都将组中所有节点写入种子节点列表中。

4.2、建立数据恢复的通道

1. 当选择好一个donor后，新节点会和这个donor建立一个数据恢复的通道group_replication_recovery。
2. Recovery组件会从donor上复制所有新节点缺失的数据对应的binlog，然后应用在新节点上。
3. 当新节点数据和组中已经保持一致，则新节点成功加入到组，它将标记为ONLINE。

实际上，这只是恢复的一个阶段，还有第二阶段

4.3、记录Binlog同步过程中新产生的事务

1. 记录新节点Binlog同步过程中，新产生的事务,该数据放到事务缓存队列中
2. 当新节点将Binlog数据恢复完成后，将执行事务缓存队列的事务，直到缓存中的事务数量减为0后，才表示新节点已经完全赶上了组中的数据，这是它才可以标识为ONLINE，并真正成为组中的一员。

4.3.1、在新节点准备开始加入组的时候，Recovery组件有两个功能：

1. 选择donor，并从donor处复制缺失的数据
2. 监控组中新产生的事务并放进自己的事务缓存队列中。

4.3.2、举例

在填补缺失的数据时，客户端向组中的可写节点插入了一条数据，这个数据不会被新节点的异步复制抓走，新节点会监控到这个事务。如下图：

4.3.3、说明

1. 新节点的recovery组件通过异步复制通道从donor处获取p1之前的所有数据，并监控组中新生成的事务放入自己的事务缓存队列中。
2. 当新节点将p1之前的数据恢复完成后，将执行缓存队列中的事务，直到缓存中的事务数量减为0后，才表示新节点已经完全赶上了组中的数据，这是它才可以标识为ONLINE，并真正成为组中的一员。

5、事务数量相同，为什么新节点能赶上组？

1. 第1个原因是事务不会源源不断地生成，它总有停顿的时候
2. 第2个原因归功于基于行格式的binlog(row-based binlog)，除了发起事务的那个节点，只要事务被大多数节点同意了，所有节点都根据binlog行中设置的值直接修改数据，而不会完整地执行事务逻辑。换句话说，事务发起节点修改数据的速度没有其他节点快，尽管它们是同时提交的。

6、donor(供体)机制

6.1、供体选择

1. 供体从当前视图中的在线成员列表中随机选择。 这样，当多个成员进入组时，很可能不会选择同一服务器多次。
2. 如果与所选供体的连接失败，则自动尝试向新的候选供体进行新连接,达到连接重试限制后，恢复过程将终止并显示错误。

6.2、增强的自动供体切换

整个恢复的另一个主要关注点是确保它能够应对失败。 因此，Group Replication提供了强大的错误检测机制。 对有问题的供体是切换到新的供体。

6.2.1、清除数据方案

如果所选供体包含恢复过程所需的一些被清除数据，则会发生错误。恢复检测到此错误，并选择新的供体。

6.2.2、被复制的数据

1. 如果 新节点 已经包含一些与恢复期间来自所选供体冲突的数据，则会发生错误。恢复检测到此错误，并选择新的供体。
2. 有人可能会说，恢复应该失败而不是转移到另一个供体，但在群体中，一些成员有可能分享冲突的事务，而其他成员则没有。 出于这个原因，一旦出错，恢复将从该组中选择另一个供体

6.2.3、其他错误

如果任何恢复线程失败(接收器或应用程序线程失败)，则发生错误并且恢复切换到新的供体。

注意：

如果出现一些持续性故障甚至是瞬态故障，恢复将自动重试连接到相同或新的供体。

6.3、供体重新连接

恢复数据传输依赖于二进制日志和现有的MySQL复制框架，因此一些瞬态错误可能会导致接收器或应用程序线程中出现错误。 在这种情况下，供体切换进程具有重试功能，类似于常规复制中的功能。

6.4、允许的次数

1. 当尝试从供体池连接到供体时，加入该组的节点尝试的次数默认是10

6.4.1、设置允许的次数

以下命令将设置连接到供体的最大尝试次数设置为10。

mysql> SET GLOBAL group_replication_recovery_retry_count= 10;

6.5、sleep 常规

1. 定义 新节点 尝试所有可能的供体服务器后，应该休眠的时间。
2. 此变量的默认设置为60秒，您可以动态更改此值。

6.5.1、设置sleep

定义 新节点 尝试所有可能的供体服务器后。休眠120秒

mysql> SET GLOBAL group_replication_recovery_reconnect_interval= 120;