admin 管理员组文章数量: 887021
2023年12月19日发(作者：property boom)
京东商城基础平台-数据库技术部
Mysql Group Replication官方文档译文
京东商城基础平台-数据库技术部
译文指导： 京东老樊
校 对： 王伟 刘风才 刘岩
商东京
据数
-
城翻 译： 张璐 王思佳 张树臣 翟敏 赵晨
部术技库
版权声明和保密须知
本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属北京京东尚科信息技术有限公司所有，受到有关产权及版权法保护。任何单位和个人未经北京京东尚科信息技术有限公司的书面授权许可，不得复制或引用本文件的任何片断，无论通过电子形式或非电子形式。
Copyright © 2017北京京东尚科信息技术有限公司版权所有
京东商城基础平台-数据库技术部
前言
MySQL Group Replication（简称MGR）是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。MySQL组复制提供了高可用、高扩展、高可靠的MySQL集群服务。高一致性，基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。
MGR是MySQL数据库未来发展的一个重要方向。京东商城数据库技术部对此作出积极响应，在最短的时间内立项，对MGR进行研究测试。为了使研究以及后续的运维推广工作更加简便，特此将MGR官方文档译为中文，谨供业内人士参考。由于本章内容较多，翻译时间紧迫，尽管我们尽量做到认真仔细，但还是难以避商东京
免出现错误和不尽如人意的地方，在此欢迎广大读者批评指正。
据数
-
城部术技库
京东商城基础平台-数据库技术部
目录
19.1 组复制背景 ............................................................................................................................. 1
19.1.1 复制技术...................................................................................................................... 2
19.1.1.1 主–从复制 ........................................................................................................ 2
19.1.1.2 组复制 .............................................................................................................. 3
19.1.2 组复制用例.................................................................................................................. 3
19.1.2.1 用例场景示例 .................................................................................................. 4
19.1.3 组复制详细信息 .......................................................................................................... 4
19.1.3.1 故障检测 .......................................................................................................... 4
19.1.3.2 组成员关系 ...................................................................................................... 5
19.1.3.3 容错 .................................................................................................................. 5
19.2 入门指南 ................................................................................................................................. 6
19.2.1 在单主模式下部署组复制 .......................................................................................... 6
19.2.1.1部署组复制的实例 ........................................................................................... 6
19.2.1.2配置组复制实例 ............................................................................................... 7
19.2.1.3用户凭据 ......................................................................................................... 10
19.2.1.4启动组复制 ..................................................................................................... 11
19.2.1.5向组中添加实例 ............................................................................................. 15
19.3监控组复制 ............................................................................................................................ 26
19.3.1 Replication_group_member_stats ......................................................................... 26
19.3.2 Replication_group_members ................................................................................. 27
19.3.3 Replication_connection_status .............................................................................. 27
19.3.4 Replication_applier_status ...................................................................................... 28
商东京19.3.5组复制中的server状态............................................................................................ 28
19.4 组复制操作 ........................................................................................................................... 29
19.4.1 以多主模式或单主模式部署 .................................................................................... 29
19.4.1.1 单主模式 ........................................................................................................ 30
19.4.1.2 多主模式 ........................................................................................................ 30
19.4.1.3 查找主节点 .................................................................................................... 31
19.4.2 调整恢复.................................................................................................................... 31
19.4.3 网络分隔.................................................................................................................... 33
19.4.3.1
检测分区 ........................................................................................................ 33
19.4.3.2 解除分隔 ........................................................................................................ 36
19.5 组复制安全 ........................................................................................................................... 39
19.5.1 IP地址白名单 ............................................................................................................ 40
19.5.2 安全套接字层的支持（SSL） ................................................................................ 40
19.5.3 虚拟专用网（VPN） ............................................................................................... 43
19.6 组复制系统变量 ................................................................................................................... 43
19.7 要求和限制 ........................................................................................................................... 52
19.7.1 组复制要求................................................................................................................ 52
19.7.2 使用限制.................................................................................................................... 53
19.8 常见问题 ............................................................................................................................... 54
组中MySQL server的最大数量是多少？ ................................................................. 54
据数
-
城部术技库
京东商城基础平台-数据库技术部
商东京
组中的server之间如何连接？ .................................................................................... 54
选项group_replication_bootstrap_group有什么用途？ ......................................... 54
如何设置恢复过程的凭据？ ......................................................................................... 54
我可以使用组复制横向扩展我的写入负载吗？ ......................................................... 54
在相同工作负载下，对比单纯的复制，组复制是否需要更多的网络带宽和CPU？......................................................................................................................................... 55
我可以跨广域网部署组复制吗？ ................................................................................. 55
在遇到临时的连接问题时，节点是否自动重新加入组？ ......................................... 55
什么时候从组中移除成员？ ......................................................................................... 55
当一个节点非常明显地延迟时会怎么处理？ ............................................................. 56
在怀疑组中存在问题时，组中是否有某个特定成员负责触发重新配置组？ ......... 56
19.9 组复制技术详细信息 ........................................................................................................... 56
19.9.1 组复制插件架构 ........................................................................................................ 56
19.9.2 组 ............................................................................................................................... 57
19.9.3 数据操作语句 ............................................................................................................ 58
19.9.4 数据定义语句 ............................................................................................................ 58
19.9.5 分布式恢复................................................................................................................ 59
19.9.5.1 组复制基础 .................................................................................................... 59
19.9.5.2 从时间点恢复 ................................................................................................ 59
19.9.5.3 视图更改 ........................................................................................................ 60
19.9.5.4 分布式恢复的使用建议和限制 .................................................................... 64
19.9.6 可观察性.................................................................................................................... 64
19.9.7 组复制性能................................................................................................................ 64
19.9.7.1 微调组通讯线程 ............................................................................................ 65
19.9.7.2 消息压缩 ........................................................................................................ 65
19.9.7.3 流量控制 ........................................................................................................ 66
据数
-
城部术技库
京东商城基础平台-数据库技术部
本章介绍MySQL组复制以及如何安装，配置和监控。 MySQL组复制是一个能够让您创建弹性化、高可用、容错复制结构的MySQL插件。
组复制可以在两种模式下运行。 在单主模式下，组复制具有自动选主功能，每次只有一个server成员接受更新。在多主模式下运行时，所有的server成员都可以同时接受更新。
组复制中内置的组成员服务，用于保持组信息的视图一致，并在任何给定的时间点对于所有server成员可用。 当Server成员离开或加入组时，视图会相应地进行更新。 当有server成员意外离开组时，故障检测机制会检测到此情况，并自动通知组当前视图已更改。
本章的结构如下：
•第19.1节“组复制背景”介绍组以及组复制的工作原理。
•第19.2节“入门指南”介绍如何通过配置多个MySQL Server实例来创建组。
•第19.3节“监控组复制”介绍如何监控组。
•第19.5节“组复制安全性”介绍如何保护组。
•第19.9节“组复制技术详细信息”详细介绍组复制是如何工作的。
19.1 组复制背景
本节介绍有关MySQL组复制的背景信息。
创建容错系统的最常见方法是创建组件冗余，换句话说，组件可以删除，而系统应该继续按预期运行。 这就造成了一系列的挑战，将这种系统的复杂性提高到一个完全不同的水平。 具体来说，商东京machine运行。
复制的数据库需要同时维护和管理若干个server成员，而不只是一个。 此外，当多个server协同工作时，系统必须处理其他一些常见的分布式系统问题，诸如断网或脑裂等情况。
因此，最大的挑战是将数据库和数据复制的逻辑与若干个server以简单一致的方式协调运行的逻辑相融合。 换句话说，也就是使多个server成员关于系统的状态和系统每次变更的数据保持一致。 这可以被概括为使多个server对于每个数据库状态转换达成共识，从而使它们都作为一个独立的数据库运行，或者说它们最终达到相同状态。 这就意味着它们需要作为（分布式）state
据数
-
城部术技库MySQL组复制提供了一种强大的server间协调机制的分布式state machine复制。 组中的server成员会自动地进行协调。
组复制可以在两种模式下运行。 在单主模式下，组复制具有自动选主功能，每次只有一个server成员接受更新。在多主模式下运行时，所有的server成员都可以同时接受更新。
这种功能就要求应用程序不得不解决部署所带来的限制。内置的组成员服务，用于保持组视图的一致性，并在任何给定的时间点对于所有server可用。当 Server离开或加入组时，视图会相应地进行更新。 server也可能会意外离开组，故障检测机制会自动检测到此情况，并通知组该视图已更改。
1
京东商城基础平台-数据库技术部
对于要提交的事务，决定提交或中止事务是由每个server单独完成的，但所有组成员必须就该事务在全局事务序列中的顺序达成一致意见。如果存在网络分隔，造成组成员间无法达成协议，则系统在此问题解决前将不会继续运行。 因此，组复制还内置了一个自动的脑裂保护机制。
这种机制都是由系统提供的组通信协议提供支持的。 该协议保障了故障检测机制，组成员服务的安全和消息的完全有序传递。该技术的核心是Paxos算法实现的，是组复制中保证数据一致性复制的关键， 它充当了组通信系统的引擎。
19.1.1 复制技术
在介绍MySQL组复制的详细信息之前，本节将简要介绍一些背景概念以及组复制是如何运行的。
通过本节我们可以了解组复制中需要什么，以及传统异步MySQL复制和组复制之间的区别。
19.1.1.1 主–从复制
传统的MySQL复制提供了一种简单的主–从复制方法。 有一个主，以及一个或多个从。 主节点执行和提交事务，然后将它们（异步地）发送到从节点，以重新执行（在基于语句的复制中）或应用（在基于行的复制中）。 这是一个shared-nothing的系统，默认情况下所有server成员都有一个完整的数据副本。
图19.1 MySQL异步复制
商东京
据数
-
城部术技库
还有一个半同步复制，它在协议中添加了一个同步步骤。 这意味着主节点在提交时需要等待从节点确认它已经接收到事务。只有这样，主节点才能继续提交操作。
图19.2 MySQL异步复制
在上面的两个图片中，可以看到传统异步MySQL复制协议（以及半同步）的图形展示。 蓝色箭头表示在不同server之间或者server与 client应用之间的信息交互。
2
京东商城基础平台-数据库技术部
19.1.1.2 组复制
组复制是一种可用于实现容错系统的技术。 复制组是一个通过消息传递相互交互的server集群。
通信层提供了原子消息（atomic message）和完全有序信息交互等保障机制。 这些是非常强大的功能，我们可以据此架构设计更高级的数据库复制解决方案。
MySQL组复制以这些功能和架构为基础，实现了基于复制协议的多主更新。复制组由多个server成员构成，并且组中的每个server成员可以独立地执行事务。但所有读写（RW）事务只有在冲突检测成功后才会提交。只读（RO）事务不需要在冲突检测，可以立即提交。换句话说，对于任何RW事务，提交操作并不是由始发server单向决定的，而是由组来决定是否提交。准确地说，在始发server上，当事务准备好提交时，该server会广播写入值（已改变的行）和对应的写入集（已更新的行的唯一标识符）。然后会为该事务建立一个全局的顺序。最终，这意味着所有server成员以相同的顺序接收同一组事务。因此，所有server成员以相同的顺序应用相同的更改，以确保组内一致。
在不同server上并发执行的事务可能存在冲突。 根据组复制的冲突检测机制，对两个不同的并发事务的写集合进行检测。如在不同的server成员执行两个更新同一行的并发事务，则会出现组中的其他server上删除。 这就是分布式的先提交当选规则。
图19.3 MySQL组复制协议
冲突。排在最前面的事务可以在所有server成员上提交，第二个事务在源server上回滚，并在商东京
19.1.2 组复制用例
据数
-
城部术技库
最后，组复制是一种share-nothing复制方案，其中每个server成员都有自己的完整数据副本。
上图描述了MySQL组复制协议，并通过将其与MySQL复制（MySQL半同步复制）进行比较，可以看到一些差异。 需要注意的是，这个图片中不包含一些基本共识和Paxos相关的信息。
组复制使您能够根据在一组server中复制系统的状态来创建具有冗余的容错系统。因此，只要它不是全部或多数server发生故障，即使有一些server故障，系统仍然可用，最多只是性能和可伸缩性降低，但它仍然可用。server故障是孤立并且独立的。它们由组成员服务来监控，组成员服务依赖于分布式故障检测系统，其能够在任何server自愿地或由于意外停止而离开组时发出信号。他们是由一个分布式恢复程序来确保当有server加入组时，它们会自动更新组信息到3
京东商城基础平台-数据库技术部
最新。并且多主更新确保了即使在单个服务器故障的情况下也不会阻止更新，不必进行server故障转移。因此，MySQL组复制保证数据库服务持续可用。
值得注意的一点是，尽管数据库服务可用，但当有一个server崩溃时，连接到它的客户端必须重定向或故障转移到不同的server。 这不是组复制要解决的问题。 连接器，负载均衡器，路由器或其他形式的中间件更适合处理这个问题。
总之，MySQL组复制提供了高可用性，高弹性，可靠的MySQL服务。
19.1.2.1 用例场景示例
以下示例是组复制的典型用例。
•
弹性复制 - 需要非常流畅的复制基础架构环境，其中server的数量必须动态增长或收缩，并尽可能减少副作用。 例如，云数据库服务。
•
高可用分片（Shards） - 分片是实现写扩展的常用方法。 使用MySQL组复制实现高可用性分片，其中每个分片映射到一个复制组。
•
•
可扩展性。
替代主从复制 - 在某些情况下，使用单个主服务器会造成单点争用，写入整个组可能更具自动系统 - 此外，您可以将MySQL组复制直接部署到已有复制协议的自动化系统中（在本章和前面的章节中已经描述过）。
19.1.3 组复制详细信息
本节介绍有关组复制基础服务的详细信息。
商东京19.1.3.1 故障检测
据数
-
城部术技库组复制提供了一种故障检测机制，它能够找到并报告哪些server成员是无响应的，并且假定这些server已死。在更高级别来说，故障检测是提供关于哪些server可能已死的信息（猜测）的分布式服务。 然后，如果组同意该猜测可能是真的，则组判定给定的server确实已经failed。 这意味着组中的其余成员进行协调决定以排除给定成员。
某个server无响应时触发猜测， 当server A在给定时间段内没有从server B接收消息时，将会发生超时并且触发猜测。
如果某个server与组的其余成员隔离，则它会怀疑所有其他server都失败了。 由于无法与组达成协议（因为它无法确保仲裁成员数），其怀疑不会产生后果。 当服务器以此方式与组隔离时，它无法执行任何本地事务。
4
京东商城基础平台-数据库技术部
19.1.3.2 组成员关系
MySQL组复制依赖于组成员服务。 这是一个内置的插件。 它定义了哪些server在线并在组中。
在线server列表通常称为视图。 因此，组中的每个server对于给定时刻积极参与组中的成员具有一致的视图。
同组server不仅需要关于事务提交必须达成一致意见，关于当前视图也是。 因此，如果同组server同意新的server加入，则该组本身将被重新配置从而将该server加入其中，并触发视图更新。 相反，如果server离开组，无论自愿或被迫的情况，该组都会动态地重新规划其配置，并触发视图更新。
要注意的是，当成员自愿离开时，它首先启动组的动态重新配置。 这触发一个过程，其中所有成员必须就不包含已离开server的新视图达成一致。 然而，如果成员由于发生意外而离开（例如它意外停止或网络连接断开），则故障检测机制检测到后，将提出该组的重新配置，去除故障成员。 如上所述，这需要来自组中大多数服务器达成一致意见。 如果组不能够达成一致（例如，况的发生。 最终，这意味着管理员需要介入并解决这个问题。
当大多数服务器都不在线的情况），则系统不能动态地改变配置，而且系统会锁定以防止脑裂情19.1.3.3 容错
MySQL组复制构建在Paxos分布式算法实现的基础上，以提供不同server之间的分布式协调。
因此，它需要大多数server处于活动状态以达到仲裁成员数，从而做出决定。 这对系统可以容忍的不影响其自身及其整体功能的故障数量有直接影响。 容忍f个故障所需的server数量（n）为n = 2×f + 1。
在实践中，这意味着为了容忍一个故障，组必须有三个server。 因此，如果一个服务器故障，商东京组大小
1
2
3
4
5
6
7
1
2
2
3
3
4
4
仍然有两个服务器形成大多数（三分之二）来允许系统自动地继续运行。 但是，如果第二个server意外地fail掉，则该组（剩下一个server）锁定，因为没有多数可以达成决议。
以下是说明上述公式的小表。
多数
据数
-
城允许的即时故障数
0
0
1
1
2
2
3
部术技库下一章将涵盖组复制技术方面的知识。
5
京东商城基础平台-数据库技术部
19.2 入门指南
MySQL组复制是MySQL server的插件，组中的每个server都需要配置和安装该插件。 本节提供了一个详细的教程，其中包含创建至少三台server的复制组所需的步骤。
19.2.1 在单主模式下部署组复制
组中的每个server实例可以在独立的物理机器上运行，也可以在同一台机器上运行。 本节介绍如何在一台物理机上创建具有三个MySQL Server实例的复制组。 这意味着需要三个数据目录，每个server实例一个，每个实例都需要单独配置。
图19.4组架构
商东京
本教程介绍如何使用组复制插件获取和部署MySQL Server，如何在创建组之前配置每个server实例以及如何使用Performance Schema来验证一切是否正常。
据数
-
城
部术技库
19.2.1.1部署组复制的实例
第一步是部署MySQL服务器的三个实例。 组复制是MySQL Server 5.7.17及更高版本提供的内置MySQL插件。 有关MySQL插件的更多背景信息，请参见第6.5节“MySQL服务器插件”。下载MySQL服务器包后，需要解压缩并安装二进制文件。 此过程假定MySQL服务器已下载并解压缩到当前目录，该目录需要在mysql-5.7的目录下。 由于本教程使用一个物理机，每个MySQL实例都需要一个特定的数据目录，用于存储实例的数据。 在名为data的目录中创建数据目录，并初始化每个目录。
mkdir data
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7
--datadir=$PWD/data/s1
6
京东商城基础平台-数据库技术部
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7
--datadir=$PWD/data/s2
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7
--datadir=$PWD/data/s3
在data / s1，data / s2，data / s3中是一个初始化的数据目录，包含mysql系统数据库和相关表等。 要了解有关初始化过程的更多信息，请参见第2.10.1.1节“使用mysqld手动初始化数据目录”。
Warning
不要在生产环境中使用--initialize-insecure，它只用于简化教程。 有关安全设置的更多信息，请参见第19.5节“组复制安全性”。
19.2.1.2配置组复制实例
本节介绍如何配置组复制的MySQL Server实例。 有关背景信息，请参见第19.7.2节“使用限制”。
组复制Server设置
要安装和使用组复制插件，必须正确配置MySQLserver实例。 建议将配置存储在文一个实例的配置，在此节中称为s1。 以下部分展示server的示例配置。
[mysqld]
件中。 有关详细信息，请参见第5.2.6节“文件的使用”。 如没有特殊说明，以下是组中第商东京port=24801
# server configuration
据数
-
城部术技库datadir=
basedir=
socket=
这些设置对MySQL server进行了配置，使其使用先前已创建的数据目录，并配置server应打开哪个端口，并开始侦听传入连接。
注意
在此使用非默认端口24801，因为在本教程中，三个服务器实例使用相同的主机名。 在具有三个不同机器的环境中，这种设置不是必需的。
7
京东商城基础平台-数据库技术部
复制框架
以下设置根据MySQL组复制要求配置复制。
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
这些设置将server配置为使用唯一标识号1，以启用全局事务标识符，并将复制元数据存储在用二进制日志事件校验和。 有关详细信息，请参见第19.7.2节“使用限制”
系统表（而不是文件）中。 此外，它设置server打开二进制日志记录，使用基于行的格式并禁商东京"
组复制设置
确保server中文件此时已按要求配置，且server按配置实例化复制基础结构。 以下部分是server组复制的配置。
据数
-
城部术技库transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaaloose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24901"
loose-group_replication_group_seeds=
"127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off
Note
8
京东商城基础平台-数据库技术部
如果在server启动时尚未加载组复制插件，上面group_replication变量使用的loose- 前缀将指示server继续启动，
•
•
•
•
第1行指示server必须为每个事务收集写集合，并使用XXHASH64哈希算法将其编码为散列。
第2行告知插件，正在加入或创建的组要命名为
“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。
第3行指示插件在server启动时不自动启动组复制。
第4行告诉插件使用IP地址127.0.0.1或本地主机，端口24901用于接受来自组中其他成员的传入连接。
Important
server在此端口上侦听组成员之间的连接。 此端口不能用于用户应用程序，它必须保留，用于在运行组复制时组的不同成员之间的通信。
由group_replication_local_address配置的本地地址必须可供所有组成员访问。 例如，如group_replication_local_address的推荐端口为33061，但在本教程中，我们使用在一台机器上运行的三个server实例，因此使用端口24901到24903。
• 第5行告诉插件，当下面这些server需要加入组时，应该连接到这些主机和端口上访问他果每个server实例位于不同的计算机上，则使用计算机的IP和端口，例如10.0.0.1:33061。
们。 这些就是种子成员，当此成员想要连接到组时使用，在申请加入时，server先访问这些种子成员中的一个，然后它请求组重新配置以允许它加入组。 需要注意的是，此选项不需要列出组中的所有成员，而是当此sever需要加入该组时需要访问的server列表。
启动组的server不使用此选项，因为它是初始server，因此它负责引导组。 第二个加入的server向组中的唯一成员申请加入，然后组得以扩容。 第三个加入的server可以向这两个server中的任意一个申请加入，然后组再次扩容。 后续server在加入时重复此过程。
商东京Warning
•
Important
据数
-
城部术技库当多个server同时加入时，请确保它们已在组中的种子成员。 不要使用同时正在申请加入组的种子成员，因为他们可能在访问时尚未加入群组。
首先启动引导成员并让它创建组， 然后使其成为正在加入的其余成员的种子成员。 这确保了当加入其余成员时已有一个组。
不支持创建组并同时加入多个成员。 在操作竞争时，这种情况可能会发生，但是加入组的行为最终会出现错误或超时。
第6行指示插件是否自动引导组。
此选项在任何时候只能在一个server实例上使用，通常是首次引导组时（或在整个组被崩溃然后恢复的情况下）。 如果您多次引导组，例如，当多个server实例设置了此选项，则它们可能会人为地造成脑裂的情况，其中存在两个具有相同名称的不同组。 在第一个server实例加入组后禁用此选项。
9
京东商城基础平台-数据库技术部
组中的所有server成员的配置都非常相似。 您需要更改每个server的详细信息（例如server_id，datadir，group_replication_local_address）。 这将在本教程的后面进行介绍。
19.2.1.3用户凭据
组复制使用异步复制协议来实现分布式恢复，在将组成员加入组之前将其同步。 分布式恢复过程依赖于group_replication_recovery复制通道，该复制通道用于在组成员之间传输事务。 因此，您需要设置具有正确权限的复制用户，以便组复制可以直接建立成员到成员的恢复复制通道。
启动服务器：
mysql-5.7/bin/mysqld --defaults-file=data/s1/
创建具有REPLICATION-SLAVE权限的MySQL用户。 此操作不应记录到二进制日志中，以配置服务器时需要使用正确的用户名和密码。 连接到server s1并执行以下语句：
mysql> SET SQL_LOG_BIN=0;
避免将更改传递到其他server实例。。以下示例演示了创建用户rpl_user的过程，密码为rpl_pass。
Query OK, 0 rows affected (0,00 sec)
mysql> CREATE USER rpl_user@'%';
Query OK, 0 rows affected (0,00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
Query OK, 0 rows affected, 1 warning (0,00 sec)
mysql> FLUSH PRIVILEGES;
商东京
Query OK, 0 rows affected (0,00 sec)
mysql> SET SQL_LOG_BIN=1;
据数
-
城部术技库Query OK, 0 rows affected (0,00 sec)
用户进行上述配置后，需要使用CHANGE MASTER TO语句将server配置为，在下次需要从其他成员恢复其状态时，使用group_replication_recovery复制通道的给定凭据。 执行以下命令，将rpl_user和rpl_pass替换为创建用户时使用的值。
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass'
FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0,01 sec)
分布式恢复是加入组的server执行的第一步。 如果未正确设置这些凭据，server将无法执行恢复过程并获得与其他组成员同步，因此最终将无法加入组。 类似地，如果成员无法通过server的主机名正确识别其他成员，则恢复过程可能会失败。 建议运行MySQL的操作系统都正确地配置唯一主机名，使用DNS或本地设置。 可以在performance_ation_group_members表的Member_host列中验证此主机名。 如10
京东商城基础平台-数据库技术部
果多个组成员使用操作系统设置的默认主机名，则会出现有成员无法解析到正确的成员地址且无法加入组的情况。 在这种情况下，可以使用report_host来配置每个server唯一主机名。
19.2.1.4启动组复制
配置并启动server s1后，安装组复制插件。 然后连接到server并执行以下命令：
INSTALL PLUGIN group_replication SONAME 'group_';
要检查插件是否已成功安装，请执行SHOW PLUGINS并检查输出。 它应该显示如下：
mysql> SHOW PLUGINS;
+----------------------------+----------+--------------------+----------------------+-------------+
| Name | Status | Type | Library
| License |
+----------------------------+----------+--------------------+----------------------+-------------+
| binlog | ACTIVE | STORAGE ENGINE | NULL
| PROPRIETARY |
商东京(...)
据数
-
城部术技库| group_replication | ACTIVE | GROUP REPLICATION |
group_ | PROPRIETARY |
+----------------------------+----------+--------------------+----------------------+-------------+
要启动组，请指示server s1引导组，然后启动组复制程序。 此引导应仅由单个sever独立完成，该server启动组并且只启动一次。 这就是为什么引导配置选项的值不保存在配置文件中的原因。 如果将其保存在配置文件中，则在重新启动时，server会自动引导具有相同名称的第二个组。 这将导致两个不同的组具有相同的名称。 同样的道理适用于停止和重新启动插件，并且此选项设置为ON。
SET GLOBAL group_replication_bootstrap_group=ON;
11
京东商城基础平台-数据库技术部
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
START GROUP_REPLICATION语句返回后，组就已启动了。 您可以检查该组现在是否已创建并且其中已经有一个成员：
mysql> SELECT * FROM performance_ation_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 |
myhost | 24801 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
1 row in set (0,00 sec)
商东京户端连接。
mysql> use test
Database changed
此表中的信息确认了组中有一个成员并且具有唯一的标识符ce9be252-2b71-11e6-b8f4-00212844f856，它是在线的并且在myhost侦听端口24801上的客据数
-
城部术技库为了演示server确实在一个组中，并且能够处理加载，创建一个表并向其中添加一些内容。
mysql> CREATE DATABASE test;
Query OK, 1 row affected (0,00 sec)
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
12
京东商城基础平台-数据库技术部
Query OK, 0 rows affected (0,00 sec)
mysql> INSERT INTO t1 VALUES (1, 'Luis');
Query OK, 1 row affected (0,01 sec)
检查表t1和二进制日志的内容。
mysql> SELECT * FROM t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0,00 sec)
商东京|
mysql> SHOW BINLOG EVENTS;
据数
-
城部术技库+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 | 4 | Format_desc | 1 | 123 | Server ver:
5.7.17-gr080-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 1 | 150 |
|
| binlog.000001 | 150 | Gtid | 1 | 211 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
13
京东商城基础平台-数据库技术部
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN
|
| binlog.000001 | 270 | View_change | 1 | 369 |
view_id=259180:1 |
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT
|
| binlog.000001 | 434 | Gtid | 1 | 495 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE
DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`;
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| binlog.000001 | 831 | Query | 1 | 899 | BEGIN
商东京|
| binlog.000001 | 899 | Table_map | 1 | 942 | table_id: 108
(test.t1) |
| binlog.000001 | 942 | Write_rows | 1 | 984 | table_id:
108 flags: STMT_END_F |
| binlog.000001 | 984 | Xid | 1 | 1011 | COMMIT /*
xid=38 */ |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
15 rows in set (0,00 sec)
据数
-
城部术技库如上所示，创建了数据库和表对象，并且将其对应的DDL语句写入二进制日志。 此外，数据被插入到表中并被写入二进制日志。 当组成员增长并且由于新成员尝试加入并变为在线而执行分布式恢复时，二进制日志条目的重要性将在以下部分中说明。
14
京东商城基础平台-数据库技术部
19.2.1.5向组中添加实例
此时，组中有一个成员，已经有一些数据存在的server s1。 此时就可以通过添加先前配置的其他两个server来扩展组了。
19.2.1.5.1添加第二个实例
为了添加第二个实例server s2，首先为它创建配置文件。 该配置类似于用于server s1的配置，除了诸如数据目录的位置，s2将要监听的端口或其server_id之类的事情之外。 这些不同的行已在下面的列表中突出显示。
[mysqld]
# server configuration
datadir=
basedir=
port=24802
商东京
#
#
server_id=2
gtid_mode=ON
socket=
据数
-
城部术技库# Replication configuration parameters
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
15
京东商城基础平台-数据库技术部
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24902"
loose-group_replication_group_seeds=
商东京SET SQL_LOG_BIN=0;
SET SQL_LOG_BIN=1;
"127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off
据数
-
城部术技库与server s1的过程类似，在配置文件就位的情况下启动server。
mysql-5.7/bin/mysqld --defaults-file=data/s2/
然后按如下所示配置恢复凭据。 由于用户在组中共享，该命令与设置server s1时使用的命令相同。 在s2上执行以下语句。
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass'
FOR CHANNEL 'group_replication_recovery';
16
京东商城基础平台-数据库技术部
安装组复制插件，并启动将server加入组的程序。 以下示例使用与部署server s1时相同的方式安装插件。
mysql> INSTALL PLUGIN group_replication SONAME 'group_';
Query OK, 0 rows affected (0,01 sec)
将server s2添加到组。
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (44,88 sec)
与之前的步骤不同，这里与s1上执行的那些步骤有一个区别，就是不执行SET GLOBAL
创建和引导。 此时，server s2只需要添加到已经存在的组中。
there are now twoONLINE servers in the group.
ONLINE的server。
group_replication_bootstrap_group = ON的操作; 在启动组复制之前，因为该组已由server s1Checking the
performance_ation_group_members table again shows that
再次检查performance_ation_group_members表，可以看出组中现在有两个mysql> SELECT * FROM performance_ation_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
商东京| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
据数
-
城部术技库+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 |
myhost | 24801 | ONLINE |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 |
myhost | 24802 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
2 rows in set (0,00 sec)
17
京东商城基础平台-数据库技术部
由于server s2也被标记为ONLINE，它必须已经与server s1同步。 按照如下方式验证它确实与server s1同步。
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
1 row in set (0,00 sec)
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
商东京| 1 | Luis |
+----+------+
据数
-
城部术技库1 row in set (0,00 sec)
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
|
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
18
京东商城基础平台-数据库技术部
| binlog.000001 | 4 | Format_desc | 2 | 123 | Server ver:
5.7.17-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 2 | 150 |
|
| binlog.000001 | 150 | Gtid | 1 | 211 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN
|
| binlog.000001 | 270 | View_change | 1 | 369 |
view_id=483517:1 |
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT
|
| binlog.000001 | 434 | Gtid | 1 | 495 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE
DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET
商东京|
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`;
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
据数
-
城部术技库| binlog.000001 | 831 | Query | 1 | 890 | BEGIN
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id:
108 (test.t1) |
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id:
108 flags: STMT_END_F |
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /*
xid=30 */ |
19
京东商城基础平台-数据库技术部
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' |
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGIN
|
| binlog.000001 | 1122 | View_change | 1 | 1261 |
view_id=483517:2 |
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT
|
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
19 rows in set (0,00 sec)
如上所示，第二个server已添加到组中，并且已自动从server s1复制了更改。 按照分布式恢复过程，这意味着加入组之后并且在即将被声明在线之前，server s2自动地连接到server s1之前缺少的事务。
19.2.1.5.2添加其他实例
并且从其获取丢失的数据。 换句话说，它从s1的二进制日志中复制了它在加入组的时间节点向组添加其他实例与添加第二个server基本上是相同的步骤，除了配置必须更改为对应的server。
商东京总结所需的命令如下：
1.创建配置文件
[mysqld]
port=24803
据数
-
城部术技库# server configuration
datadir=
basedir=
socket=
20
京东商城基础平台-数据库技术部
#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
商东京
#
#
"
据数
-
城部术技库# Group Replication configuration
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaaloose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24903"
loose-group_replication_group_seeds=
"127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
21
京东商城基础平台-数据库技术部
loose-group_replication_bootstrap_group= off
2. 启动server
mysql-5.7/bin/mysqld --defaults-file=data/s3/
3. 配置group_replication_recovery通道的恢复凭据
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass'
FOR CHANNEL 'group_replication_recovery';
4. 安装组复制插件并启动。
INSTALL PLUGIN group_replication SONAME 'group_';
商东京START GROUP_REPLICATION;
据数
-
城部术技库此时，server s3被引导并且正在运行，并且已经加入组且已与组中的其他server成员同步。 访问performance_ation_group_members表再次确认真实情况确实如此。
mysql> SELECT * FROM performance_ation_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 |
myhost | 24801 | ONLINE |
22
京东商城基础平台-数据库技术部
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 |
myhost | 24803 | ONLINE |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 |
myhost | 24802 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
3 rows in set (0,00 sec)
在server s2或server s1上发出此相同的查询会产生相同的结果。 此外，您可以验证server s3已经同步：
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
商东京
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0,00 sec)
据数
-
城部术技库mysql> SELECT * FROM test.t1;
1 row in set (0,00 sec)
23
京东商城基础平台-数据库技术部
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
|
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 | 4 | Format_desc | 3 | 123 | Server ver:
5.7.17-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 3 | 150 |
|
| binlog.000001 | 150 | Gtid | 1 | 211 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN
|
| binlog.000001 | 270 | View_change | 1 | 369 |
view_id=483517:1 |
商东京|
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT
据数
-
城部术技库| binlog.000001 | 434 | Gtid | 1 | 495 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE
DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`;
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
24
京东商城基础平台-数据库技术部
| binlog.000001 | 831 | Query | 1 | 890 | BEGIN
|
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id:
108 (test.t1) |
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id:
108 flags: STMT_END_F |
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /*
xid=29 */ |
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' |
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGIN
|
| binlog.000001 | 1122 | View_change | 1 | 1261 |
view_id=483517:2 |
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT
|
| binlog.000001 | 1326 | Gtid | 1 | 1387 | SET
商东京|
|
@@_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6' |
| binlog.000001 | 1387 | Query | 1 | 1446 | BEGIN
据数
-
城部术技库| binlog.000001 | 1446 | View_change | 1 | 1585 |
view_id=483517:3 |
| binlog.000001 | 1585 | Query | 1 | 1650 | COMMIT
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
23 rows in set (0,00 sec)
25
京东商城基础平台-数据库技术部
19.3监控组复制
假设MySQL已经在启用了性能模式的情况下编译，使用Perfomance Schema表监控组复制。
组复制添加以下两个新的P_S表：
•
•
performance_ation_group_member_stats
performance_ation_group_members
这些现有的P_S复制表也显示有关组复制的信息。
•
•
performance_ation_connection_status
performance_ation_applier_status
由组复制插件创建的复制通道名为：
•
•
group_replication_recovery - This channel is used for the replication changes that
are related to the distributed recovery phase.
group_replication_applier - This channel is used for the incoming changes from
the group. This is the channel used to apply transactions coming directly from the group.
以下部分描述了每个表中可用的信息。
19.3.1 Replication_group_member_stats
复制组中的每个成员都会验证并应用该组提交的事务。 有关验证和应用程序的统计信息对于了商东京信息。
Field
Channel_name
Member_id
解申请队列增长情况、触发了多少冲突、检查了多少事务、哪些事务已被所有成员提交等等非常有用。 表performance_ation_group_member_stats提供与认证过程相关的以下据数
-
城组复制通道的名称
部术技库表19.1 replication_group_member_stats
描述
此值为我们当前连接到的server成员的UUID。组中的每个成员具有不同的值。因为它对每个成员是唯一的，所以它也成为了一个关键字。
队列中等待冲突检测检查的事务数。冲突检查通过后，他们Count_Transactions_in_queue
Count_transactions_checked
Count_conflicts_detected
排队等待应用。
表示已进行过冲突检查的事务数。
表示未通过冲突检测检查的事务数。
26
京东商城基础平台-数据库技术部
Field 描述
表示冲突检测数据库的当前大小（每个事务经过验证的数据Count_transactions_validating 库）。
表示已在当前视图的所有成员上成功提交的事务。 此值以Transactions_committed_all_members
固定的时间间隔更新。
Last_conflict_free_transaction 显示最后一个经检查无冲突的事务标识符。
这些字段对于监控组中的成员的性能很重要。 例如，假设组的成员之一出现延迟，并且不能与该组的其他成员同步。 在这种情况下，您可能会在队列中看到大量的事务。 基于此信息，您可以决定从组中删除成员或延迟组中其他成员的事务处理，从而减少排队的事务的数量。 此信息还可以帮助您决定如何调整组复制插件的流控制。
19.3.2 Replication_group_members
该表用于监控在当前视图中的不同server实例的状态，或者换句话说，是该组的一部分，用于组员服务追踪。
表19.2 replication_group_members
Field
Channel_name 组复制通道的名称
商东京Member_id server成员的UUID
Member_host 组成员的网络地址
据数
-
城描述
部术技库Member_port 侦听此成员的MySQL连接端口
Member_state
组成员的状态(判断他们是ONLINE, RECOVERING, OFFLINE 或者
UNREACHABLE中的某一个)
有关Member_host值的详细信息及其对分布式恢复过程的影响，请参见第19.2.1.3节“用户凭据”。
19.3.3 Replication_connection_status
连接到组时，此表中的某些字段显示有关组复制的信息。 例如，已从组中接收并在应用队列（中继日志）中排队的事务。
表 19.3 replication_connection_status
27
京东商城基础平台-数据库技术部
Field
Channel_name
Group_name
组复制通道的名称
表示组名称的值。 它始终是有效的UUID。
表示组的标识符。 它类似于组名称，并被用作组复制期间生成的所有Source_UUID 事务的UUID。
显示某个成员是否是组的一部分。 服务状态的可能值为{ON，OFF和Service_state CONNECTING};
Description
Received_transaction_set 此GTID集合中的事务已由该组的此成员接收。
19.3.4 Replication_applier_status
可以使用常规replication_applier_status表观察组复制相关的通道和线程的状态。 如果有许多不同的工作线程在应用事务，那么工作表也可以用来监控每个工作线程正在做什么。
表 19.4 replication_applier_status
Field
Channel_name
商东京Service_state
Remaining_delay
据数
-
城描述
组复制通道的名称。
显示应用服务是开启还是关闭。
显示是否配置了应用延迟。
部术技库Count_transactions_retries 应用事务的重试次数。
Received_transaction_set 此GTID集合中的事务已由该组的此成员接收。
19.3.5组复制中的server状态
每当视图更改时，表replication_group_members就会更新，例如，当组的配置动态更改时。 在此基础上，server成员之间交换他们的一些元数据以保持同步并继续协作。
组中的server实例可以处于多种状态。如果server都正常通信，则所有server都报告相同的状态。 但是，如果存在网络分隔，或者组成员离开组，则可能报告不同的信息，这取决于查询了哪个server。 要注意的是，如果某个组成员已经离开组，那么显然它不能报告关于其他server状态的最新信息。 如果发生网络分隔，如果超出仲裁数量的server都断开了，那么server之
28
京东商城基础平台-数据库技术部
间将不能相互协作。 因此，他们无法得知不同server成员的状态。 因此，他们会报告一些server不可访问，而不是猜测他们的状态。
表 19.5 Server State
Group
Field 描述
该成员可以作为一个具有所有功能的组成员，这意味着客户端可以ONLINE 连接并开始执行事务。
该成员正在成为该组的有效成员，并且正处于恢复过程中，从数据RECOVERING 源节点（数据源节点）接收状态信息。
OFFLINE 插件已加载，但成员不属于任何组。
No
No
Yes
Synchronized
本地成员的状态。 只要恢复阶段或应用更改时出现错误，serverERROR 就会进入此状态。
每当本地故障检测器怀疑某个给定的server可能由于已经崩溃或UNREACHABLE
被意外地断开而不可访问时， No
server的状态显示为“UNREACHABLE”。
需要注意的是，组复制不是同步复制，但最终是同步的。 更确切地说，事务以相同的顺序传递给所有组成员，但是它们的执行不同步，这意味着在接受事务被提交之后，每个成员以其自己的速度提交。
商东京19.4 组复制操作
据数
-
城部术技库No
本节介绍部署组复制的不同模式，说明管理组的常见操作，并提供有关如何调整组的信息。
19.4.1 以多主模式或单主模式部署
组复制在以下不同模式下运行：
•
•
单主模式
多主模式
默认模式为单主模式。组的不同成员不能部署在不同的模式下，例如一个配置为多主模式，而另一个为单主模式。 要在模式之间切换，需要使用不同配置重新启动组而不是单个server。 无论部署模式如何，组复制不处理客户端 fail-over，必须由应用程序本身、连接器或中间件框架（如代理或路由器）处理。
29
京东商城基础平台-数据库技术部
在多主模式下部署时，将检查语句以确保它们与模式兼容。 在以多主模式部署组复制时需要进行以下检查：
•
•
如果事务在SERIALIZABLE隔离级别下执行，则在与组同步时，它的提交会失败。
如果事务对具有外键约束的表进行操作，则事务在与组同步时无法提交。
可以通过将optiongroup_replication_enforce_update_everywhere_checks设置为FALSE来禁用这些检查。 在单主机模式下部署时，此选项必须设置为FALSE。
19.4.1.1 单主模式
在此模式下，组有一个设置为读写模式的单主server。 组中的所有其他成员被自动设置为只读模式（超级只读模式）。主服务器通常是用于引导组的第一个server，所有其他加入的server自动从主服务器同步并设置为只读。
图19.5选取新主
商东京19.4.1.2 多主模式
在单主机模式下，将禁用在多主机模式下部署的某些检查，因为系统会强制在组中每次只有一个写入server。 例如，在单主模式下允许对具有外键的表进行更改，而在多主模式下不允许。 在主服务器故障时，自动选主机制选择下一个主服务器。 通过按字典顺序（使用其UUID）来排序剩余的server成员并选择列表中的第一个成员来作为下一个主服务器。
如果主服务器从组中移除，则启动主节点选择程序，然后从组中的其余server成员中选择新的主节点。通过查看新视图，按照词典顺序将server的UUID进行排序并选择第一个作为主节点。选择了新的主节点后，它将自动设置为只读，其他辅助节点仍然为辅助节点，因此也是只读。
在将客户端应用程序重新路由到它之前，等待新的主节点完成所有的数据同步是一个很好的选择。
据数
-
城部术技库
在多主模式下，没有单主模式的概念。 没有必要使用选主程序，因为不同server成员之间没有什么特殊的差异。
图19.6客户端故障转移
30
京东商城基础平台-数据库技术部
加入组时，所有server成员都将被设置为读写模式。
19.4.1.3 查找主节点
以下示例显示了在单主模式下部署时，如何确定当前哪个server成员是主服务器。
mysql> SELECT VARIABLE_VALUE FROM performance__status WHERE
VARIABLE_NAME= 'group_replication_primary_member';
+--------------------------------------+
| VARIABLE_VALUE |
+--------------------------------------+
+--------------------------------------+
1 row in set (0,00 sec)
| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |
商东京
19.4.2 调整恢复
据数
-
城部术技库每当新成员加入复制组时，它将连接到合适的数据源节点数据源节点来获取它所缺失的数据，直到它的状态为OLINE。 组复制中的这个关键组件是容错和可配置的。 以下部分说明恢复如何进行以及如何调整设置。
数据源节点数据源节点选择
从该组中的现有在线成员中随机选择数据源节点数据源节点。 当多个成员进入组时，同一server几乎不会被重复选择。
如果访问所选数据源节点数据源节点失败，则自动连接到新的候选数据源节点数据源节点。 一旦达到连接重试限制，恢复过程将终止并报错。
Note
31
京东商城基础平台-数据库技术部
数据源节点数据源节点从当前视图中的在线成员列表中随机选择的。
增强型自动数据源节点数据源节点切换
总体来说，完整恢复的另一个关键点是确保它能够应对故障。 因此，组复制提供了可靠的错误检测机制。 在早期版本的组复制中，当访问一个数据源节点数据源节点时，恢复程序只能检测出认证问题或一些其他问题导致的连接错误。 应对这种场景的策略是切换到新的数据源节点数据源节点，因此会对别的成员进行新的连接尝试。
这种模式被扩展使用到其他故障场景：
•
已清除的数据 - 如果所选数据源节点数据源节点上恢复过程所需的某些数据已被清除，则会出现错误。 恢复程序检测到此错误并会选择新的数据源节点数据源节点。
•
重复数据
- 如果新加入的server已经包含一些与选定数据源节点数据源节点提供的数据误的事务。
相冲突的数据，那么在恢复期间会发生错误。 这可能是由于新加入的server中存在一些错有人可能认为恢复过程应该失败退出，而不是切换到另一个数据源节点数据源节点，但在恢复程序将从组中选择另一个数据源节点数据源节点。
•
异构集群中有一些其他成员共享冲突事务，而另一些没有。 因为这个原因，错误发生时，其他错误
- 如果任何恢复线程失败（接收或应用线程失败），则会出现错误，恢复程序切换到新的数据源节点数据源节点。
商东京节点。
重试功能。
Note
在一些持续故障甚至短暂故障的情况下，恢复程序自动重试连接到相同或新的数据源节点数据源据数
-
城部术技库数据源节点数据源节点连接重试
恢复的数据传输依赖于二进制日志和现有MySQL复制框架，因此一些短暂错误可能会导致接收或应用线程错误。 在这种情况下，数据源节点切换过程具有重试功能，类似于在常规复制中的尝试次数
当要加入的server尝试从数据源节点池连接到某个数据源节点时，所尝试次数为10.这通过group_replication_recovery_retry_count这个插件变量进行配置。 以下命令将连接到数据源节点的最大尝试次数设置为10。
SET GLOBAL group_replication_recovery_retry_count= 10;
需要注意的是，这是要加入的server会尝试连接到每个合适的数据源节点的全局次数。
32
京东商城基础平台-数据库技术部
睡眠程序
group_replication_recovery_reconnect_interval这个插件变量定义了恢复进程在尝试连接到数据源节点时应休眠多长时间。 此变量的默认设置为60秒，您可以动态更改此值。 以下命令设置尝试连接到恢复数据源节点的重试间隔时间为120秒。
SET GLOBAL group_replication_recovery_reconnect_interval= 120;
要注意的是，恢复程序不会在每次尝试连接数据源节点后休眠。 由于要加入的server会尝试连接到不同的server，而不是不断地尝试连接到同一个server，我们可以假设影响server A的问题可能不影响server B.因此，恢复程序仅当它已经对所有可能的数据源节点进行尝试无果后才会停止。要加入的server尝试连接到组中的所有可能的数据源节点后，恢复程序会在由group_replication_recovery_reconnect_interval配置的秒数后休眠：
19.4.3 网络分隔
当复制的网络环境发生变化时，组内需要达成共识。 这是常规事务的处理，而且对于组成员更改和保持组一致的某些内部消息传递也是必需的。 组内共识需要大多数组成员就给定的决定达成一致。 当大多数组成员丢失时，由于无法确保多数或仲裁成员是否存活，组将无法继续运行而停止。
当有多个节点意外故障时，仲裁可能会丢失，导致大多数server成员突然从组中被移除。 例如，被破坏，因此不能实现仲裁。 事实上，剩下的两个server不能分辨其他3个server是否崩溃或网络分隔了这2个server，因此无法自动重新配置组。
在一个5个server组成的组中，如果其中3个server突然没有消息，也就是大多数server成员商东京Note
19.4.3.1 检测分区
另一方面，如果有server成员主动退出组，那它们会告知组应该重新进行配置。 实际上，这意味着一个将要离开的server成员会告诉其余的server成员它将要离开。 这也意味着其他成员可以正确地重新配置组，保持组成员关系的一致性，并重新计算仲裁成员数。 例如，上述的场景中存在5个server成员，3个server要离开，如果3个要离开的server成员告知组他们一个接一个地离开，则组成员能够将组的总数从5调整到2，与此同时确保仲裁成员数。
据数
-
城部术技库仲裁成员数的丢失本身就是不良规划造成的。 要根据预期故障数（无论它们是否持续地同时发生，还是偶尔发生）计划组的大小。
以下部分将介绍，如果系统被分隔了导致组内仲裁成员数无法自动达成时，应该怎么处理。
performance schema 下的replication_group_members表，从每个server的角度显示当前视图中每个server的状态。 大多数情况下系统不会发生分隔，因此该表显示的信息对于组中的所有server成员都是一致的。 换句话说，此表上的每个server的状态都由当前视图中的所有server33
京东商城基础平台-数据库技术部
成员达成决议的。 但是，如果存在网络分隔，并且仲裁丢失，则表对于访问不到的那些server显示状态UNREACHABLE。 此信息由组复制中内置的本地故障检测器导出。
图19.7 仲裁丢失
为了理解这种类型的网络分隔，下面的部分描述了最初有5个server成员的组正确工作的场景，以及只有2个server成员在线时该组发生的改变。 这种场景在图中进行了描述。
因此，我们假设有一个组中有这5个server：
•
•
•
•
•
server s1, 成员标识符为199b2df7-4aaf-11e6-bb16-28b2bd168d07
server s3, 成员标识符为1999b9fb-4aaf-11e6-bb54-28b2bd168d07
server s4, 成员标识符为19ab72fc-4aaf-11e6-bb51-28b2bd168d07
server s2, 成员标识符为199bb88e-4aaf-11e6-babe-28b2bd168d07
商东京这一点。 例如：
server s5, 成员标识符为19b33846-4aaf-11e6-ba81-28b2bd168d07
最初，组可以正常运行，server之间可以畅通地相互通信。
您可以通过登录到s1并查看performance schema 下的replication_group_members表来验证据数
-
城部术技库mysql> SELECT * FROM performance_ation_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 |
127.0.0.1 | 13002 | ONLINE |
34
京东商城基础平台-数据库技术部
| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 |
127.0.0.1 | 13001 | ONLINE |
| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 |
127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 |
127.0.0.1 | 13003 | ONLINE |
| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 |
127.0.0.1 | 13004 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
5 rows in set (0,00 sec)
但是，不久之后发生灾难性的故障，server s3，s4和s5意外停止。 几秒钟后，再次查看在s1的replication_group_members表显示它仍然在线，但其他几个成员不在线。 事实上，如下所示，它们被标记为UNREACHABLE。 此外，系统不能重新进行自身配置改变成员关系，因为大多数成员已经丢失。
mysql> SELECT * FROM performance_ation_group_members;
+---------------------------+--------------------------------------+----商东京---------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 |
127.0.0.1 | 13002 | UNREACHABLE |
| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 |
127.0.0.1 | 13001 | ONLINE |
| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 |
127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 |
127.0.0.1 | 13003 | UNREACHABLE |
35
据数
-
城部术技库
京东商城基础平台-数据库技术部
| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 |
127.0.0.1 | 13004 | UNREACHABLE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
5 rows in set (0,00 sec)
该表显示，s1现在处于一个在没有外部干预的情况下无法继续运行的组中，因为大多数server不可访问。 在这种特殊情况下，为了让系统继续进行，组成员关系列表需要重置，这已经在本节中讲解过。 或者，您也可以选择停止s1和s2上的组复制（或完全停止s1和s2），找出s3，s4和s5停止的原因，然后重新启动组复制（或服务器）。
19.4.3.2 解除分隔
组复制使您能够通过强制执行特定配置来重置组成员关系列表。 例如，在上面的情况中，其中s1和s2是仅有的在线server，您可以强制地为s1和s2配置一致的组成员关系。 这就需要检查有关s1和s2的一些信息，然后使用group_replication_force_members变量。
图19.8强制配置组成员关系
商东京
Warning
据数
-
城
部术技库假设s1和s2是组中仅有的server成员的情况，server s3，s4和s5意外地离开了组。 要使s1和s2继续运行，您就可能要强制地配置仅包含s1和s2的成员关系。
此过程使用group_replication_force_members，并应被视为最后的补救措施。使用group_replication_force_members应该非常小心，它仅用来重置仲裁成员数丢失的情况。 如果被滥用，它可能导致人为的脑裂情况或阻塞整个系统运行。
试想一下，系统被阻塞，并且当前配置如下（这是s1上的本地故障检测器所检测到的）：
36
京东商城基础平台-数据库技术部
mysql> SELECT * FROM performance_ation_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 |
127.0.0.1 | 13002 | UNREACHABLE |
| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 |
127.0.0.1 | 13001 | ONLINE |
| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 |
127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 |
127.0.0.1 | 13003 | UNREACHABLE |
| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 |
127.0.0.1 | 13004 | UNREACHABLE |
商东京息，如下所示。
+---------------------------+--------------------------------------+-------------+-------------+--------------+
5 rows in set (0,00 sec)
据数
-
城部术技库首先要做的是检查s1和s2的对等地址（组通信标识符）是什么。 登录到s1和s2并获取该信mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| 127.0.0.1:10000 |
+-----------------------------------+
37
京东商城基础平台-数据库技术部
1 row in set (0,00 sec)
然后登录到s2并做同样的操作：
mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| 127.0.0.1:10001 |
+-----------------------------------+
1 row in set (0,00 sec)
知道s1（127.0.0.1:10000）和s2（127.0.0.1:10001）的组通信地址后，就可以在其中一台服下操作：
mysql> SET GLOBAL
务器上配置新的成员关系，从而覆盖现有的仲裁成员数丢失情况下的成员关系。在s1上进行如group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";
商东京
Query OK, 0 rows affected (7,13 sec)
这会强制地使用不同的配置来解锁组。 检查s1和s2上的replication_group_members表以验证更改后的组成员关系。 首先检查s1。
据数
-
城部术技库mysql> select * from performance_ation_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 |
127.0.0.1 | 13000 | ONLINE |
38
京东商城基础平台-数据库技术部
| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 |
127.0.0.1 | 13001 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0,00 sec)
然后检查s2.
mysql> select * from performance_ation_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST
| MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 |
127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 |
商东京操作是非常重要的。
19.5 组复制安全
127.0.0.1 | 13001 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0,00 sec)
据数
-
城部术技库当进行强制配置成员关系时，需要确保所有将被强制从组中移除的server都已经停止工作了。 在上面描述的情形中，如果s3，s4和s5不是真正不可访问的，而是在线的，则它们可能已经形成了它们自己的功能分隔区（它们是5个server中的3个，因此他们是大多数）。 在这种情况下，强制配置由s1和s2组成的成员列表会造成人为的脑裂情况。 因此，在强制地配置成员关系前，需要确保将要移除的server确实已经关闭，如果没有关闭，则在继续配置之前执行关闭本节介绍如何通过保护组成员之间的连接，或者使用地址白名单来确保一个组是安全有效的工作。
39
京东商城基础平台-数据库技术部
19.5.1 IP地址白名单
组复制插件具有一个配置选项，用于确定哪些主机可以接入的组通信连接。 此选项称为group_replication_ip_whitelist。 如果在server s1上设置此选项，则当server s2正在建立与s1的组通信连接时，s1在接受s2的连接请求之前，需要首先检查白名单。 如果s2在白名单中，则s1接受连接，否则s1拒绝s2的连接尝试。
Note
默认情况下，如果未明确说明，白名单将自动设置为一个该server的私有网络接口地址。
如果未配置任何白名单，则server会自动将白名单设置为他的私有网络接口地址。 这意味着，即使server具有公共IP上的接口，默认也不会允许来自外部主机的连接。
每当IP白名单设置为AUTOMATIC时，在这种情况下错误日志中会显示如下信息：
2016-07-07T06:40:49.320686Z 4 [Note] Plugin group_replication reported:
'Added automatically
IP ranges 10.120.40.237/18,10.178.59.44/22,127.0.0.1/8 to the whitelist'
您可以通过手动设置允许进行组通信连接的IP地址列表，来进一步提高组的安全性。 可以使用CIDR标识法或简单的IP地址来制定列表。 使用逗号分隔各个条目。 例如：
mysql> STOP GROUP_REPLICATION;
mysql> SET GLOBAL
.1/8";
商东京Note
加的。
group_replication_ip_whitelist="10.120.40.237/18,10.178.59.44/22,127.0.0据数
-
城部术技库mysql> START GROUP_REPLICATION;
本地主机IP地址（127.0.0.1）始终添加到白名单中。 如果没有明确说明，它是隐式和自动添19.5.2 安全套接字层的支持（SSL）
MySQL组复制支持MySQL Server的OpenSSL和YaSSL协议。
组通信连接以及恢复程序的连接使用SSL进行保护。 以下部分说明如何配置连接。
40
京东商城基础平台-数据库技术部
为配置恢复SSL
恢复是通过常规异步复制连接实现的。一旦数据源节点选择好，新加入的server通过异步复制与自动其建立连接。
但是，请求SSL连接的用户必须在要加入的server连接到数据源节点之前被创建。 通常，这是在给要加入组的server指定数据源节点时设置的。
数据源节点> SET SQL_LOG_BIN=0;
数据源节点> CREATE USER 'rec_ssl_user'@'%' REQUIRE SSL;
数据源节点> GRANT replication slave ON *.* TO 'rec_ssl_user'@'%';
数据源节点> SET SQL_LOG_BIN=1;
假设组中的所有server成员都已经有一个设置好的复制用户用于使用SSL，您可以将server配置为在连接到数据源节点时使用这些凭证。 这是通过为组复制插件配置的SSL选项的值来配置的。
new_member> SET GLOBAL group_replication_recovery_use_ssl=1;
new_member> SET GLOBAL group_replication_recovery_ssl_ca=
'.../';
商东京new_member> SET GLOBAL group_replication_recovery_ssl_cert=
'.../';
据数
-
城部术技库new_member> SET GLOBAL group_replication_recovery_ssl_key=
'.../';
并且要通过将恢复通道配置为“需要SSL连接的用户凭证”来实现。
new_member> CHANGE MASTER TO MASTER_USER="rec_ssl_user" FOR CHANNEL
"group_replication_recovery";
new_member> START GROUP_REPLICATION;
配置组通信相关的SSL
可以使用安全套接字在组成员之间建立通信。 此配置取决于server的SSL配置。 因此，如果server配置了SSL，则组复制插件也配置了SSL。 有关配置server的SSL选项的详细信息，请参见第7.4.5节“安全连接的命令选项”。 配置组复制的选项如下表所示。
41
京东商城基础平台-数据库技术部
表 19.6 SSL 选项
Server 配置
ssl_key
ssl_cert
ssl_ca
插件配置说明
密钥文件的路径。 用作客户端和服务器认证
证书文件的路径。 用作客户端和服务器证书。
受信任的具有SSL CA的文件路径。
ssl_capath 包含受信任的SSL CA证书的目录路径。
ssl_crl 包含证书吊销列表的文件路径。
ssl_crlpath 包含已撤销的证书列表文件的目录路径。
ssl_cipher 在通过连接加密数据时允许使用的密码。
tls_version 安全通信将使用此版本及其协议。
身的SSL”的组复制选项。
•
这些选项是组配置所依赖的MySQL server配置选项。 此外，还有以下专门用于“配置插件本group_replication_ssl_mode - 指定组复制成员之间的连接的安全状态。
表19.7 group_replication_ssl_mode配置值
Value
商东京DISABLED
REQUIRED
VERIFY_CA
建立未加密的连接（默认）。
如果server支持安全连接，则建立安全连接。
类似于REQUIRED，但会额外根据已配置的证书颁发机构（CA）证书进行验证server TLS证书。
据数
-
城描述
部术技库VERIFY_IDENTITY
与VERIFY_CA类似，但会额外验证server证书与尝试连接的主机匹配。
以下示例展示了如何在server的文件中配置SSL以及如何在组复制中激活它。
[mysqld]
ssl_ca = ""
ssl_capath = "/.../ca_directory"
ssl_cert = ""
ssl_cipher = "DHE-RSA-AEs256-SHA"
42
京东商城基础平台-数据库技术部
ssl_crl = ""
ssl_crlpath = "/.../crl_directory"
ssl_key = ""
group_replication_ssl_mode= REQUIRED
列出的选项中唯一专用于插件的配置选项为group_replication_ssl_mode。 此选项通过“使用提供给server的ssl_ *参数配置SSL框架”来激活组成员之间的SSL通信。
19.5.3 虚拟专用网（VPN）
组复制在虚拟专用网上运行没有什么限制条件。 它的核心只是依靠一个IPv4套接字在server成员之间建立连接，以便在它们之间传播消息。
19.6 组复制系统变量
本节是特定于组复制插件的系统变量。 每个配置选项都以“group_replication”作为前缀。
Important
虽然大多数动态变量，并且可以在server运行时更改，但大多数更改仅在重新启动组复制插件时生效。 在本节中主要关注那些不需要重启插件进行更改的变量。
商东京•
group_replication_group_name
引入
5.7.17
命令行格式
--group-replication-group-name=value
名称
group_replication_group_name据数
-
城string
部术技库变量范围
Global
动态变量
Yes
类型
系统变量
允许值
•
•
此server实例所属组的名称。 必须是有效的UUID格式。
group_replication_start_on_boot
引入
5.7.17
命令行格式
--group-replication-start-on-boot=value
名称
系统变量
允许值
•
group_replication_start_on_boot变量范围
Global
动态变量
Yes
类型
默认值
boolean
ON
43
server是否应在自身启动期间启动组复制。
京东商城基础平台-数据库技术部
•
group_replication_local_address
引入
系统变量
允许值
•
•
5.7.17
命令行格式
--group-replication-local-address=value
名称
group_replication_local_address变量范围
Global
动态变量
Yes
类型
string
作为本地地址，格式为主机:端口。
group_replication_group_seeds
引入
系统变量
允许值
•
•
5.7.17
命令行格式
--group-replication-group-seeds=value
名称
group_replication_group_seeds变量范围
Global
动态变量
Yes
类型
string
组内其他成员的地址列表，以逗号分隔开，如host1:port1，host2:port2。
group_replication_force_members
引入
系统变量
允许值
5.7.17
命令行格式
--group-replication-force-members=value
名称
group_replication_force_members变量范围
Global
动态变量
Yes
类型
string
商东京•
•
以逗号分隔开的组内其他成员的地址列表，如host1:port1，host2:port2。 此选项用于强制据数
-
城部术技库建立新的组成员关系，在此过程中已排除的成员不接收新的视图并且被排除在外。 您需要手动移除已排除的server。
group_replication_bootstrap_group
引入
5.7.17
命令行格式
--group-replication-bootstrap-group=value
系统变量
允许值
•
名称
group_replication_bootstrap_group变量范围
Global
动态变量
Yes
类型
默认值
boolean
OFF
配置此server以引导组。 此选项只能在一个server上设置，且只能在首次启动组或重启整个组时设置。 组被引导后，将此选项设置为OFF。 它被动态地在配置文件中设置为OFF。
当设置了此选项后，如果在组运行时启动两个server或重启一个server，可能会导致人为脑裂情况，此过程会造成两个具有相同名称的独立组。
44
京东商城基础平台-数据库技术部
•
group_replication_poll_spin_loops
引入
命令行格式
系统变量
5.7.17
--group-replication-poll-spin-loops=value
名称
group_replication_poll_spin_loops变量范围
Global
动态变量
Yes
类型
默认值
最小值
允许值 (32位平台)
最大值
integer
0
0
4294967295
integer
0
0
类型
默认值
最小值
允许值 (64位平台)
最大值
18446744
•
•
在组通信线程等待传入更多的网络信息之前，等待mutex被释放的次数。
group_replication_recovery_retry_count
引入
系统变量
5.7.17
命令行格式
--group-replication-recovery-retry-count=value
名称
group_replication_recovery_retry_count变量范围
Global
动态变量
Yes
类型
默认值
最小值
最大值
10
0
商东京允许值
•
•
据数
-
城integer
31536000
部术技库要加入的成员尝试连接到可用数据源节点的次数。
group_replication_recovery_reconnect_interval
引入
5.7.17
命令行格式
--group-replication-recovery-reconnect-interval=value
系统变量 名称
group_replication_recovery_reconnect_interval变量范围
Global
动态变量
Yes
类型
默认值
最小值
允许值
•
•
integer
60
0
0
最大值
在组中找不到数据源节点时，重新尝试连接的时间间隔（以秒为单位）。
group_replication_recovery_use_ssl
引入
5.7.17
45
版权声明：本文标题：MySQL Group Replication(简称MGR)官方文档中文版 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/free/1702964900h437656.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论