从零开始的云计算生活——番外2，MySQL组复制

目录

[一·组复制 (MGR) 介绍](#一·组复制 (MGR) 介绍)

[1. 组复制原理](#1. 组复制原理)

[2. 组复制特点](#2. 组复制特点)

[3. 组复制的要求与限制](#3. 组复制的要求与限制)

[4. 组复制相关服务](#4. 组复制相关服务)

二·基于GTID的组复制分布式集群的环境部署

[1. 服务器环境部署](#1. 服务器环境部署)

[2. MGR组复制单主模式配置](#2. MGR组复制单主模式配置)

[2.1 组复制第一个实例配置](#2.1 组复制第一个实例配置)

[2.2 重启服务](#2.2 重启服务)

[2.3 环境准备](#2.3 环境准备)

[2.4 组复制插件](#2.4 组复制插件)

[2.5 加入组复制](#2.5 加入组复制)

[2.6 数据测试](#2.6 数据测试)

[3. 组复制添加其他实例成员](#3. 组复制添加其他实例成员)

[3.1 参数配置](#3.1 参数配置)

[3.2 重启服务](#3.2 重启服务)

[3.3 用户凭据](#3.3 用户凭据)

[3.4 组复制插件](#3.4 组复制插件)

[3.5 加入组复制](#3.5 加入组复制)

[3.6 数据测试](#3.6 数据测试)

---

一·组复制 (MGR) 介绍

MySQL Group Replication(简称 MGR )是 MySQL 官方于 2016 年 12 月推出的一个全新的高可用与高扩展的解决方案。组复制是 MySQL 5.7.17 版本出现的新特性，它提供了高可用、高扩展、高可靠的 MySQL 集群服务。MySQL 组复制分单主模式和多主模式，传统的mysql复制技术仅解决了数据同步的问题，如果主机宕机，意味着数据库管理员需要介入，应用系统可能需要修改数据库连接地址或者重启才能实现。(这里也可以使用数据库中间件产品来避免应用系统数据库连接的问题，例如 Mycat 和 atlas 等产品)。

创建容错系统最常见的方法是组件冗余。换句话说，一个组件被移除时，系统应该继续按预期运行。这产生了一系列挑战，将这种系统的复杂性提高到了一个完全不同的水平。数据复制必须维护和管理多个服务器，还必须处理若干其它经典的分布式系统问题，如网络分区或脑裂。对 MySQL 而言，最终的挑战是将数据复制逻辑与协调多个服务器的逻辑相融合。这可以概括为让每个服务器的状态在数据变化时达成一致，即便它们都作为单个数据库系统运行，但最终都收敛到相同的状态。

MGR 对属于同一组的服务器自动进行协调。对于要提交的事务，组成员必须就全局事务序列中给定事务的顺序达成一致。提交或回滚事务由每个服务器单独完成，但所有服务器都必须做出相同的决定。如果存在网络分区，导致成员无法达成事先定义的分割策略，则在解决此问题之前系统不会继续进行，这是一种内置的自动裂脑保护机制。MGR由组通信系统(Group Communication System，GCS ) 协议支持。该系统提供故障检测机制、组成员服务以及安全且有序的消息传递。所有这些属性都是创建系统的关键，可确保在服务器组中一致地复制数据。该技术的核心是 Paxos 算法的实现，它充当组通信引擎。

1. 组复制原理

组复制是一种可用于实现容错系统的技术。 复制组是一个通过消息传递相互交互的server集群。通信层提供了原子消息 (atomic message) 和完全有序信息交互等保障机制，实现了基于复制协议的多主更新。复制组由多个 server成员构成，并且组中的每个 server 成员可以独立地执行事务。但所有读写 (RW) 事务只有在冲突检测成功后才会提交。只读 (RO) 事务不需要在冲突检测,可以立即提交。句话说, 对于任何 RW 事务,提交操作并不是由始发server单向决定的,而是由组来决定是否提交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值 (已改变的行) 和对应的写入集 (已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此, 所有server成员以相同的顺序应用相同的更改,以确保组内一致。

基于组的复制(Group-based Replication)是一种被使用在容错系统中的技术。Replication-group (复制组) 是由能够相互通信的多个服务器(节点)组成的。在通信层，Group replication 实现了一系列的机制：比如原子消息 (atomic message delivery) 和全序化消息 (total ordering of messages)。这些原子化，抽象化的机制，为实现更先进的数据库复制方案提供了强有力的支持。MySQL Group Replication 正是基于这些技术和概念，实现了一种多主全更新的复制协议。

简而言之，一个 Replication-group 就是一组节点，每个节点都可以独立执行事务，而读写事务则会在于 group 内的其他节点进行协调之后再 commit。因此，当一个事务准备提交时，会自动在 group 内进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务。这种原子广播的方式，使得这个事务在每一个节点上都保持着同样顺序。这意味着每一个节点都以同样的顺序，接收到了同样的事务日志，所以每一个节点以同样的顺序重演了这些事务日志，最终整个 group 保持了完全一致的状态。然而，不同的节点上执行的事务之间有可能存在资源争用。这种现象容易出现在两个不同的并发事务上。

假设在不同的节点上有两个并发事务，更新了同一行数据，那么就会发生资源争用。面对这种情况，Group Replication 判定先提交的事务为有效事务，会在整个 group 里面重演，后提交的事务会直接中断，或者回滚，最后丢弃掉。因此，这也是一个无共享的复制方案，每一个节点都保存了完整的数据副本。看下图描述了具体的工作流程，能够简洁的和其他方案进行对比。这个复制方案，在某种程度上，和数据库状态机 (DBSM) 的 Replication 方法比较类似。

2. 组复制特点

• 高一致性

  • 基于原生复制及 Paxos 协议的组复制技术，并以插件的方式提供，提供一致数据安全保证。确保组内数据最终一致性【重要】(通过分布式协议和分布式 recovery 机制保证);

• 高容错性

  • 确保组内高可用。只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；

• 高扩展性

  • 良好的扩展能力，可动态增删节点，组成员自动管理。节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；

• 高灵活性

  • 有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；

  • 多主模式下，所有 Server 都可以同时处理更新操作。

• 多写，写冲突检测。

3. 组复制的要求与限制

• 存储引擎必须为Innodb，即仅支持 InnoDB 表，并且每张表一定要有一个主键，用于做write set的冲突检测；

• 每个表必须提供主键；

• 只支持 ipv4，网络需求较高；

• 必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set；

• COMMIT 可能会导致失败，类似于快照事务隔离级别的失败场景；

• 目前一个 MGR 集群组最多支持 9 个节点；

• 不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚；

• 二进制日志 binlog 不支持Replication event checksums；

• 多主模式(多写模式) 不支持SERIALIZABLE事务隔离级别；

• 多主模式不能完全支持级联外键约束；

• 多主模式不支持在不同节点上对同一个数据库对象并发执行 DDL (在不同节点上对同一行并发进行 RW 事务，后发起的事务会失败)。

4. 组复制相关服务

• 故障检测

  • 组复制包括一种故障检测机制，该机制能够查找并报告哪些服务器已经宕机。故障检测是提供关于哪些 server 可能已死的信息(猜测)的分布式服务。 某个 server 无响应时触发猜测，组中其余成员进行协调决定以排除给定成员。如果某个 server 与组的其余成员隔离，则它会怀疑所有其他 server 都失败了。由于无法与组达成协议 (因为它无法确保仲裁成员数)，其怀疑不会产生后果。当服务器以此方式与组隔离时,它无法执行任何本地事务。 在线 server 列表通常称为视图，新成员 server 的加入离开，无论是自愿还是被迫的离开，该组都会动态地重新规划其配置,并触发视图更新。

  • 如果一个服务器与组的其余部分隔离，它会怀疑所有其它服务器都已失败，但由于无法与该组达成协议(因为无法确保法定票数)，其怀疑并没有结果。当服务器以这种方式与组隔离时，它无法执行任何本地事务。

• 组成员服务

  • MGR 依赖于组成员服务，该服务内置于插件中。它定义了哪些服务器在线并参与该组。在线服务器列表通常称为视图。因此，组中的每个服务器都具有一致的视图，其中是在给定时刻主动参与该组的成员。

  • 服务器不仅必须同意事务提交，还要同意当前视图。因此，如果服务器同意新服务器成为组的一部分，则组本身将重新配置为将该服务器集成在其中，从而触发视图更改。相反的情况也会发生，如果服务器离开组，则组会动态更新配置并触发视图更改。

  • 组成员离开组分主动与被动。主动离开会启动组的动态重新配置，这会触发所有其它成员必须在没有该服务器的情况下就新视图达成一致。被动离开 (如已意外停止或断网) 时，故障检测机制会建议重新配置组，这需要组中大多数服务器的同意。如果该组无法达成协议，为阻止脑裂，系统无法动态更改配置，这意味着管理员需要介入解决此问题。

• 容错

  • MGR 构建于Paxos分布式算法的实现之上，需要多数服务器处于活动状态才能达到法定票数，从而做出决定。这直接影响系统可以容忍的故障机数量，但不会影响组复制自身及其整体功能。容忍 f 个故障机所需的服务器数量 n 为：n = 2*f + 1。

  • 实践中为了容忍一个故障机，该组必须具有三个服务器，因为此时如果一个服务器发生故障，仍然有两个服务器构成多数，并允许系统继续自动做出决策并继续提供服务。但如果第二个服务器继续失败，那么该组 (剩下一个服务器) 会阻塞，因为没有多数票可以做出决定。

二·基于GTID的组复制分布式集群的环境部署

需要清楚知道：MySQL 复制组能够以一种自动优先选择的单主模式运行，在某个时间只有一个服务器接受更新 。但是对于更高优先级的用户，组能够以多主模式部署，所有的服务器都能够接受更新，即使它们是同时发生的。组复制中存在着一种内建的组成员关系服务用来保持组的视图一致，并且在任意时间对于组中的所有的服务器都可用。MySQL 服务器能够退出或者加入组中，而且视图也会相应的更新。有时服务器可能会意外的退出组 (故障)，在这种情况下失败检测机制检测这种情况并且告知复制组视图发生了变化，这所有的一切都是自动实现的。

1. 服务器环境部署

主机名	IP	Server ID	OS	MySQL version
node1	192.168.71.162	81	Rock8	Mysql 5.7
node2	192.168.71.163	82	Centos 7.8	Mysql 8.0.31
node3	192.168.71.164	83	Centos 7.8	Mysql 8.0.31

所有主机添加hosts解析

192.168.71.162	node1
192.168.71.163	node2
192.168.71.164	node3

2. MGR组复制单主模式配置

2.1 组复制第一个实例配置

如果要通过节点的UUID设置组名，查看节点node1的uid

配置参数文件

[mysqld]
# 原有默认配置
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# 密码验证方式
default_authentication_plugin=mysql_native_password
#Storage Engines
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
#Replication Framework
server_id=81
gtid_mode=ON
enforce_gtid_consistency=ON

binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction_write_set_extraction=XXHASH64

sync-master-info =1
sync_binlog =1
#Group Replication Settings
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "node1:33061"
group_replication_group_seeds= "node1:33061,node2:33061,node3:33061"
group_replication_bootstrap_group=off
# 双主模式，如果是单主模式无需配置，默认单主模式
# 当前不配置，后续切换多主模式后再持久化该参数
# group_replication_single_primary_mode=off
# group_replication_enforce_update_everywhere_checks=on

参数说明：

#以便在server收集写集合的同时将其记录到二进制日志。写集合基于每行的主键，并且是行更改后的唯一标识此标识将用于检测冲突。

transaction_write_set_extraction=XXHASH64

plugin_load_add='group_replication.so'

#组的名字可以随便起,但不能用主机的GTID! 所有节点的这个组名必须保持一致！

group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"

#为了避免每次启动自动引导具有相同名称的第二个组,所以设置为OFF。

group_replication_start_on_boot=off

group_replication_local_address= "node1:33061"

group_replication_group_seeds= "node1:33061,node2:33061,node3:33061"

group_replication_bootstrap_group=off

#关闭单主模式的参数

#group_replication_single_primary_mode=off

#开启多主模式的参数

#group_replication_enforce_update_everywhere_checks=on

2.2 重启服务

2.3 环境准备

2.4 组复制插件

2.5 加入组复制

引导只能由单个服务器完成，即启动组的服务器并且只执行一次。

这就是为什么group_replication_bootstrap_group选项的值没有存储在实例的选项文件中的原因。

如果它保存在选项文件中，则在重新启动服务器时会自动引导第二个具有相同名称的组。这将导致两个不同的组具有相同的名称

2.6 数据测试

3. 组复制添加其他实例成员

3.1 参数配置

配置参数文件,其他参数相同，修改如下两个参数server_id，group_replication_local_address

3.2 重启服务

3.3 用户凭据

node2

node3

3.4 组复制插件

本次已经在配置文件添加引导，无需再次安装

3.5 加入组复制

这里只需要执行这一步即可,因为组已经创建

START GROUP_REPLICATION;

查看组内情况，发现node2，node3已经成功加入这个组了

3.6 数据测试

主库添加数据

从库查询

至此，组复制配置结束.