18章组复制
前一个下一个

18章组复制

目录

18.1组复制背景
18.1.1复制技术
情势和组复制使用案例
18.1.3组复制的细节
18.2入门
18.2.1部署在单个主模式组复制
18.3监测组复制
18.3.1 replication_group_member_stats
18.3.2 replication_group_members
18.3.3复制“连接”状态
18.3.4 replication_applier_status
18.3.5组复制服务器状态
18.4组的复制操作
18.4.1部署在多发或单个主模式
18.4.2调整恢复
18.4.3网络划分
18.4.4使用MySQL企业备份与复制组
18.5组复制安全
18.5.1 IP地址白名单
18.5.2安全套接字层（SSL）的支持
18.5.3虚拟专用网络（VPN）
18.6组复制系统变量
18.7要求和限制
18.7.1组复制的要求
18.7.2集团复制限制
18.8交叉询问问题
18.9组复制的技术细节
18.9.1组复制插件体系结构
18.9.2组
18.9.3数据处理。
18.9.4数据定义语句
为18.95分布式恢复
18.9.6可观测性
18.9.7组复制性能

本章介绍了MySQL组复制和如何安装，配置和监控组。MySQL组复制一个MySQL服务器插件，允许你创建弹性、高可用性、容错复制拓扑。

组可以在一个单一的初级模式自动预选操作，其中只有一个服务器接收更新一次。另外，对于更高级的用户组可以部署在多主模式，其中所有服务器可以接受更新，即使他们同时发出的。

有一个内置的组成员服务，保持一致的组可以在任何给定的时间点，所有服务器视图。服务器可以加入和离开组和视图更新。有时服务器可以离开组意外的是，在这种情况下的故障检测机制检测到这个通知小组的观点已经改变。这是全自动的。

本章的结构如下：

18.1组复制背景

18.1.1复制技术
情势和组复制使用案例
18.1.3组复制的细节

这部分提供了MySQL组复制的背景信息。

创建一个容错系统采用组件冗余最常见的方式，换句话说，组件可以被删除，系统应继续运行如预期。这创造了一系列挑战，提高系统的复杂性，一个完全不同的水平。具体而言，复制的数据库必须面对的事实是，他们需要的不只是一个几台服务器的维护和管理。此外，由于服务器合作共同打造集团其他几个经典的分布式系统的问题要处理，如网络分区或脑裂的情况。

因此，最终的挑战是将逻辑的数据库的数据复制与逻辑有几个服务器在一个一致的和简单的方式协调。换句话说，有多个服务器同意对系统状态和对每一个变化，系统通过数据。这可以概括为具有服务器达到每个数据库状态的协议，所以他们所有的进步作为一个数据库或者他们最终收敛到相同的状态。这意味着他们需要作为一个（分布式）状态机。

MySQL服务器之间的复制提供了一组强协调分布式状态机复制。服务器协调自己自动当他们同组的一部分。集团可以在一个单一的初级模式自动预选操作，其中只有一个服务器接收更新一次。另外，对于更高级的用户组可以部署在多主模式，其中所有服务器可以接受更新，即使他们同时发出的。这种权力是有工作在这些部署的限制应用程序的费用。

有一个内置的组成员服务，保持一致的组可以在任何给定的时间点，所有服务器视图。服务器可以加入和离开组和视图更新。有时服务器可以离开组意外的是，在这种情况下的故障检测机制检测到这个通知小组的观点已经改变。这是全自动的。

一个事务提交，该小组的大部分已经在全球交易序列的一个给定的交易秩序的认同。决定提交或中止事务是由每个单独的服务器，而服务器作出同样的决定。如果有一个网络分区，导致分裂，成员无法达成一致，则系统不进步，直到这个问题解决。因此也有一个内置的自动分割脑保护机制。

所有的这一切都是由提供动力组通信系统（GCS）协议。这提供了一个故障检测机制，一个组的成员服务，安全和完全有序的消息传递。所有这些特性的关键是建立一个系统，以确保数据始终复制整个服务器组。在这项技术的核心在于对Paxos算法的实现。它作为组通信引擎。

18.1.1复制技术

18.1.1.1级复制
18.1.1.2组复制

在进入MySQL组复制的细节，本节介绍一些背景的概念和事物如何工作的概述。这有助于理解什么是集团的复制需要什么差异是典型的异步MySQL复制和组之间的复制提供了一些背景。

18.1.1.1级复制

传统的MySQL复制提供了一个简单的主次的方法来复制。有一个主（Master）和有一个或多个次级（奴隶）。主要执行交易，犯罪的人，然后他们后来（因此异步）发送到二是重新执行（在基于语句的复制）或应用（在基于行的复制）。这是一个共享的系统，其中所有服务器的默认数据的完整副本。

图18.1 MySQL异步复制

A transaction received by the master is executed, written to the binary log, then committed, and a response is sent to the client application. The record from the binary log is sent to the relay logs on Slave 1 and Slave 2 before the commit takes place on the master. On each of the slaves, the transaction is applied, written to the slave's binary log, and committed. The commit on the master and the commits on the slaves are all independent and asynchronous.

还有半同步复制，它的协议增加了一个同步步骤。这意味着原发性等，在提交时，第二承认它收到交易。然后才是主要的简历提交操作。

图18.2 MySQL半同步复制

A transaction received by the master is executed and written to the binary log. The record from the binary log is sent to the relay logs on Slave 1 and Slave 2. The master then waits for an acknowledgement from the slaves. When both of the slaves have returned the acknowledgement, the master commits the transaction, and a response is sent to the client application. After each slave has returned its acknowlegement, it applies the transaction, writes it to the binary log, and commits it. The commit on the master depends on the acknowledgement from the slaves, but the commits on the slaves are independent from each other and from the commit on the master.

在上面的两幅照片中，你可以看到一个图的经典异步MySQL复制协议（及其半同步变为好）。斜箭头表示服务器或邮件服务器和客户端应用程序之间交换之间交换的消息。

18.1.1.2组复制

复制是一组可以用于实现容错系统技术。复制组是一组互相交流，通过消息传递服务器。通信层提供了一套保证如原子信息和总订单的消息传递。这些都是非常强大的特性，转化为非常有用的抽象，可以采取建立更先进的数据库复制方案。

MySQL复制组的基础上，这些属性和抽象和实现多主机更新无处不在的复制协议。在本质上，一个复制组由多个服务器组成，每个组中的服务器可以执行交易的独立。但所有的读写（RW）事务提交后才被集团批准。只读（RO）交易不需要协调集团内，因此立即提交。换句话说，任何RW交易集团需要决定是否提交或不提交操作，因此不从源服务器单方面的决定。准确地说，当一个事务准备提交在原始服务器，服务器自动广播写值（行改变）和记者写集（即被更新的行的唯一标识符）。然后，建立了全球总交易。最终，这意味着所有服务器接收在同一顺序相同的一组交易。作为一个结果，所有的服务器将在同一顺序的变化一样，因此他们保持一致，组内。

然而，有可能是并发执行的事务之间的冲突在不同的服务器上。这种冲突是通过检查写两个并发事务集检测，这一过程被称为认证。如果两个并发事务，这在不同的服务器上执行，更新相同的行，然后有冲突。决议程序规定，交易被命令首先提交的所有服务器上，而交易的有序二中止，从而击退发起服务器和下降组中的其他服务器。这实际上是一个分布式的第一把赢的规则。

图18.3 MySQL组复制协议

A transaction received by Master 1 is executed. Master 1 then sends a message to the replication group, consisting of itself, Master 2, and Master 3. When all three members have reached consensus, they certify the transaction. Master 1 then writes the transaction to its binary log, commits it, and sends a response to the client application. Masters 2 and 3 write the transaction to their relay logs, then apply it, write it to the binary log, and commit it.

最后，集团的复制是一个共享的复制方案，每个服务器有自己的完整的数据副本。

上图描述了MySQL组复制协议并通过MySQL的复制（或MySQL半同步复制）你会看到一些不同。值得注意的是，一些基本的共识和Paxos相关消息丢失这张照片为清晰起见。

情势和组复制使用案例

18.1.2.1使用短链氯化碳的检验

组复制使您通过复制系统的状态在一组服务器中创建冗余容错系统。因此，即使某些服务器失败，只要它不是全部或大部分，系统仍然是可用的，和它可以降解性能和可伸缩性，它仍然是可用的。服务器故障隔离和独立。他们是由一组成员的服务依赖于一个分布式的故障检测器，能够信号时，任何服务器离开组跟踪，无论是自愿或因意外停止。这是一个分布式的恢复过程来确保当服务器加入他们长大的自动日期组。不需要服务器失败，和多主机更新无处不在的性质确保即使更新都在一个单一的服务器故障事件受阻。因此，MySQL组复制保证持续可用的数据库服务。

它需要理解的是，虽然数据库服务是重要的，在服务器崩溃的情况下，这些客户端连接必须重定向，或失败过，到不同的服务器。这不是一组复制的尝试解决。一个连接器，负载平衡器，路由器，或某种形式的中间件更适合处理这个问题。

综上所述，MySQL组复制提供了高可用、高弹性、可靠的MySQL服务。

18.1.2.1使用短链氯化碳的检验

下面的例子是组复制的典型应用案例。

  • 弹性复制环境需要非常流畅的复制架构，在服务器的数量增长或收缩的动态和尽可能少的副作用。例如，对于云数据库服务。

  • 高度可用的碎片Sharding是一个流行的方法写出来实现规模。使用MySQL复制来实现高可用性组的碎片，每个碎片都映射到一个复制组。

  • 替代主从复制在某些情况下，使用一个主服务器是一个单点的竞争。写一个组可能在某些情况下，更多的可扩展性。

  • 自治系统技术另外，您可以部署MySQL组复制的纯粹的自动化是建立在复制协议（这和前面的章节已经介绍了）。

18.1.3组复制的细节

18.1.3.1失效检测
18.1.3.2组成员
18.1.3.3容错

本节介绍一些有关这组复制建立在服务细节。

18.1.3.1失效检测

有一个故障检测机制，能够发现和报告服务器是沉默，这样的假定是死的。在一个较高的水平，故障检测器是一个分布式的服务，提供关于服务器可能死了的信息（怀疑）。以后如果组同意，怀疑可能是真的，然后小组决定给定的服务器确实失败了。这意味着在集团其余成员采取协调决策要排除某一成员。

怀疑是由于服务器去静音。当服务器不接收从服务器B信息在一定时期内，发生超时和怀疑了。

如果服务器收到从该组的其余部分分离，然后怀疑，所有的人都没有。无法安全协议的组（如不安全的一个群体），它的怀疑没有后果。当服务器以这种方式从集团分离，无法执行任何地方交易。

18.1.3.2组成员

MySQL组复制依赖于一个团体会员服务。这是内置的插件。它定义了服务器在线参与组。网络服务器列表通常被称为意见。因此，该组中的每个服务器有一个一致的看法是成员积极参与集团在某一时刻。

服务器已经同意不仅在事务提交，而且这是目前的观点。因此，如果服务器同意一个新的服务器成为该集团的一部分，那么该集团自身的重新整合，服务器，引发观念的转变。也恰好相反，如果一个服务器叶片组，自愿或不自愿，然后将其配置和动态组视图的变化是引发。

需要注意的是，当一个成员离开是自愿的，它第一次启动动态组的重构。这触发了一个程序，所有的成员都同意对新观点没有离开服务器。然而，如果一个成员离开不由自主地（例如意外停止或网络连接断开）则故障检测机制实现这一事实，提出了一种重构的集团，这一个没有失败的成员。如上所述，这需要从群组中的大多数服务器协议。如果小组无法达成协议（例如它划分在这样一种方式，没有多数在线服务器），然后系统不能够动态地更改配置，以防止脑裂情况块。最终，这意味着管理员需要加强和解决这。

18.1.3.3容错

MySQL组复制建立实施的Paxos分布式算法提供服务器之间的分布式协调。因此，它需要一个大多数服务器主动将达到法定人数，从而做出决定。这直接影响了一些故障系统可以容忍不妥协的本身和它的整体功能。服务器的数量（N）需要容忍f失败是那么n = 2 x f + 1

在实践中，这意味着容忍一个失败的小组必须在3服务器。如果一台服务器故障等，还有两服务器形成多数（三个）和允许系统继续自动进步做出决定。然而，如果一个服务器失败身不由己，然后小组（左一块服务器），因为没有多数作出决定。

下面是一个小桌子，上面的公式说明。

组的大小

大多数

即时故障容忍

一

一

零

二

二

零

三

二

一

四

三

一

五

三

二

六

四

二

七

四

三

第二章组复制技术方面。

18.2入门

18.2.1部署在单个主模式组复制

MySQL组复制提供一个插件的MySQL服务器，并在一个组中的每个服务器需要配置和插件的安装。本节提供了一个详细的教程，需要至少三台服务器创建一个复制组的步骤。

18.2.1部署在单个主模式组复制

18.2.1.1部署实例组复制
18.2.1.2配置组复制实例
18.2.1.3用户凭据
18.2.1.4发射组复制
18.2.1.5添加实例组

每个组中的服务器实例可以运行在一个独立的物理机，或在同一台机器。本节说明如何创建三个MySQL服务器实例在一台物理机复制组。这意味着三的数据目录是必要的，每一个服务器实例，并需要配置每个实例独立。

图18.4组建筑

Three server instances, S1, S2, and S3, are deployed as an interconnected group, and clients communicate with each of the server instances.

本教程介绍了如何获取和部署组复制插件的MySQL服务器，如何在创建一组配置每个服务器实例，以及如何使用性能模式监测，确认一切工作正常。

18.2.1.1部署实例组复制

第一步是配置MySQL服务器实例三。组的复制是一个内置的MySQL插件提供的MySQL服务器5.7.17后来。基于MySQL的插件的更多背景信息，看第六，MySQL服务器插件”。此过程假定MySQL服务器被下载并解压到目录命名mysql-8.0。下面的过程使用一个物理机，因此每个MySQL服务器实例需要该实例的一个特定的数据目录。在一个目录下创建数据目录数据每一个和初始化

mkdir data
mysql-8.0/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-8.0 --datadir=$PWD/data/s1
mysql-8.0/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-8.0 --datadir=$PWD/data/s2
mysql-8.0/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-8.0 --datadir=$PWD/data/s3

里面data/s1，日期/ S2，data/s3是一个初始化的数据目录，包含MySQL数据库和相关表和更多。要了解更多关于初始化程序，看部分2.9.1.1，“初始化使用mysqld”手动数据目录

警告

不要使用--initialize-insecure在生产环境中，只有以简化教程。在安全设置的更多信息，参见18.5节，“组复制安全”

18.2.1.2配置组复制实例

本节说明了要使用MySQL服务器实例组复制所需的配置设置。背景信息，看第18.7.2”组，复制限制”

组复制服务器设置

安装和使用组复制插件必须正确配置MySQL服务器实例。建议存储配置的实例的配置文件。看到第4.2.6、“使用选项文件”更多信息。除非另有说明，以下是该组中的第一个实例的配置，简称S1在这一过程中。下面显示了一个示例服务器配置。

[mysqld]

# server configuration
datadir=<full_path_to_data>/data/s1
basedir=<full_path_to_bin>/mysql-8.0/

port=24801
socket=<full_path_to_sock_dir>/s1.sock

这些设置配置MySQL服务器使用的数据目录之前创建和端口服务器应该打开并开始侦听传入的连接。

笔记

24801非默认端口的使用是因为本教程中的三个服务器实例使用相同的主机名。在安装有三台不同的机器，这将不需要。

组复制取决于成员之间的网络连接，这意味着每个成员必须能够解决所有的其他成员的网络地址。例如，在本教程中所有三个实例运行在同一机器，所以确保成员可以彼此接触，你可以添加一行的选项文件等report_host=127.0.0.1

复制框架

以下设置配置复制根据MySQL组复制的要求。

server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

这些设置配置服务器使用的唯一标识号码1，使全局事务标识符，只允许陈述，可以安全地登录使用gtid执行，并禁用写写入二进制日志事件校验。

如果你正在使用一个版本的MySQL比8.0.3，在缺陷进行改进的复制，你需要把这些线成员的选项文件。

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

这些设置指示服务器开启二进制日志格式，通过使用列存储复制元数据在系统表而不是文件和禁用二进制日志事件校验。更多细节参见第18.7.1，“组复制的要求”

组复制设置

在这一点上my.cnf文件确保服务器配置和指定实例化复制基础设施在一个给定的配置。以下部分配置复制设置为服务器组。

transaction_write_set_extraction=XXHASH64loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"loose-group_replication_start_on_boot=offloose-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
笔记

这个loose-用于前缀群组复制上述变量指示服务器继续如果组复制插件没有在服务器启动加载的启动时间。

  • 配置transaction_write_set_extraction指示服务器为每个交易已收集写集并将其编码为哈希散列算法使用xxhash64。从MySQL 8.0.2，这个设置是默认的，所以这条线可以省略。

  • 配置group_replication_group_name告诉插件，它是连接，或创建组，命名为“aaaaaaaa -aaaa-aaaa-aaaa- aaaaaaaaaaaa”。

    价值group_replication_group_name必须是一个有效的UUID。这个UUID是内部使用设置在二进制日志组复制事件gtids时。使用选择uuid()生成一个UUID

  • 配置group_replication_start_on_boot指示插件无法启动操作自动服务器启动时。这很重要，在设置组的复制是保证你能在手动启动插件配置服务器。一旦成员配置可以设置group_replication_start_on_boot在那组复制在服务器开机自动启动。

  • 配置group_replication_local_address告诉插件使用网络地址127.0.0.1，端口24901与小组其他成员的内部沟通。

    重要

    组复制使用这个地址的内部成员连接使用XCOM。这个地址必须使用SQL的主机名和端口不同，它不能用于客户端应用程序。它必须被保留为集团成员之间的内部通信，运行组复制。

    配置网络地址group_replication_local_address必须在所有组成员可分辨。例如，如果每个服务器实例上的一个固定的网络地址，你可以使用本机的IP不同的机器，如10.0.0.1。如果你使用的主机名，那么你必须使用完全限定的名称和确保它是可通过DNS配置正确/etc/hosts文件，或其他名称解析过程。推荐使用的端口group_replication_local_address是33061。在本教程中，我们使用了三个服务器实例在一台机器上运行，因此端口24901到24903用于内部通信网络地址。

  • 配置group_replication_group_seeds设置主机名，这是由新成员用来建立集团的成员端口连接。这些成员称为种子的成员。一旦建立连接，组成员身份信息列在performance_schema.replication_group_members。通常group_replication_group_seeds列表包含港每个团体成员group_replication_local_address，但这不是强制的，一个子集的组成员可以作为种子。

    重要

    这个hostname:port上市group_replication_group_seeds是种子成员的内部网络地址配置group_replication_local_address而不是SQL港用于客户端的连接，并显示为例performance_schema.replication_group_members表

    服务器启动组不使用此选项，因为它是最初的服务器，因此，它在引导组负责。换句话说，任何现有的数据服务器上的引导组是作为下一个加入会员的资料。第二服务器连接请求，只有在组成员的加入，任何丢失的数据在第二服务器从引导成员的捐赠数据复制，然后组扩展。第三服务器连接可以向其中任何两个加入，数据同步到新的成员，然后小组再度膨胀。随后服务器重复此过程，当加入。

    警告

    当连接多个服务器在同一时间，确保他们点种子，已经在集团成员。不要使用也加入本集团作为种子的成员，因为他们可能尚未在集团接触时。

    这是很好的做法，开始引导员，并让它创建组。然后让它的成员，其他成员加入种子。这将确保有形成时，加入剩下的成员组。

    创建一个组并加入多个成员同时不支持。它可以工作，但机会是操作比赛然后加入集团的行为结束在错误或超时。

  • 配置group_replication_bootstrap_group指示插件是否引导组或不。

    重要

    此选项只能在任何时间在一个服务器实例使用，通常你第一次引导组（或以整个组被带倒，又回来了）。如果你引导组多次，例如在多个服务器实例都设置了此选项，则可以创建一个人工脑裂的情况下，在这两个不同的组具有相同名称的存在。后的第一个服务器实例联机时禁用此选项。

该组中的所有服务器的配置是非常相似的。你需要改变一下每个服务器的细节（例如server_id，datadir，group_replication_local_address）。这说明在本教程的后面。

18.2.1.3用户凭据

组复制使用异步复制协议的实现部分为18.95，“分布式恢复”同步组的成员，在加入他们的团体。分布式恢复过程依赖于复制通道命名group_replication_recovery这是用来交易从供体转移到成员的成员加入组。因此，你需要建立一个复制的用户具有正确的权限，可以建立直接复制组成员恢复复制通道。

使用选项文件启动服务器：

mysql-8.0/bin/mysqld --defaults-file=data/s1/s1.cnf

与创建一个MySQL的用户REPLICATION-SLAVE特权。这个过程可以在二进制日志，然后你可以依靠分布式恢复复制用于创建用户语句捕获。另外，你可以禁用二进制日志并创建用户手动在每个成员，例如，如果你想避免的变化被传播到其他服务器实例。禁用二进制日志，连接服务器S1并发出以下声明：

MySQL的&#62;SET SQL_LOG_BIN=0;

在下面的示例中的用户rpl_user与密码password显示。当配置你的服务器使用一个合适的用户名称和密码。

MySQL的&#62;CREATE USER rpl_user@'%' IDENTIFIED BY 'password';MySQL的&#62;GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';MySQL的&#62;FLUSH PRIVILEGES;

如果二进制日志被禁用，使它再次用户已创建。

mysql> SET SQL_LOG_BIN=1;

一旦用户已配置，使用CHANGE MASTER TO语句将服务器配置为使用提供的凭据的group_replication_recovery复制通道下次需要另一成员恢复状态。以下问题，更换rpl_user和password在创建用户时使用的值。

MySQL的&#62;CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
		      FOR CHANNEL 'group_replication_recovery';

分布式恢复的服务器加入组和不具有相同的一组交易为集团成员迈出第一步。如果这些凭据不正确设置为group_replication_recovery复制通道和多用户_如图所示，服务器无法连接到供成员和运行分布式恢复过程中与其他小组成员获得的同步，因此最终无法加入该组。

同样，如果服务器不能正确识别其他成员通过服务器的hostname恢复过程失败。建议使用MySQL的操作系统已正确配置的独特主机名，或者使用DNS或本地设置。这hostname可验证的member_host列的performance_schema.replication_group_members表如果多个组的成员将默认主机名由操作系统设置，有没有解决的正确地址和成员不能参加的小组成员。在这种情况下使用report_host配置一个独特的主机名被外部的服务器

使用组的复制和缓存SHA-2的用户凭据的插件

默认情况下，MySQL 8使用创建的用户第6.5.1.3，“缓存SHA-2认证”。如果rpl_user你配置的分布式恢复使用缓存SHA-2认证插件，你不使用第18.5.2，安全套接字层（SSL）的支持”对于group_replication_recovery复制通道，RSA密钥对用于密码交换，看第6.4.3，“创建SSL和RSA证书和密钥”。你可以复制的公钥rpl_user的成员，应该从组恢复其状态，或配置捐赠者要求时提供公钥。

更安全的方法是复制的公钥rpl_user的成员，应该从捐赠者恢复组状态。然后你需要配置group_replication_recovery_public_key_path在成员加入群组路径的公共密钥的系统变量多用户_

或者，一个不太安全的方法是设置group_replication_recovery_get_public_key=ON在donors如此，他们提供公共英语的关键多用户_当他们加入集团的成员。有没有办法验证服务器的身份，因此只设置group_replication_recovery_get_public_key=ON当你确定没有服务器的身份被泄露的风险，例如通过中间人攻击。

18.2.1.4发射组复制

一旦服务器S1已配置和启动，安装组复制插件。连接到服务器并发出以下命令：

INSTALL PLUGIN group_replication SONAME 'group_replication.so';
重要

这个mysql.session用户必须在你可以加载组复制的存在。mysql.session在MySQL版本8.0.2添加。如果你的数据字典初始化是使用早期版本必须运行mysql_upgrade程序。如果升级没有运行，集团开始复制失败的错误信息有一个错误，当试图访问用户的服务器会话@本地MySQL。确保用户在服务器和服务器更新后mysql_upgrade是跑。

检查插件安装成功，问题SHOW PLUGINS;检查输出。它应该表现出这样的东西：

MySQL的&#62;SHOW PLUGINS;---------------------------- ---------- -------------------- ---------------------- ------------- |名字|状态|型|图书馆|许可| ---------------------------- ---------- -------------------- ---------------------- ------------- | binlog |主动|存储引擎|空|专有|（…）| group_replication |主动|组复制| group_replication.so |专有| ---------------------------- ---------- -------------------- ---------------------- -------------

启动组，指示服务器S1引导组，然后开始组复制。这个引导程序只能由一台服务器完成，一开始只有一组。这就是为什么启动配置选项的值没有被保存在配置文件中。如果它被保存在配置文件中，在重新启动服务器自动启动一个具有相同名称的第二组。这将导致截然不同的两组具有相同名称的。同样的道理也适用于停止与此选项设置为插件启动ON

SET GLOBAL group_replication_bootstrap_group=ON;START GROUP_REPLICATION;SET GLOBAL group_replication_bootstrap_group=OFF;

一旦START GROUP_REPLICATION语句返回，集团已开始。你可以检查，现在创建的组，它有一个成员：

MySQL的&#62;SELECT * FROM performance_schema.replication_group_members;--------------------------- -------------------------------------- ------------- ------------- --------------- | channel_name | member_id | member_host | member_port | member_state | --------------------------- -------------------------------------- ------------- ------------- --------------- | group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | Myhost | 24801 |在线| --------------------------- -------------------------------------- ------------- ------------- ---------------

本表信息确认的唯一标识符的组有一个成员ce9be252-2b71-11e6-b8f4-00212844f856，它是在线而在myhost在此端口上监听客户端的连接二万四千八百零一

为证明确实是在一组服务器的目的，它是能够处理负载，创建表并添加一些内容。

mysql> CREATE DATABASE test;
mysql> USE test;
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
mysql> INSERT INTO t1 VALUES (1, 'Luis');

检查表的内容t1和二进制日志

MySQL的&#62;SELECT * FROM t1;两| C1 - C2 | | -两| 1 |路易斯-两| MySQL &#62;SHOW BINLOG EVENTS;+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+| Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                                               |+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+| binlog.000001 |   4 | Format_desc    |         1 |         123 | Server ver: 8.0.2-gr080-log, Binlog ver: 4                        || binlog.000001 | 123 | Previous_gtids |         1 |         150 |                                                                    || binlog.000001 | 150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  || binlog.000001 | 211 | Query          |         1 |         270 | BEGIN                                                              || binlog.000001 | 270 | View_change    |         1 |         369 | view_id=14724817264259180:1                                        || binlog.000001 | 369 | Query          |         1 |         434 | COMMIT                                                             || binlog.000001 | 434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  || binlog.000001 | 495 | Query          |         1 |         585 | CREATE DATABASE test                                               || binlog.000001 | 585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_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 @@SESSION.GTID_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 */                                                |+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

如上所述，数据库和表对象的创建及其相应的DDL语句写入二进制日志。另外，数据插入表和写入二进制日志。的二进制日志条目重要性说明在下面的部分，当集团发展和分布式恢复的新成员试图赶上并成为在线执行。

18.2.1.5添加实例组

在这一点上，该集团已在一个成员服务器，S1，在它里面有一些数据。现在是时候加入其他两服务器配置之前扩大组。

18.2.1.5.1添加的第二个实例

为了增加一个实例，服务器S2，首先为其创建配置文件。配置是一个类似于用于服务器S1，除了诸如数据目录的位置，港口，S2要听或其server_id。这些不同的线都在下面的列表显示。

[mysqld]# server configurationdatadir=<full_path_to_data>/data/s2basedir=<full_path_to_bin>/mysql-8.0/port=24802socket=<full_path_to_sock_dir>/s2.sock## Replication configuration parameters#server_id=2gtid_mode=ONenforce_gtid_consistency=ONbinlog_checksum=NONE## Group Replication configuration#loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"loose-group_replication_start_on_boot=offloose-group_replication_local_address= "127.0.0.1:24902"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

类似的程序服务器S1，与选项文件在你启动服务器。

mysql-8.0/bin/mysqld --defaults-file=data/s2/s2.cnf

然后配置恢复证书如下。命令是一样的用在设置服务器S1为用户组内共享。发出以下语句S2。

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
	FOR CHANNEL 'group_replication_recovery';
小贴士

如果您使用的是缓存SHA-2认证插件，在MySQL 8默认，看使用组的复制和缓存SHA-2的用户凭据的插件

安装组复制插件并开始加入服务器组的过程。下面的示例安装插件以同样的方式在部署服务器S1。

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';

添加服务器S2组

mysql> START GROUP_REPLICATION;

不同于以往的步骤，为那些执行S1一样，这里是你的差异不问题SET GLOBAL group_replication_bootstrap_group=ON;出发前组复制，因为集团已经建立，让服务器S1。在这一点上服务器S2只需要被添加到已有的组。

小贴士

当组复制成功启动与服务器的连接组检查super_read_only变量。通过建立super_read_only对成员的配置文件，您可以确保服务器失败时，开始以任何理由组复制不接受交易。如果服务器应该加入组读写实例，比如在一个单一的初级群体或作为一个多发组成员主要的，当super_read_only变量设置为它设置为关闭入组。

检查performance_schema.replication_group_members表再次表明，现在有两在线组中的服务器

mysql> SELECT * FROM performance_schema.replication_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        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

作为服务器S2也标记为在线，它必须已经赶上服务器S1自动。确认它确实与服务器S1同步如下。

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+

mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+

mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         2 |         123 | Server ver: 8.0.3-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         2 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_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 @@SESSION.GTID_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 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

如上所述，第二服务器已被添加到组和已复制从服务器S1自动变化。根据分布式恢复过程，这意味着在加入本集团之前，立即宣布在线，服务器自动连接到服务器S1 S2有了丢失的数据从。换句话说，它复制交易从S1的二进制日志，它失踪了，到时间点，加入组。

18.2.1.5.2添加额外的实例

添加额外的实例组基本相同的序列步骤添加第二服务器，除了配置已经改变了对服务器S2。总结所需的命令：

1.。创建配置文件

[mysqld]

# server configuration
datadir=<full_path_to_data>/data/s3
basedir=<full_path_to_bin>/mysql-8.0/

port=24803
socket=<full_path_to_sock_dir>/s3.sock

#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

#
# Group Replication configuration
#
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:24903"
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

2。启动服务器

mysql-8.0/bin/mysqld --defaults-file=data/s3/s3.cnf

三.配置的group_replication_recovery通道恢复证书。

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password'  \\
FOR CHANNEL 'group_replication_recovery';

4。安装组复制插件启动它。

INSTALL PLUGIN group_replication SONAME 'group_replication.so';
START GROUP_REPLICATION;

在这一点上服务器S3是启动和运行，加入了这个团体，赶上了组中的其他服务器。咨询performance_schema.replication_group_members表再次印证了这种情况。

MySQL &#62;选择*从performance_schema.replication_group_members；--------------------------- -------------------------------------- ------------- ------------- --------------- | channel_name | member_id | member_host | member_port | member_state | --------------------------- -------------------------------------- ------------- ------------- --------------- | group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | Myhost | 24801 |在线| | group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | Myhost | 24803 |在线| | group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | Myhost | 24802 |在线| --------------------------- -------------------------------------- ------------- ------------- ---------------

发行这一查询服务器或服务器S1 S2产生相同的结果。此外，您可以验证服务器S3也赶上了：

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+

mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+

mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         3 |         123 | Server ver: 8.0.3-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         3 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_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 @@SESSION.GTID_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=29 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
| binlog.000001 | 1326 | Gtid           |         1 |        1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6'  |
| binlog.000001 | 1387 | Query          |         1 |        1446 | BEGIN                                                              |
| binlog.000001 | 1446 | View_change    |         1 |        1585 | view_id=14724832985483517:3                                        |
| binlog.000001 | 1585 | Query          |         1 |        1650 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

18.3监测组复制

18.3.1 replication_group_member_stats
18.3.2 replication_group_members
18.3.3复制“连接”状态
18.3.4 replication_applier_status
18.3.5组复制服务器状态

使用性能模式表监测组复制，假设绩效模式启用。组复制增加了以下表格：

  • performance_schema.replication_group_member_stats

  • performance_schema.replication_group_members

这些行为模式复制表还显示复制信息组：

  • performance_schema.replication_connection_status

  • performance_schema.replication_applier_status

由集团复制插件创建的复制通道命名：

  • group_replication_recovery此通道用于为分布式恢复期相关的复制变化。

  • group_replication_applier此通道用于从该组输入变化。这是用来申请交易直接来自集团的渠道。

以下各节描述在这些表提供的信息。

18.3.1 replication_group_member_stats

在复制组中的每个成员提供适用于交易的组。对于认证机构和申请程序统计有助于了解施放队列越来越多，多少冲突被发现，有多少交易进行了检查，其中交易承诺无处不在，等等。

这个performance_schema.replication_group_member_stats表提供的认证过程相关的组级信息，并统计为交易收到的和起源于复制组中的每个成员。信息是所有服务器实例的复制组成员之间共享，因此对所有组成员信息可以查询任何成员。注意，远程成员统计刷新是由指定的消息周期控制group_replication_flow_control_period选项，那么这些可能略有不同，从当地收集统计会员在查询了。

表18.1 replication_group_member_stats

场

描述

channel_name

本集团的复制通道的名称。

view_id

这组标识符为当前视图。

member_id

成员服务器UUID。这一组中的每个成员不同的价值。这也是作为一个关键是每个成员独特。

count_transactions_in_queue

交易在排队待审的冲突检测检查次数。一旦交易被检查的冲突，如果他们通过检查，他们排队要应用以及。

count_transactions_checked

the number of conflicts for that have been checked交易。

检测到冲突_ _计数

交易没有通过冲突检测次数。

count_transactions_rows_validating

冲突的检测数据库的当前大小（对每个交易认证）。

transactions_committed_all_members

已成功提交的复制组的所有成员的交易。这是在一个固定的时间间隔更新。

last_conflict_free_transaction

标识符的最后冲突的自由交易的交易检查。

count_transactions_remote_in_applier_queue

交易，这名成员从复制组，等待应用接收数。

count_transactions_remote_applied

交易，这名成员从复制组已收到数。

count_transactions_local_proposed

交易会员是发送到复制组协调数。

count_transactions_local_rollback

交易，这个成员是被回滚发送到复制组经过数。


这些字段用于监测连接在组成员的绩效的重要。例如，假设一个组的成员是延迟和不能够跟上其他组的成员。在这种情况下，你可能会看到大量的队列中的交易。基于这些信息，你可以决定是删除成员从组，或延迟交易的处理以集团的其他成员减少排队的交易数量。这个信息也可以帮助你决定如何调整集团复制插件流量控制。

18.3.2 replication_group_members

此表用于监测不同服务器的情况下，在当前视图中跟踪的状态，或者说是群体的一部分，如由会员服务跟踪。信息是所有服务器实例的复制组成员之间共享，因此对所有组成员信息可以查询任何成员。

表2 replication_group_members

场

描述

channel_name

本集团的复制通道的名称。

member_id

成员服务器UUID。这一组中的每个成员不同的价值。这也是作为一个关键是每个成员独特。

member_host

该组成员的网络地址

member_port

MySQL连接的端口组成员听。

member_state

该组成员的当前状态（可ONLINE，误差，RECOVERING，离线或UNREACHABLE）

member_role

该小组成员的作用，无论是PRIMARY或二

member_version

群成员的MySQL版本。


有关更多信息Member_host价值和在分布式恢复过程的影响，见第18.2.1.3，“用户凭据”

18.3.3复制“连接”状态

当连接到一个组，此表中显示信息组复制某些领域。例如，交易已经从组和排队在施放队列（中继日志）。

Ttable 18.3 Relipped by connection to Status Status

场

描述

channel_name

本集团的复制通道的名称。

group_name

显示该组的名称的价值。它始终是一个有效的UUID。

_ UUID源

节目组标识符。这是类似的组名和它作为所有交易都在小组复制生成UUID。

service_state

节目组成员是否是或不是一个部分。服务状态的可能值可以是{，关闭连接}；

received_transaction_set

在这gtid集交易已收到由集团成员。


18.3.4 replication_applier_status

本集团与复制相关的渠道和线程的状态可以用普通replication_applier_status表以及观察。如果有许多不同的线程应用交易，那么工作表也可以用来监测每个工作者线程是做什么。

表18.4 replication_applier_status

场

描述

channel_name

本集团的复制通道的名称。

service_state

显示应用服务或关闭

remaining_delay

显示是否有施放延迟配置。

count_transactions_retries

在应用事务进行重试次数。

received_transaction_set

在这gtid集交易已收到由集团成员。


18.3.5组复制服务器状态

表replication_group_members是每当有一个观念的转变更新，例如当该组的配置是动态变化的。在这一点上，服务器交换他们的一些元数据同步自己继续合作。

有各种状态，服务器实例可以在。如果服务器正常通信，所有报告的所有服务器相同的状态。但是，如果有一个网络分区，或者服务器离开了团队，然后不同的信息可能被报道，这取决于服务器查询。注意，如果服务器已经离开公司，那显然不能报告更新的信息对其他服务器的状态。如果有一个分区，这样仲裁丢失，服务器不能协调自己。作为一个结果，他们猜不到不同服务器的状态是什么样的。因此，而不是猜测他们的状态，他们报告说，有些服务器不可达。

表18.5服务器状态

场

描述

组同步

在线

成员是准备作为一个全功能的组的成员，这意味着客户端可以连接并开始执行交易。

是

回收

成员在成为该小组成员的过程和目前正在经历的恢复过程，从供体接收状态信息。

否

离线

插件加载但不属于任何组的成员。

否

误差

该成员的状态。无论是在恢复期或在应用更改错误，服务器进入该状态。

否

遥不可及

当局部故障检测器的嫌疑，一个给定的服务器不可达的，因为也许它已经坠毁或被断开，身不由己，这表明服务器的状态为“遥不可及”。

否


重要

一旦一个实例进入ERROR的状态，super_read_only选项设置为打开（放）。离开ERROR你必须手动配置实例super_read_only=OFF

注意组复制不同步，但最终同步。更确切地说，交易是在同一顺序传递到所有组成员，但他们的执行是不同步的，这意味着事务后接受的是承诺，每个成员有自己的速度。

18.4组的复制操作

18.4.1部署在多发或单个主模式
18.4.2调整恢复
18.4.3网络划分
18.4.4使用MySQL企业备份与复制组

本节描述了不同的部署组复制模式，阐述了常用操作管理组，并提供有关如何调整你的组。。

18.4.1部署在多发或单个主模式

18.4.1.1单原模式
18.4.1.2多主模式
18.4.1.3找到原

组复制工作在以下不同的模式：

  • 单次模式

  • 多主模式

默认的模式是单原。它是不可能有团体成员部署在不同的模式，例如一个配置在多主模式，而另一个在单一的基本模式。模式之间切换，群而不是服务器，需要使用不同的操作配置重新启动。无论部署模式，组复制不处理客户端故障，必须由应用程序自己来处理，一个连接器或中间件框架，如代理服务器或路由器。

当部署在多主模式，报表进行检查以确保与模式兼容。以下检查是当组复制部署在多主模式：

  • 如果一个事务的可串行化隔离级别下执行，那么其提交失败时，同步本身与组。

  • 如果一个事务执行的表有外键级联约束，那么交易失败时同步提交本身的组。

这些检查可以通过设置选项关闭group_replication_enforce_update_everywhere_checks到错误的。当部署在单一的基本模式，这个选项必须被设置为FALSE

18.4.1.1单原模式

在这种模式下，集团有一个单一的主服务器，设置为读写模式。该集团中的其他成员都被设置为只读模式（与super-read-only=ON）。这是自动发生的。小学通常是引导组的第一个服务器，其他服务器加入自动学习主服务器被设置为只读。

图18.5新的初选

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. Server S1 is the primary. Write clients are communicating with server S1, and a read client is communicating with server S4. Server S1 then fails, breaking communication with the write clients. Server S2 then takes over as the new primary, and the write clients now communicate with server S2.

在单一的基本模式，有些检查部署在多主模式被禁用，因为系统强制执行，只有一个单一的服务器写入组。例如，级联外键表的变化是允许的，而在多主模式不。在主要构件的破坏，一个自动的初选机制选择新的主要成员。选举的过程看新观点进行排序，和潜在的新的初选基于价值group_replication_member_weight。假设该组成员都运行相同版本的MySQL操作，则会员的最高值group_replication_member_weight被选为新的主。如果在多个服务器有相同的group_replication_member_weight的服务器，然后根据他们的优先server_uuid在字典顺序从第一个。一旦一个新的主要是选举产生的，它是自动设置为读写及其他辅助保持次级，这样，只读。

如果是，运行不同版本的MySQL然后选举过程可以影响成员工作。例如，如果有人不支持group_replication_member_weight，然后选择主要是基于server_uuid从低版本为主要成员。另外，如果所有的成员运行不同版本不支持group_replication_member_weight主要是选择的基础上，group_replication_member_weight从较低版本的主要成员。

这是等待新的主前重新路由的客户端应用程序将其复制相关的中继日志的一个很好的实践。

18.4.1.2多主模式

在多主模式，是没有概念的一个主要。没有必要搞选举程序在玩什么特殊作用没有服务器。

图18.6客户端故障转移

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. All of the servers are primaries. Write clients are communicating with servers S1 and S2, and a read client is communicating with server S4. Server S1 then fails, breaking communication with its write client. This client reconnects to server S3.

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

18.4.1.3找到原

找出哪些服务器目前主要部署在单个主模式，使用MEMBER_ROLE列在performance_schema.replication_group_members表。例如：

sql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------------------+-------------+
| MEMBER_HOST             | MEMBER_ROLE |
+-------------------------+-------------+
| remote1.example.com     | PRIMARY     |
| remote2.example.com     | SECONDARY   |
| remote3.example.com     | SECONDARY   |
+-------------------------+-------------+
警告

这个group_replication_primary_member状态变量已经被弃用，预计将在未来的版本中删除。

交替使用group_replication_primary_member状态变量

MySQL的&#62;SHOW STATUS LIKE 'group_replication_primary_member'

18.4.2调整恢复

每当有新的成员加入一个复制组，它连接到一个合适的供体，取数据，它已经错过了直到它宣布在线。在这组复制的关键部件是容错和配置。以下部分解释了如何恢复工作和如何调整设置

供体的选择

一个随机的供体选择的是从集团现有的在线会员。这种方式有一个很好的机会，同样的服务器没有选择不止一次地在多个成员进组。

如果选择的供体未连接，新的连接会自动尝试一个新的候选供体。一旦连接重试限制达到恢复程序终止一个错误。

笔记

捐赠者是随机挑选，从在线成员列表中的当前视图。

增强的自动供切换

关注复苏的另一个主要的点作为一个整体，以确保它符合故障。因此，组复制提供了强大的错误检测机制。在早期版本的组复制，当达到了施主，恢复只能检测由于认证问题或其他一些问题连接错误。这样的问题情景的反应是切换到一个新的供体，因此一个新的连接尝试不同的成员。

这种行为扩展到其他故障的情况下也盖：

  • 清除数据方案如果选择的供体有清除数据，为恢复过程需要发生错误。恢复检测错误和一个新的供选择。

  • 重复数据如果一个服务器加入集团已经包含了一些数据，来自供体恢复然后选择错误时发生数据冲突。这可以通过一些错误的交易中加入群组服务器造成的。

    可以说，恢复失败而切换到另一个供体，但在异质群体有机会在其他成员共享冲突的事务和别人不一样。因此，在选择另一个错误，恢复供从组。

  • 其他错误如果任何恢复线程失败（接收机或施放线程失败）然后发生了一个错误，恢复切换到一个新的供体。

笔记

在一些持续性故障情况下的暂态故障恢复或自动重试连接到同一个或一个新的供体。

供体连接重试

恢复数据传输依赖于二进制日志和现有的MySQL复制框架，因此它可能是一些短暂的错误可能导致错误的接收器或施放螺纹。在这种情况下，供体的切换过程有重试功能，类似于常规的复制发现。

一些尝试

尝试一个服务器加入组当试图连接到从捐献者池供数10。这是通过配置的group_replication_recovery_retry_count插件变量。下面的命令集的尝试连接到供10个数的最大值。

MySQL的&#62;SET GLOBAL group_replication_recovery_retry_count= 10;

注意，这个占全球数量，尝试加入群组服务器连接到每一个合适的捐赠者。

睡眠习惯

这个group_replication_recovery_reconnect_interval插件变量定义了恢复过程应该睡多少时间供连接尝试之间。该变量默认设置为60秒，可以动态更改此值。以下命令将恢复供连接重试间隔120秒。

MySQL的&#62;SET GLOBAL group_replication_recovery_reconnect_interval= 120;

注意，然而，复苏并非每个供体连接尝试后的睡眠。作为加入本集团的服务器连接到不同的服务器和不一样的一遍又一遍，它可以假设影响服务器不影响服务器B这样的问题，恢复暂停只有当它经历了所有可能的捐助者。一旦加入组服务器尝试连接到的组和不完全是合适的捐赠者，恢复过程中睡觉的配置的秒数group_replication_recovery_reconnect_interval变量

18.4.3网络划分

集团需要达成共识时，需要复制发生变化。这是正常的交易情况也是组成员的变化和一些内部消息，保持群体一致性要求。共识需要大多数小组成员在一个给定的决定同意。当大多数小组成员丢失，本集团无法进步，因为它无法保证块多数或群体。

群体可能丢失，当有多个非自愿的失败，造成大多数服务器是突然从组中删除。例如，在一组5台服务器，如果3人成为沉默的一次，大多数是妥协，因此没有法定人数可达到。事实上，剩下的两个不能告诉如果其他3台服务器崩溃或者网络分区隔离这2个单独的组，因此无法自动重新。

另一方面，如果服务器退出组自愿，他们指导组应配置。在实践中，这意味着一个服务器，去告诉其他人这是走。这意味着，其他成员可以配置组正确，成员的一致性维护和重新计算的大多数。例如，在5台服务器，3马上离开上述情形，如果3离开服务器警告组，他们走了，一个接一个，然后会员能够自行调节从5到2，同时确保仲裁而发生的。

笔记

损失的群体本身就是一个坏计划的副作用。计划预期的失败次数的组的大小（无论他们是连续的，发生一次或是零星的）。

以下各节介绍如何在这样一种方式，没有法定的组中的服务器自动实现系统分区。

小贴士

主已经排除一组后大部分损失由重构可以包含额外的交易，不包括在新的组。如果发生这种情况，尝试重新添加排除成员的消息在一个错误的结果这件更具有执行的交易比在组。

检测分区

这个replication_group_members性能模式表给出了各个服务器的状态，在当前视图中从服务器的角度。该系统的运行不到分区的大部分时间，因此表显示是一致的所有服务器组中的信息。换句话说，每个服务器在这张桌子上的地位是同意所有在当前视图。然而，如果有网络分区和仲裁丢失，那么表显示状态遥不可及那些服务器无法联系。这个信息是由局部故障检测器内置组复制的出口。

图18.7失去仲裁

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group, which is a stable group. When three of the servers, S3, S4, and S5, fail, the majority is lost and the group can no longer proceed without intervention.

要理解这种类型的网络分区下面的部分描述了一个场景，那里有最初的5台服务器一起工作正常，以及变化，然后发生一次只有2组服务器在线。图中描绘的情景。

例如，让我们假设有一组服务器在这五：

  • 服务器S1与成员标识符199b2df7-4aaf-11e6-bb16-28b2bd168d07

  • 服务器S2成员标识符199bb88e-4aaf-11e6-babe-28b2bd168d07

  • 成员标识符服务器S31999b9fb-4aaf-11e6-bb54-28b2bd168d07

  • 成员标识符服务器S419ab72fc-4aaf-11e6-bb51-28b2bd168d07

  • 成员标识符服务器S519b33846-4aaf-11e6-ba81-28b2bd168d07

最初，集团运行良好，服务器是愉快地相互交流。你可以验证这个登录到S1，看它replication_group_members性能模式表。例如:

MySQL的&#62;SELECT * FROM performance_schema.replication_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 |在线| | group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1 | 13001 |在线| | group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1 | 13000 |在线| | group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1 | 13003 |在线| | group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1 | 13004 |在线| --------------------------- -------------------------------------- ------------- ------------- --------------

然而，片刻之后，有一个灾难性的失败和服务器S3、S4、S5意外停止。几秒钟之后，再看看replication_group_members表1表明，它仍然是在线的，但其他几个成员不。事实上，如下图所示，他们被标记为遥不可及。此外，系统无法配置更改会员，因为大多数人已经失去了。

mysql> SELECT * FROM performance_schema.replication_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  |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

该表显示，S1现在是一组无进展没有外部干预手段，因为大多数的服务器都是遥不可及的。在这种情况下，小组成员名单需要重置，让系统来进行，这是本节的解释。或者，你也可以选择停止组复制的S1和S2（或完全停止S1和S2和S3），找出发生了什么事，S4和S5然后重启组复制（或服务器）。

闭塞分区

使你重新组复制组成员名单通过强制一个特定的配置。例如，在上述的情况下，在S1和S2是唯一的在线服务器，你可以选择力会员配置只包括S1和S2。这就需要检查一些关于S1和S2的信息再利用group_replication_force_members变量

图18.8强迫一个新会员

Three of the servers in a group, S3, S4, and S5, have failed, so the majority is lost and the group can no longer proceed without intervention. With the intervention described in the following text, S1 and S2 are able to form a stable group by themselves.

假设你是回来在S1和S2组中唯一剩下的服务器情况。服务器S3、S4、S5已经离开集团意外。让服务器S1和S2的继续，你想让会员配置仅包含S1和S2。

警告

本程序采用group_replication_force_members最后度假村和should be事情考虑救济。EN必须小心使用，只为压倒一切的损失的群体。如果使用不当，它可以创建一个人工脑裂的情况或阻止整个系统共。

记得，系统堵塞和当前的配置如下（按S1局部故障检测器的感知）：

mysql> SELECT * FROM performance_schema.replication_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  |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

要做的第一件事是检查点的地址是什么（组通信标识符）S1和S2。登录到S1和S2和获得信息如下。

mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| 127.0.0.1:10000                   |
+-----------------------------------+

然后登录到S2和做同样的事情：

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";

这种疏导组迫使不同的配置。检查replication_group_members在S1和S2验证组成员身份更改之后。首先在S1。

MySQL的&#62;SELECT * FROM performance_schema.replication_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 |在线| | group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1 |吉林|在线| --------------------------- -------------------------------------- ------------- ------------- --------------

然后在S2

mysql> SELECT * FROM performance_schema.replication_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 | 127.0.0.1   |       13001 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

当强迫一个新会员的配置，确保所有服务器都将被迫离开集团确实停止了。在上面描述的场景，如果S3、S4和S5是不是真的遥不可及，而是在网上，他们可能已经形成了自己独特的功能分区（他们是3的5，因此他们大多数）。在这种情况下，迫使S1和S2组成员列表，可以创建一个人工脑裂情况。因此重要的是在强迫一个新会员配置确保被排除的服务器是关机，如果他们不是，他们关闭之前。

18.4.4使用MySQL企业备份与复制组

本节说明如何备份和随后恢复使用MySQL企业备份组复制成员；同样的技术可用于快速添加新成员的一组。一般来说，备份一组复制的成员不同的是没有备份一个独立的MySQL实例。建议的过程是使用MySQL企业备份映像备份和随后的恢复，更多信息见备份操作

所需的步骤可以概括为：

  • 使用MySQL企业备份创建一个备份时间戳与简单的源服务器实例。

  • 复制备份到目标服务器实例。

  • 使用MySQL企业备份恢复备份到目标服务器实例。

下面的程序演示了这一过程。考虑下面的组：

mysql> SELECT * member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| node1       |        3306 | ONLINE       |
| node2       |        3306 | ONLINE       |
| node3       |        3306 | ONLINE       |
+-------------+-------------+--------------+

在这个例子中，集团经营的单的基本模式和主要组成员node1。这意味着，NODE2和node3是次要的，在只读模式运行（super_read_only=ON）。使用MySQL企业备份，最近的备份了NODE2通过发放：

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

这个--no-history-logging选择是因为NODE2是次要的，因为它是只读的MySQL企业备份无法写入实例状态和元数据表。

假定初级会员，node1，遇到不可调和的腐败。一段时间的服务器实例正在重建但所有成员上的数据丢失后。会员最新的备份NODE2可以用来重建node1。这需要复制备份文件NODE2到node1然后使用MySQL企业备份恢复备份Node1。确切的方式你复制备份文件取决于操作系统和工具提供给你。在这个例子中我们假设Linux服务器和服务器之间使用SCP复制文件：

node2/backups # scp my.mbi_2206_1429 node1:/backups

连接到目标服务器，在这种情况下node1，采用MySQL企业备份通过发行恢复备份：

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企业备份恢复期和恢复期组复制。这取决于该组的访问客户，还有一种可能是DML在新加入的实例的时刻可在网络上执行，甚至应用二进制日志之前重新组。为了避免这种情况，配置成员的选项文件：

group_replication_start_on_boot=OFF
super_read_only=ON
event_scheduler=OFF

这确保了组复制未开始启动，该成员默认为只读，event_scheduler当成员赶上恢复期组关闭。适当的错误处理必须配置在客户承认他们，暂时阻止这期间执行DML。

启动服务器实例和连接SQL客户端。恢复备份旧的二进制日志文件和相关的元数据，这是特定于实例的备份。重置所有的问题：

mysql> RESET MASTER;

恢复备份的源实例关联的中继日志文件，在这种情况下node2。因此重置日志的元数据，并通过发行的所有复制通道的配置：

MySQL的&#62;RESET SLAVE ALL;

为恢复实例能够恢复使用组复制的内置分布式恢复自动（见部分为18.95，“分布式恢复”), configure thegtid_executed变量。MySQL企业备份的备份NODE2包括backup_gtid_executed.sql文件，通常在路径datadir目标/ /，其中包含所需的配置信息Node1。禁用二进制日志，然后使用这个文件来配置gtid_executed发行：可变的城市

MySQL的&#62;SET SQL_LOG_BIN=OFF;MySQL的&#62;SOURCE datadir/meta/backup_gtid_executed.sqlMySQL的&#62;SET SQL_LOG_BIN=ON;

配置第18.2.1.3，“用户凭据”开始组复制，例如：

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的&#62;SET global event_scheduler=ON;

在实例的选项文件编辑下面的系统变量：

group_replication_start_on_boot=ON
super_read_only=ON
event_scheduler=ON

18.5组复制安全

18.5.1 IP地址白名单
18.5.2安全套接字层（SSL）的支持
18.5.3虚拟专用网络（VPN）

本节说明如何安全的一组，将一组成员之间的连接，或建立一个使用地址白名单安全防线。

18.5.1 IP地址白名单

组复制插件有一个配置选项来确定哪些主机传入的组通信连接可以接受。这个选项是group_replication_ip_whitelist。如果你设置这个选项在服务器S1，S2当服务器建立一个连接到S1进行组通信的目的，然后S1首先检查之前接受从S2连接白名单。如果S2是白名单，然后S1接受连接，否则拒绝连接尝试的S1 S2。

如果你不指定名单明确，服务器自动设置白名单，服务器的专用网络接口。这意味着一个服务器，即使它具有公网IP的接口，默认不允许从外部主机的连接。

每当IP白名单是设置为“自动”，一项是在错误日志中添加类似：

2017-10-07T06:40:49.320686Z 4 [Note] Plugin group_replication reported: '[GCS] Added automatically IP ranges 192.0.2.21/24,198.51.100.44,203.0.113.0/24,127.0.0.1/32 to the whitelist'

你还可以通过手动设置，可以使用组通信连接的主机列表提高集团的安全。您可以指定主机名称（从MySQL 8.0.4），简单的IP地址，或CIDR符号，任意组合。一个逗号分隔每个条目必须。例如:

mysql> STOP GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_ip_whitelist="192.0.2.21/24,198.51.100.44,203.0.113.0/24,example.org,www.example.com/24";
mysql> START GROUP_REPLICATION;

本地主机的IP地址（127.0.0.1）总是添加到白名单。如果没有明确规定，它是隐含的，自动添加。IPv6地址和主机名解析为IPv6地址，不支持。

主机名，域名解析发生仅当连接请求是由另一个服务器。一个主机名，不能解决的是不考虑白名单验证，和一个警告消息写入错误日志。提出确认反向DNS（fcrdns）验证是解析的主机名进行。

警告

主机名是固有的安全性低于在白名单的IP地址。fcrdns验证提供了很好的保护，但可以通过攻击某些类型的损害。指定主机名称在你的白名单，只有在绝对必要的，并确保所有用于名称解析组件，如DNS服务器，保持在你的控制之下。您也可以执行名称解析使用本地主机文件，避免了外部元件的使用。

加入一个复制组，服务器只需要白名单的种子成员，使请求加入群。通常，这将是为复制组的引导员，但它可以是任何上市的服务器--loose-group_replication_group_seeds加入该组中的服务器配置选项。但是，请注意，当复制组改组，集团成员之间重新建立连接。如果一个组内的成员只是不再是复制组部分服务器后重构，它是无法连接到在复制组不白它其余的服务器。为了避免这种情况下完全指定所有服务器的复制组成员的名单。

笔记

例如配置不同的白名单在不同组的成员根据自己的安全要求，是可能的，以保持不同的子网分开。如果你需要配置不同的白名单来满足您的安全要求，确保在复制组最大化服务器能够重新在原来的种子成员缺席的可能性之间有足够的重叠的白名单。

18.5.2安全套接字层（SSL）的支持

MySQL组复制支持OpenSSL和wolfssl建立MySQL服务器。

组通信以及恢复连接，并使用SSL保护。以下各节说明如何配置连接。

配置SSL的恢复

恢复是通过定期进行异步复制连接。一旦供选择，加入本集团建立了一个异步复制连接服务器。这是全自动的。

然而，用户需要一个SSL连接必须被创建在加入本集团之前的服务器连接到供体。通常，这是当时一个设置是设置服务器加入组。

donor> SET SQL_LOG_BIN=0;
donor> CREATE USER 'rec_ssl_user'@'%' REQUIRE SSL;
donor> GRANT replication slave ON *.* TO 'rec_ssl_user'@'%';
donor> SET SQL_LOG_BIN=1;

假设所有的服务器已经在集团有一个复制用户设置使用SSL，您配置加入本集团使用这些凭据连接到供当服务器。这是根据提供的组复制插件SSL选项的值做。

new_member> SET GLOBAL group_replication_recovery_use_ssl=1;
new_member> SET GLOBAL group_replication_recovery_ssl_ca= '.../cacert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_cert= '.../client-cert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_key= '.../client-key.pem';

并通过配置恢复通道使用的用户需要一个SSL连接的凭据。

new_member> CHANGE MASTER TO MASTER_USER="rec_ssl_user" FOR CHANNEL "group_replication_recovery";
new_member> START GROUP_REPLICATION;

配置SSL通信

安全插座可以在团队中建立成员之间的沟通。这个配置取决于服务器的SSL配置。例如，如果服务器的SSL配置，组复制插件也有SSL配置。在选项的更多信息配置服务器的SSL，看第6.4.2，“加密连接”命令选项。该选项配置组复制如下表所示。

表18.6 SSL选项

服务器配置

插件配置描述

_ SSL密钥

密钥文件路径。作为客户端和服务器证书。

_ SSL证书

证书文件路径。作为客户端和服务器证书。

SSL作为_

与SSL证书颁发机构是值得信赖的文件路径。

ssl_capath

含SSL证书颁发机构受信任证书的目录路径。

ssl_crl

包含证书吊销列表文件路径。

ssl_crlpath

目录包含证书撤销列表的路径。

SSL _密码

允许密码使用加密数据在连接时。

_ TLS版本

保密通信将使用这个版本的协议。


这些选项是MySQL服务器配置选项组的复制依赖于它的配置。此外还有以下组复制特定选项的插件本身配置SSL。

表18.7 group_replication_ssl_mode配置值

价值

描述

禁用

建立一个加密的连接（默认）

必修的

如果服务器支持安全连接建立安全连接。

作为_ verify

如需要，但此外验证服务器TLS证书对配置的证书颁发机构（CA）证书。

verify_identity

像verify_ca，但此外验证服务器证书匹配的主机，尝试连接。


下面的示例显示了一个示例my.cnf文件段用于在服务器上配置SSL如何激活这组复制。

[mysqld]
ssl_ca = "cacert.pem"
ssl_capath = "/.../ca_directory"
ssl_cert = "server-cert.pem"
ssl_cipher = "DHE-RSA-AEs256-SHA"
ssl_crl = "crl-server-revoked.crl"
ssl_crlpath = "/.../crl_directory"
ssl_key = "server-key.pem"
group_replication_ssl_mode= REQUIRED

唯一的插件特定的配置选项，是上市group_replication_ssl_mode。这个选项激活的小组成员之间的SSL通信，通过与配置SSL框架SSL _ *参数提供给服务器

18.5.3虚拟专用网络（VPN）

有什么预防组复制操作在虚拟专用网络。在它的核心，它仅仅依赖于建立他们之间传播信息的目的服务器之间连接一个IPv4插座。

18.6组复制系统变量

这些都是具体到组复制插件系统变量。每一个配置选项的前缀是“group_replication”。

重要

虽然大多数的变量称为动态，可以在服务器运行的变化，大多数变化只生效重启组复制插件。变量可以被改变而无需重新启动插件都特别指出，如在本节。

  • group_replication_allow_local_disjoint_gtids_join

    财产价值
    命令行格式--group-replication-allow-local-disjoint-gtids-join=value
    过时的是的（除去8.0.4）
    系统变量group_replication_allow_local_disjoint_gtids_join
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值OFF

    在版本8.0.4删除。让当前的服务器，即使它在群体中不存在交易加入组。

    警告

    使用时要小心启用这个选项是不正确的使用可能会导致在组不一致。

  • group_replication_allow_local_lower_version_join

    财产价值
    命令行格式--group-replication-allow-local-lower-version-join=value
    系统变量group_replication_allow_local_lower_version_join
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值OFF

    让当前的服务器，即使它比集团下的插件版本加入的组。

  • group_replication_auto_increment_increment

    财产价值
    命令行格式--group-replication-auto-increment-increment=value
    系统变量group_replication_auto_increment_increment
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值7
    最小值1
    最大值65535

    确定此服务器实例上执行交易连续列值之间的时间间隔。

  • group_replication_bootstrap_group

    财产价值
    命令行格式--group-replication-bootstrap-group=value
    系统变量group_replication_bootstrap_group
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值OFF

    将这个服务器配置引导组。此选项只能设置一个服务器只有当启动组首次或重新启动整个集团。此前集团已自举，设置这个选项OFF。它应该被设置为关闭动态配置文件中的。从两个服务器或设置此选项而组运行可能导致人工脑裂情况的一个服务器重新启动，在独立的两组具有相同名称的自举。

  • group_replication_communication_debug_options

    财产价值
    命令行格式--group-replication-communication-debug-options=value
    介绍8.0.3
    系统变量group_replication_communication_debug_options
    范围全球
    动态是
    set_var提示应用否
    类型字符串
    默认值GCS_DEBUG_NONE
    有效值

    GCS_DEBUG_NONE

    GCS_DEBUG_BASIC

    GCS_DEBUG_TRACE

    XCOM_DEBUG_BASIC

    XCOM_DEBUG_TRACE

    GCS_DEBUG_ALL

    配置调试信息水平为不同组的复制组件，如组通信系统（GCS）和网络互连。调试信息存储在GCS_DEBUG_TRACE在数据目录下的文件

    可用的选项设置，指定为字符串，可以结合。下面的选项是可用的：

    • GCS_DEBUG_NONE不可分割的一切都是为了

    • GCS_DEBUG_BASIC使在GCS基本的调试信息

    • GCS_DEBUG_TRACE使在GCS跟踪信息

    • XCOM_DEBUG_BASIC使在XCOM基本的调试信息

    • XCOM_DEBUG_TRACE使在XCOM的跟踪信息

    • GCS_DEBUG_ALL使所有的调试水平GCs和XCOM

    设置调试级别GCS_DEBUG_NONE只有当没有任何其他选项提供的影响。设置调试级别gcs_debug_allOverrides all other options .

  • group_replication_components_stop_timeout

    财产价值
    命令行格式--group-replication-components-stop-timeout=value
    系统变量group_replication_components_stop_timeout
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值31536000
    最小值2
    最大值31536000

    超时，在几秒钟内，这组复制等各部件，当关闭。

  • group_replication_compression_threshold

    财产价值
    命令行格式--group-replication-compression-threshold=value
    系统变量group_replication_compression_threshold
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值1000000
    最小值0
    最大值4294967295

    在字节以上的价值（lz4）压缩的执行。当设置为零，使压缩。

  • group_replication_enforce_update_everywhere_checks

    财产价值
    命令行格式--group-replication-enforce-update-everywhere-checks=value
    系统变量group_replication_enforce_update_everywhere_checks
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值OFF

    启用或禁用严格一致性检查多主要更新无处不在。

  • group_replication_exit_state_action

    财产价值
    命令行格式--group-replication-exit-state-action=value
    系统变量group_replication_exit_state_action
    范围全球
    动态是
    set_var提示应用否
    类型枚举
    默认值ABORT_SERVER
    有效值

    ABORT_SERVER

    READ_ONLY

    配置复制时的行为如何组服务器实例离开集团无意，例如在遇到施放器的误差。什么时候group_replication_exit_state_action是集abort_server例如，自动关闭，当group_replication_exit_state_action是集read_only服务器交换机本身超级只读模式代替。

  • group_replication_flow_control_applier_threshold

    财产价值
    命令行格式--group-replication-flow-control-applier-threshold=value
    系统变量group_replication_flow_control_applier_threshold
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值25000
    最小值0
    最大值2147483647

    指定数量的等待交易在施放队列触发流量控制。该变量可以不复位组复制更改。

  • group_replication_flow_control_certifier_threshold

    财产价值
    命令行格式--group-replication-flow-control-certifier-threshold=value
    系统变量group_replication_flow_control_certifier_threshold
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值25000
    最小值0
    最大值2147483647

    指定数量的等待交易认证队列触发流量控制。该变量可以不复位组复制更改。

  • group_replication_flow_control_hold_percent

    财产价值
    命令行格式--group-replication-flow-control-hold-percent=value
    介绍8.0.2
    系统变量group_replication_flow_control_hold_percent
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值10
    最小值0
    最大值100

    定义有多少百分比的组配额仍然未允许集群下流量控制赶上积压。值为0意味着没有部分名额预留给赶上工作积压。

  • group_replication_flow_control_max_commit_quota

    财产价值
    命令行格式--group-replication-flow-control-max-commit-quota=value
    介绍8.0.2
    系统变量group_replication_flow_control_max_commit_quota
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值0
    最小值0
    最大值2147483647

    定义了该组的最大流量控制指标，或最大可用配额为任何一段流控制功能。值为0意味着没有最高限额设置。不能小于group_replication_flow_control_min_quota和集团_复制_流_控制_分钟_恢复_配额

  • group_replication_flow_control_member_quota_percent

    财产价值
    命令行格式--group-replication-flow-control-member-quota-percent=value
    介绍8.0.2
    系统变量group_replication_flow_control_member_quota_percent
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值0
    最小值0
    最大值100

    定义的配额比例，成员应承担提供本身在计算配额。值为0意味着配额应的成员，在过去的时期作家平分。

  • group_replication_flow_control_min_quota

    财产价值
    命令行格式--group-replication-flow-control-min-quota=value
    介绍8.0.2
    系统变量group_replication_flow_control_min_quota
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值0
    最小值0
    最大值2147483647

    控件可以分配给成员的最低流量控制指标，分别计算出的最小限额的最后期限执行。值为0意味着没有最低限额。不能大于group_replication_flow_control_max_commit_quota

  • group_replication_flow_control_min_recovery_quota

    财产价值
    命令行格式--group-replication-flow-control-min-recovery-quota=value
    介绍8.0.2
    系统变量group_replication_flow_control_min_recovery_quota
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值0
    最小值0
    最大值2147483647

    控件可以被分配到一个成员因为另一个回收小组成员的最低限额，独立计算出的最低限额的最后期限执行。值为0意味着没有最低限额。不能大于group_replication_flow_control_max_commit_quota

  • group_replication_flow_control_mode

    财产价值
    命令行格式--group-replication-flow-control-mode=value
    系统变量group_replication_flow_control_mode
    范围全球
    动态是
    set_var提示应用否
    类型枚举
    默认值QUOTA
    有效值

    DISABLED

    QUOTA

    指定用于流量控制模式。该变量可以不复位组复制更改。

  • group_replication_flow_control_period

    财产价值
    命令行格式--group-replication-flow-control-period=value
    介绍8.0.2
    系统变量group_replication_flow_control_period
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值1
    最小值1
    最大值60

    定义了流量控制迭代之间等待多少秒，在流量控制消息的发送流量控制管理任务的运行。

  • group_replication_flow_control_release_percent

    财产价值
    命令行格式--group-replication-flow-control-release-percent=value
    介绍8.0.2
    系统变量group_replication_flow_control_release_percent
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值50
    最小值0
    最大值1000

    如何定义该组配额应该释放时，流量控制不再需要节气门的作家成员，这个比例是每流控制期增加配额。值为0意味着，一旦流量控制的阈值范围内的配额是一个流量控制迭代发布。范围内允许的配额发放高达10倍，目前的配额，允许更大程度的适应，主要是当流量控制周期大，配额是非常小的。

  • group_replication_force_members

    财产价值
    命令行格式--group-replication-force-members=value
    系统变量group_replication_force_members
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    一列节点地址作为一个逗号分隔的列表如host1:port1，2：2。此选项用于力的新组的成员，以排除成员不接受一个新的视角和堵塞。你需要手动杀死排除服务器。列表中的任何无效的主机名可能导致后续START GROUP_REPLICATION语句失败是因为他们可以阻滞组成员。

  • group_replication_group_name

    财产价值
    命令行格式--group-replication-group-name=value
    系统变量group_replication_group_name
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    该服务器实例所属的组的名称。必须是一个有效的UUID。这个UUID是内部使用设置在二进制日志组复制事件gtids时。

    重要

    一个独特的UUID必须使用。

  • group_replication_group_seeds

    财产价值
    命令行格式--group-replication-group-seeds=value
    系统变量group_replication_group_seeds
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    一列组的成员提供一个成员加入组成员的加入与集团保持同步所需的数据。该表由种子成员的网络地址指定为一个以逗号分隔的列表，如host1:port1，2：2

    重要

    这些地址必须是成员的SQL的主机名和端口。

    通常这个目录包含该组的所有成员，但是你可以选择成为种子的一个子集的组成员。列表必须包含至少一个有效的成员的地址。开始时，每一组复制了地址是。如果列表不包含任何有效的主机名，发行START GROUP_REPLICATION失败.

  • group_replication_gtid_assignment_block_size

    财产价值
    命令行格式--group-replication-gtid-assignment-block-size=value
    系统变量group_replication_gtid_assignment_block_size
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值1000000
    最小值1
    最大值（64位平台）9223372036854775807
    最大值（32位平台）4294967295

    连续gtids，留给各成员的数量。每个会员消费它的块和储备更多的需要时。

  • group_replication_ip_whitelist

    财产价值
    命令行格式--group-replication-ip-whitelist=value
    系统变量group_replication_ip_whitelist
    范围全球
    动态是
    set_var提示应用否
    类型字符串
    默认值AUTOMATIC

    指定哪些主机可以连接到组。默认情况下，此系统变量设置为AUTOMATIC，允许连接的专用子网的主机主动。在主机主动接口进行扫描和那些私人子网地址自动添加到允许列表。

    或者，您可以指定一个白名单允许主机作为一个逗号分隔的IPv4地址列表，子网CIDR符号，或（从MySQL 8.0.4）主机名称，任意组合。例如:

    192.0.2.22,198.51.100.0/24,example.org,www.example.com/24

    允许连接总是地址127.0.0.1，即使没有明确指定。IPv6地址和主机名解析为IPv6地址，不支持。

    主机名，域名解析发生仅当连接请求是由另一个服务器。一个主机名，不能解决的是不考虑白名单验证，和一个警告消息写入错误日志。提出确认反向DNS（fcrdns）验证是解析的主机名进行。

    警告

    主机名是固有的安全性低于在白名单的IP地址。fcrdns验证提供了很好的保护，但可以通过攻击某些类型的损害。指定主机名称在你的白名单，只有在绝对必要的，并确保所有用于名称解析组件，如DNS服务器，保持在你的控制之下。您也可以执行名称解析使用本地主机文件，避免了外部元件的使用。

  • group_replication_local_address

    财产价值
    命令行格式--group-replication-local-address=value
    系统变量group_replication_local_address
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    网络地址为其他成员的连接提供成员，指定为host:port格式化字符串。这个地址必须是可达的组的所有成员，因为它是用XCOM，集团内部通信系统。

    警告

    不要使用这个地址与会员沟通。

    其他组成员联系会员通过复制host:port所有集团内部的沟通。这不是MySQL服务器SQL协议的主机和端口。

  • group_replication_member_weight

    财产价值
    命令行格式--group-replication-member-weight=value
    介绍8.0.2
    系统变量group_replication_member_weight
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值50
    最小值0
    最大值100

    一个重量百分比可以分配给成员影响的成员被选为在故障转移事件的主要机会，例如当存在初生叶单一主要组。指定数值的权重成员保证特定的成员是选举产生的，在预定的主要维护或确保一定的硬件是在故障转移事件优先级的例子。

    一组成员配置如下：

    • member-1: group_replication_member_weight=30, server_uuid=aaaa

    • member-2: group_replication_member_weight=40, server_uuid=bbbb

    • member-3: group_replication_member_weight=40, server_uuid=cccc

    • member-4: group_replication_member_weight=40, server_uuid=dddd

    一个新的初级以上成员会分为选举期间member-2，member-3，member-4，和member-1。这样的结果member2被选为新的故障转移事件发。有关更多信息，参见第18.4.1.1，“单原模式”

  • group_replication_poll_spin_loops

    财产价值
    命令行格式--group-replication-poll-spin-loops=value
    系统变量group_replication_poll_spin_loops
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值0
    最小值0
    最大值（64位平台）18446744073709551615
    最大值（32位平台）4294967295

    组通信的线程等待通信引擎互斥是在线程等待更多的传入的网络信息发布的次数。

  • group_replication_recovery_complete_at

    财产价值
    命令行格式--group-replication-recovery-complete-at=value
    系统变量group_replication_recovery_complete_at
    范围全球
    动态是
    set_var提示应用否
    类型枚举
    默认值TRANSACTIONS_APPLIED
    有效值

    TRANSACTIONS_CERTIFIED

    TRANSACTIONS_APPLIED

    回收政策在处理缓存交易后的状态转移。此选项指定一成员是否标志着在线在收到所有的交易，它错过了加入本集团之前（TRANSACTIONS_CERTIFIED）或当得到应用（transactions_applied）

  • group_replication_recovery_get_public_key

    财产价值
    命令行格式--group-replication-recovery-get-public-key
    介绍8.0.4
    系统变量group_replication_recovery_get_public_key
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值OFF

    无论是从主人的RSA密钥对的公钥密码交换所需的基础要求。这个变量适用于奴隶的鉴定与caching_sha2_password身份验证插件。这个插件，师傅不发送公钥除非要求。

    如果group_replication_recovery_public_key_path被设置为一个有效的公钥文件，它将优先于group_replication_recovery_get_public_key

  • group_replication_recovery_public_key_path

    财产价值
    命令行格式--group-replication-recovery-public-key-path
    介绍8.0.4
    系统变量group_replication_recovery_public_key_path
    范围全球
    动态是
    set_var提示应用否
    类型文件名
    默认值NULL

    一种含有一个由RSA密钥对的密码交换所必须掌握的公共密钥从复制文件的路径名。该文件必须在PEM格式。这个变量适用于奴隶的鉴定与sha256_password或caching_sha2_password奥斯汀·普鲁金（For）sha256_password，设置group_replication_recovery_public_key_path只适用于如果MySQL建成使用OpenSSL的。）

    如果group_replication_recovery_public_key_path被设置为一个有效的公钥文件，它将优先于group_replication_recovery_get_public_key

  • group_replication_recovery_reconnect_interval

    财产价值
    命令行格式--group-replication-recovery-reconnect-interval=value
    系统变量group_replication_recovery_reconnect_interval
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值60
    最小值0
    最大值31536000

    秒的睡眠时间，在尝试重新连接时，NO供体组发现。

  • group_replication_recovery_retry_count

    财产价值
    命令行格式--group-replication-recovery-retry-count=value
    系统变量group_replication_recovery_retry_count
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值10
    最小值0
    最大值31536000

    次，成员在加入之前试图放弃连接到可用的捐助者的数量。

  • group_replication_recovery_ssl_ca

    财产价值
    命令行格式--group-replication-recovery-ssl-ca=value
    系统变量group_replication_recovery_ssl_ca
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    一个文件包含一系列可信的SSL证书颁发机构的路径。

  • group_replication_recovery_ssl_capath

    财产价值
    命令行格式--group-replication-recovery-ssl-capath=value
    系统变量group_replication_recovery_ssl_capath
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    一个目录包含受信任的SSL证书颁发机构的证书路径。

  • group_replication_recovery_ssl_cert

    财产价值
    命令行格式--group-replication-recovery-ssl-cert=value
    系统变量group_replication_recovery_ssl_cert
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    用于建立安全连接的SSL证书的文件的名称。

  • group_replication_recovery_ssl_cipher

    财产价值
    命令行格式--group-replication-recovery-ssl-cipher=value
    系统变量group_replication_recovery_ssl_cipher
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    允许SSL加密的密码列表。

  • group_replication_recovery_ssl_crl

    财产价值
    命令行格式--group-replication-recovery-ssl-crl=value
    系统变量group_replication_recovery_ssl_crl
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    包含证书吊销列表目录包含文件的路径。

  • group_replication_recovery_ssl_crlpath

    财产价值
    命令行格式--group-replication-recovery-ssl-crlpath=value
    系统变量group_replication_recovery_ssl_crlpath
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    包含证书吊销列表目录包含文件的路径。

  • group_replication_recovery_ssl_key

    财产价值
    命令行格式--group-replication-recovery-ssl-key=value
    系统变量group_replication_recovery_ssl_key
    范围全球
    动态是
    set_var提示应用否
    类型字符串

    用于建立安全连接的SSL密钥文件的名称。

  • group_replication_recovery_ssl_verify_server_cert

    财产价值
    命令行格式--group-replication-recovery-ssl-verify-server-cert=value
    系统变量group_replication_recovery_ssl_verify_server_cert
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值OFF

    使恢复过程检查服务器的通用名称值供送证书。

  • group_replication_recovery_use_ssl

    财产价值
    命令行格式--group-replication-recovery-use-ssl=value
    系统变量group_replication_recovery_use_ssl
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值OFF

    无论是团体复制恢复连接应使用SSL或不。

  • group_replication_single_primary_mode

    财产价值
    命令行格式--group-replication-single-primary-mode=value
    系统变量group_replication_single_primary_mode
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值ON

    指导组自动选择一个单一的服务器是一个处理读/写的工作量。这个服务器是小学和所有其他的配套使用。

  • group_replication_ssl_mode

    财产价值
    命令行格式--group-replication-ssl-mode=value
    系统变量group_replication_ssl_mode
    范围全球
    动态是
    set_var提示应用否
    类型枚举
    默认值DISABLED
    有效值

    DISABLED

    REQUIRED

    VERIFY_CA

    VERIFY_IDENTITY

    指定复制组成员之间的联系的安全状态。

  • group_replication_start_on_boot

    财产价值
    命令行格式--group-replication-start-on-boot=value
    系统变量group_replication_start_on_boot
    范围全球
    动态是
    set_var提示应用否
    类型布尔
    默认值ON

    服务器是否应该开始组复制或不在服务器启动。

  • group_replication_transaction_size_limit

    财产价值
    命令行格式--group-replication-transaction-size-limit=value
    系统变量group_replication_transaction_size_limit
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值(>= 8.0.2)150000000
    默认值0
    最小值0
    最大值2147483647

    配置的最大交易字节大小的组接受。交易大于这个尺寸是回滚。使用此选项可避免大额交易导致集团失败。一个大的交易可以为一组出现问题，无论是在分配内存或网络带宽的消耗，这可能会导致故障探测器触发因为给定的成员是遥不可及的，它正忙着处理大交易。当设置为0有交易集团接受的大小没有限制，并有可能导致集团大型交易失败的风险。调整此变量取决于工作量，你需要从集团规模的价值。

  • group_replication_unreachable_majority_timeout

    财产价值
    命令行格式--group-replication-unreachable-majority-timeout=value
    介绍8.0.2
    系统变量group_replication_unreachable_majority_timeout
    范围全球
    动态是
    set_var提示应用否
    类型整数
    默认值0
    最小值0
    最大值31536000

    配置多久成员遭受网络分割和不能离开集团之前连接到大多数的等待。默认设置为0，这意味着成员发现他们由于网络分区永远等待连接组少数。5人一组服务器（S1，S2，S3，S4，S5），如果有一个脱节（S1、S2）和（S3、S4、S5）有一个网络分区。第一组（S1、S2）是目前少数因为它不能接触组的一半以上。而大多数组（S3、S4、S5）仍在运行，少数民族将永远等待一个网络连接。任何交易的少数民族处理阻塞直到组复制停止使用STOP GROUP REPLICATION对少数民族的成员

    如果配置为数秒钟，成员等待这个时间离开集团之前失去大部分成员接触后。所有悬而未决的交易由少数加工回在少数分区移动到服务器ERROR建立自己的国家super_read_only=ON模式

    警告

    当你有一个对称群，只有两个成员例如（S0，S2），如果有一个网络分区和没有多数，配置的超时后所有成员关闭并进入ERROR状态

组复制状态变量

本节描述状态变量提供有关组复制信息。变量具有以下含义：

  • group_replication_primary_member

    显示的主要成员的UUID当集团是主要经营模式单一。如果是多发的经营模式，显示一个空字符串。

    警告

    这个group_replication_primary_member状态变量已经被弃用，预计将在未来的版本中删除。

    看到第18.4.1.3，“找到主”

18.7要求和限制

18.7.1组复制的要求
18.7.2集团复制限制

本节列出了要求和组复制的局限性。

18.7.1组复制的要求

服务器实例要用于组复制必须满足以下要求。

基础设施

  • InnoDB存储引擎。数据必须存储在InnoDB事务存储引擎。交易执行，那么乐观，在提交时，被检查的冲突。如果有冲突，为了维护整个群体的一致性，一些事务回滚。这意味着事务性存储引擎是必需的。此外，InnoDB提供一些额外的功能，可以更好的管理和冲突时操作一起复制处理组。

  • 主键每个表由组复制必须定义主键，主键或等效的等效是一个非空的唯一键。这些钥匙都需要一个唯一标识表中的每行，使系统能够识别哪些行每笔交易都有修改，确定交易的冲突。

  • IPv4网络组通信引擎使用的MySQL复制仅支持IPv4组。因此，组复制要求IPv4网络基础设施。

  • 网络性能组复制设计为部署在集群环境中的服务器实例都非常接近对方，并受网络延迟以及网络带宽。

服务器实例配置

下列选项中，必须配置一个组的成员服务器实例。

  • 二进制日志活动配置--log-bin[=log_file_name]。MySQL复制复制组二进制日志内容，因此二进制日志需要在它的运作。默认是启用。看到5.4.4节，“二进制日志”

  • 从更新日志配置--log-slave-updates。需要服务器的二进制日志，通过日志的复制者。组中的服务器需要记录所有的交易，他们收到的申请的组。这是因为复苏依靠二进制日志形式的参与者组进行。因此，每个事务复制需要在每个服务器的存在，即使是那些交易不在服务器本身发起。默认是启用。

  • 行二进制日志格式配置--binlog-format=row。组复制依赖于基于行的复制格式传播始终在变化的服务器组。它依赖于行的基础设施能够提取必要的信息来检测，同时执行在不同的服务器组中的事务之间的冲突。看到17.2.1，“复制格式”

  • 全局事务标识符配置 --gtid-mode=ON。组复制使用全局事务标识符来跟踪哪些交易一直致力于在每一个服务器实例，从而可以推断哪些服务器已执行的交易，可以在其他地方已经提交的事务冲突。换句话说，显式事务标识符能够确定哪些交易架构的一个基本组成部分可能冲突。看到部分下面，“复制与全球事务标识符”

  • 复制信息库配置--master-info-repository=TABLE和--relay-log-info-repository=TABLE。复制者需要掌握的信息和中继日志的元数据写入mysql.slave_master_info和mysql.slave_relay_log_info系统表。这确保了组复制插件的复制元数据一致性和事务性管理。从MySQL 8.0.2，这些选项设置为表默认情况下，从MySQL 8.0.3，的FILE设置是过时的。看到第17.2.4.2，“奴隶状态日志”

  • 交易写集提取配置--transaction-write-set-extraction=XXHASH64所以，在收集行记录到二进制日志，服务器收集写定好了。写集是根据每行的主键是一个简化的标签唯一标识行紧凑视图改变。这个标签是用于冲突检测。默认是启用。

  • 多线程的应用复制组成员可以配置为多线程的奴隶，使交易可适用于平行。一个非零的值slave_parallel_workers使用多线程应用的成员，和多达1024个并行的线程可以指定区域。设置slave_preserve_commit_order=1确保最终提交并行交易是在同一顺序的原始交易，至于组复制所必需的，它依赖于一致性机制建立在保证所有与会成员收到申请提交的事务在同一顺序。最后，设置slave_parallel_type=LOGICAL_CLOCK，它指定用于决定哪些交易可以并行执行的奴隶政策，要求slave_preserve_commit_order=1。设置slave_parallel_workers=0禁用并行执行并给出了从单线程和线程不协调施。这样的设置，slave_parallel_type和slave_preserve_commit_order选项没有效果而被忽略。

18.7.2集团复制限制

组复制存在以下限制。注意限制和问题描述为多主模式组也可以申请单次模式集群故障转移事件中，而新当选的主要排出其施放队列从旧的主。

小贴士

组的复制是建立在基于gtid复制，因此你也应该知道第17.1.3.6，”与GTIDs的“复制限制

  • checksums复制事件。由于一个复制事件的校验和设计上的局限，组复制目前无法利用他们。因此集--binlog-checksum=NONE

  • 间隙锁认证过程中不考虑间隙锁，对间隙锁信息不可用外InnoDB。看到间隙锁更多信息

    笔记

    除非你依靠REPEATABLE READ在你的应用程序的语义，我们建议使用READ COMMITTED组复制的隔离级别。InnoDB不使用间隙锁READ COMMITTED，使得当地的冲突检测的分布式冲突检测组复制执行InnoDB。

  • 表锁锁和命名认证过程中不考虑表锁（见第13.3.6，“锁表和解锁表语法”）或命名锁（见GET_LOCK()）

  • SERIALIZABLE隔离级别。SERIALIZABLE隔离级别不在多组默认支持。设置事务隔离级别序列化配置复制拒绝提交事务。

  • 竞合DDL versus DML操作。并行数据定义语句和数据操作语句的执行对同一对象而在不同的服务器上使用多主模式时不支持。数据定义语言（DDL）在执行一个对象的语句，执行并发的数据操作语言（DML）对同一对象在不同的服务器实例具有风险不冲突的DDL执行不同情况下的检测。

  • 外键约束与级联多主模式组（成员的所有配置group_replication_single_primary_mode=OFF）不支持外键表具有多层次的依赖关系，具体表定义级联外资的关键约束。这是因为外键约束，级联操作的多主模式组执行的结果可以造成漏检的冲突，导致不一致的数据在该组的成员。因此我们建议设置group_replication_enforce_update_everywhere_checks=ON在服务器实例使用多主模式组避免漏检的冲突。

    在单一的初级模式，这不是一个问题，它不允许同时写入多个成员的组并没有发现冲突风险。

  • 非常大的交易这是足够大的，它不能被复制，集团成员之间在网络上一个5秒的窗口内可以导致在组通信故障gtid内容结果个人交易。为了避免这个问题，尽量减少你的交易规模尽可能。例如，分割文件的使用LOAD DATA INFILE成小块

  • 多主模式僵局当一个群体在多主模式操作，SELECT .. FOR UPDATE语句可以导致死锁。这是因为锁不在该组的成员共享的，所以对于这样一个声明的预期可能无法达成。

  • 复制器全球复制器不能用在一个MySQL服务器实例配置为组复制，因为有些服务器过滤交易将使集团无法达成一致的状态协议。通道特定复制过滤器可用于复制的通道没有直接参与组的复制，如其中一组成员也作为一个奴隶主，是一个复制组外。他们不能用对group_replication_applier或group_replication_recovery频道

18.8交叉询问问题

本节提供了常见问题的解答。

在一组的MySQL服务器的最大数量是多少？

一组可以由最大9服务器。尝试添加另一个服务器，一组9成员使请求加入被拒绝。

在一组连接的服务器呢？

打开一个对等的TCP连接在一组服务器连接到组中的其他服务器。这些连接只用于内部通信和消息传递服务器之间的组。这个地址的设置group_replication_local_address变量

用于group_replication_bootstrap_group选项是什么？

自举标志指示成员创造一组和作为初始种子服务器。第二成员加入集团需要向成员，引导组动态改变配置，以便它可以添加到组。

一个成员需要引导组在两个场景。当本集团最初创建，或当关机和重新启动整个集团。

我如何恢复过程设置凭据？

你预先配置的组复制恢复通道使用的凭据CHANGE MASTER TO声明

我可以扩展我写负载使用组复制？

不直接，但MySQL组复制无共享的完全复制的解决方案，在该组中的所有服务器复制相同的数据量。因此，如果在一组成员写N个字节来存储由于事务提交操作，然后大约n字节写入存储在其他成员一样，因为交易是复制的到处都是。

然而，鉴于其他成员没有做同样的处理量，原有的成员就要做当它原来执行的交易，他们将变化快。交易是一个应用行变换格式的复制，而不必再重新执行交易（基于行的格式）。

此外，鉴于改变传播和应用在基于行的格式，这意味着他们在一个优化的紧凑格式接收，并可能减少IO操作时相比发起成员数。

总结一下，您可以扩展处理，通过传播自由交易的冲突在不同的成员。你可以从你的IO操作可能规模很小的一部分，从远程服务器接收必要的改变来读修改写稳定存储的变化。

并组复制需要更多的网络带宽和CPU，相比于简单的复制，同样的工作量下？

一些额外的负荷是因为服务器需要与对方同步的目的不断相互作用。这是很难量化的多少数据。这也取决于组的大小（3服务器并减少应力对带宽的要求比在组9服务器）。

同样的内存和CPU占用较大，因为更复杂的工作是服务器同步的一部分做为组消息。

我可以在广域网中部署组复制？

是的，但每个成员之间的网络连接必须是可靠的，具有合适的性能。低延迟，高带宽的网络连接是一种最佳的性能要求。

如果网络带宽是一个问题，然后第18.9.7.2，“信息压缩”可以用较低的带宽要求。然而，如果网络数据包丢弃，导致重新传输和更高的端到端延迟、吞吐量和延迟都是负面影响。

警告

当网络往返时间（RTT）任何集团成员之间是两秒或更多你可能遇到的问题作为内置的故障检测机制可以正确触发。

做会员自动加入一个队伍在temporaryconnectivity问题吗？

这取决于连接问题的原因。如果连接问题是短暂的和重联的足够快，故障检测是没有意识到这一点，那么服务器可能无法从组中删除。如果它是一个“长”的连接问题，那么故障检测器最终嫌疑人问题和服务器是从组中删除。

一旦服务器是从组中删除，你需要加入回来了。换句话说，在服务器是明确你需要重新手动组中删除（或有一个脚本做自动）。

一个成员排除在一组是什么时候？

如果成员变得沉默，其他成员将其从组配置。在实践中，这可能发生在成员已经坠毁或有网络断开。

检测到故障后，一个给定的超时逝去对于一个给定的成员和一个新的配置没有沉默的成员在它被创建。

当一个节点明显落后了？

没有定义方法的政策时，将自动从集团成员。你需要找出为什么成员滞后和固定，或从组中删除成员。否则，如果服务器太慢，它引发了流量控制，那么整个集团放缓以及。流量控制可以根据你的需要配置。

在A组中问题的怀疑，有触发重构的特殊memberresponsible？

不，在触发重构电荷群没有特殊成员。

任何成员可怀疑有问题。所有成员都需要（自动）同意给予成员失败。一个成员是在驱逐从组负责，通过触发重构。其成员负责驱逐成员不是你可以控制或设定。

我可以用组复制的碎片？

组复制的目的是提供高度可用的副本集；数据和写入复制在每个群体中的成员。缩放超出单个系统所能提供的，你需要一个业务流程和分片框架围绕一组复制集，其中每个副本集维护和管理一个给定的总数据碎片或分区。这种类型的安装，通常称为“分片集群“规模，允许你读取和写入线性无限制。

我如何使用组复制SELinux吗？

如果SELinux被启用，您可以验证应用sestatus V，那么你需要使该组复制通信端口的使用，配置group_replication_local_address，为mysqld因此，它可以绑定到它，听我说。看看哪个端口MySQL是目前允许使用的问题播种。假设端口配置为33061，添加必要的端口由SELinux发行许可semanage港- T mysqld_port_t -p tcp 33061

我如何使用组复制iptables？

如果防火墙被启用，那么你需要开放的端口组复制机器间通信。看目前的规则在每一台机器上，问题iptables -L。假设端口配置为6606，使发行超过必要的端口通信iptables -输入-p tcp -运动6606 -j ACCEPT

我如何恢复中继日志由成员用复制通道？

通过组复制使用的复制通道的行为相同的方式复制通道用于主从复制，因此依靠中继日志。在改变的事件relay_log变，或当选项不设置和主机名的变化，可能有错误。看到第17.2.4.1，“从中继日志”在这种情况下，恢复过程。或者，另一种固定的问题特别是在组复制发行STOP GROUP_REPLICATIONStatement and then aSTART GROUP_REPLICATION语句来启动实例。复制插件创建的组集团的复制品渠道再

为什么使用两组复制绑定地址？

组复制使用为两绑定地址的网络流量的SQL地址之间的分裂，客户端通过与会员沟通，和group_replication_local_address，内部使用的组的成员进行交流。例如，假设一个服务器有两个网络接口分配到网络地址203.0.113.1和198.51.100.179。在这种情况下，你可以使用203.0.113.1:33061对集团内部网络地址设置group_replication_local_address=203.0.113.1:33061。然后，您可以使用198.51.100.179为hostname和三千三百零六对于port。客户端SQL应用程序将连接到成员198.51.100.179:3306。这使您能够在不同的网络配置不同的规则。同样，集团内部通信可用于客户端应用程序的网络连接的分离，以提高安全性。

团体如何复制使用网络地址和主机名？

组复制使用的成员因此它的功能是由你的主机名和端口的配置直接影响之间的网络连接。例如，该集团复制恢复程序是基于异步复制使用服务器的主机名和端口。当一个成员加入一组接收组成员身份信息，使用网络地址信息，在上市performance_schema.replication_group_members。一个表中列出的成员为丢失的数据从集团新成员的捐助。

这意味着任何你使用配置主机名，如SQL网络地址或组种子地址，必须是一个完全合格的名称和每个组的成员可。你能保证这例如通过DNS配置正确，或/etc/hosts文件，或其他地方的过程。如果你想配置member_host服务器上的值，指定使用--report-host在服务器选项之前加入到组。

重要

指定的值是直接使用不受影响--skip-name-resolve选项

配置MEMBER_PORT在服务器上，指定使用--report-port选项

我如何找到主？

如果是单次的经营模式，它可以找到有用的是主要成员。看到第18.4.1.3，“找到主”

18.9组复制的技术细节

18.9.1组复制插件体系结构
18.9.2组
18.9.3数据处理。
18.9.4数据定义语句
为18.95分布式恢复
18.9.6可观测性
18.9.7组复制性能

本节提供了更多的技术细节，关于MySQL组复制。

18.9.1组复制插件体系结构

MySQL组复制MySQL插件，它建立在现有的MySQL复制的基础设施，利用如二进制日志功能，基于行的记录，和全球事务标识符。它集成了现有的MySQL的框架，如性能模式或插件和服务设施。下图给出了框图描绘MySQL组复制的整体架构。

图18.9组复制插件框图

The text following the figure describes the content of the diagram.

MySQL组复制插件包括一套API捕获，应用，和生命周期，控制插件如何与MySQL服务器交互。有界面使来自服务器的信息流的插件，反之亦然。这些接口隔离MySQL服务器核心组复制插件，且大多钩放在交易执行流水线。在一个方向上，服务器插件，有事件如服务器启动通知，服务器恢复，服务器接受连接，而服务器即将提交事务。在其他方向，插件指示服务器执行的动作，如提交或中止正在进行的交易，或排队交易的中继日志。

本集团复制插件体系结构的下一层是一套组件，反应时，通知被发送到他们。捕获组件负责跟踪，执行交易的相关背景。申请人组件负责对数据库执行远程交易。回收部件管理分布式恢复，并负责获取服务器，加入本集团目前选择供体，策划赶程序，供失败的反应。

继续沿着堆栈复制协议模块包含复制协议的具体逻辑。它处理冲突检测，并接受和传播事务组。

本集团复制插件架构的最后两层组通信系统（GCS）API，和一个基于Paxos组通信引擎的实现。GCS API是一个高层次的API，需要建立一个抽象的复制状态机的性能（见18.1节，“组复制背景”）。因此，分离的通讯层实现从剩余的上层插件。组通信引擎处理通信的复制组成员。

18.9.2组

在MySQL复制组，一组服务器形成一个复制组。一组有一个名字，以一个UUID的形式。集团动态和服务器可以离开（无论是自愿或不自愿）参加在任何时间。本集团调整自己每当服务器加入或离开。

如果一个服务器加入组，它会自动将自己的日期从现有的服务器取失踪状态。这种状态是由异步MySQL复制方式转让。如果一个服务器离开集团，例如它被取下来进行维修，其余的服务器发现它已经走了，重新组自动。在组成员服务第18.1.3.2，“团体会员”这一切的力量

18.9.3数据处理。

由于没有主服务器（大师）的任何特定的数据集，该组中的每个服务器可以在任何时间进行交易，即使交易，改变状态（RW交易）。

任何服务器可以执行一个交易没有任何先验协调。但是，在提交时，它的坐标与该组中的服务器上达成交易的命运决定休息。这种协调的目的有两个：（一）检查事务是否应该提交或不；（II）和传播的变化，其他服务器可以将交易以及。

作为一个交易是通过原子广播发送的，不是所有的服务器组中接收交易或没有做。如果他们接受它，然后他们都接受它以相同的顺序相对于其他交易之前发送。冲突检测是通过检查和比较写套进行交易。因此，他们在排水平检测。冲突解决：第一，规则者胜。如果T1和T2并发执行在不同的地点，因为T2命令之前，T1，和改变的同一行，然后T2赢得冲突和T1中断。换句话说，T1试图改变数据已经由T2呈现陈旧。

笔记

如果两个交易必然冲突往往不是，然后开始他们在同一个服务器的一个很好的实践。他们有机会对当地的锁管理器而不是中止在复制协议后。

18.9.4数据定义语句

在一组复制拓扑，需要谨慎执行数据定义语句，通常也被称为数据定义语言（DDL）。

MySQL 8介绍原子支持数据定义语言（DDL）语句，其中完整的DDL语句提交或回滚一个事务原子性。然而，DDL语句，原子或其他任何隐式结束当前会话中是活跃的交易，如果你做了COMMIT在执行该语句。这意味着，DDL语句不能在另一个事务内执行，如事务控制语句START TRANSACTION ... COMMIT，或结合在同一个交易的其他报表。

组复制基于一个乐观的复制模式，在语句执行的乐观和回滚后，如果有必要的话。每个服务器执行和有无固定组协议。因此，要更加小心复制多主模式DDL语句。如果你进行架构更改（使用DDL）和改变一个对象包含的数据（使用DML）对同一对象的变化需要经过同一个服务器，而图式操作尚未完成和复制的到处都是。如果不这样做可能会导致数据的不一致性，当操作中断或只有部分完成。如果是部署在单个主模式这个问题不会发生，因为所有的变化都是通过相同的服务器进行的，主要的。

在MySQL 5.0原子DDL支持的详细信息，以及由此产生的行为变化对某些语句的复制，看第13.1.1，“原子数据定义语句的支持”

为18.95分布式恢复

18.9.5.1分布式恢复基础
18.9.5.2恢复从一个时间点
18.9.5.3视图的变化
分布式恢复18.9.5.4使用建议和局限性

本节介绍的过程中通过一个成员加入组赶上组中其余的服务器，称为分布式恢复。

18.9.5.1分布式恢复基础

这部分是一个高水平的总结。以下部分提供额外的细节，描述更详细的程序阶段。

组复制的分布式恢复可以归纳为过程，服务器从组，然后加入组处理同一套交易小组其他成员失踪的交易。在分布式恢复服务器加入缓冲任何交易和会员的事件发生而加入群组服务器接收来自该组所需的交易。一旦加入组服务器接收到所有的集团的交易，它将被缓冲在恢复过程中的交易。在这个过程中的服务器，然后加入集团作为一个在线成员结束。

1期

在第一阶段，加入组中选择一组服务器上的网络服务器是捐赠者的状态，这是失踪。供者负责提供加入组的所有数据是失踪到现在已加入该组服务器。这是依靠一个标准的异步复制通道实现，供入组服务器之间建立，看第17.2.3，“复制通道”。通过复制通道，捐赠者的二进制日志复制到点发生改变时，视图服务器加入集团成为该集团的一部分。加入群组服务器应用供体的二进制日志，它接收。

而二进制日志被复制、服务器加入集团也缓存的每一笔交易，交换群内。换句话说，它是倾听，发生后加入本集团，而它是从供体失踪状态应用事务。当第一阶段的结束和复制通道供关闭服务器加入组开始第二阶段：追赶。

2期

在这个阶段，服务器加入本集团收益的缓存事务的执行。当交易排队等待执行数达到零，声明成员在线。

弹性

恢复过程中承受失败而加入供体组服务器从它读取二进制日志。在这种情况下，每当一个供体未在阶段1，入组不到一个新的供体和恢复从一个服务器。当这种情况发生时，加入集团关闭连接到服务器失败加入集团明确服务器打开一个连接到一个新的供体。这是自动发生的。

18.9.5.2恢复从一个时间点

同步加入组与供体到特定时间点的服务器，该服务器加入组和供体利用MySQL全局事务标识符（gtids）机制。看到部分下面，“复制与全球事务标识符”。然而，gtids只提供了一种手段来实现交易加入群组服务器丢失，他们不帮助标识一个特定的时间点，加入群组服务器必须赶上，他们也帮助输送认证信息。这是二进制日志查看标记工作，这标志着在二进制日志流的观点的变化，也包含额外的元数据信息，提供加入组缺少认证相关数据服务器。

视图和视图的变化

解释视图更改标记的概念，它是要了解什么是视图和视图的变化很重要。

一意见对应一组成员积极参与当前的配置，换句话说，在一个特定的时间点。他们在系统的正确性和在线。

一观念的转变当本集团配置修改的情况，如有成员加入或离开。任何组成员变化的结果在一个独立的观点变化传达给所有的成员在同一逻辑时间点。

一视图标识符唯一标识一个视图。它生成的视图发生变化时

在组通信层、视图与视图ID的变化，然后进行交换之前和成员加入后的数据之间的界限。这个概念是通过一个新的二进制日志事件实现的：“查看更改日志事件”。视图ID从而成为一个标记，以及之前和之后的变化发生在组成员发送的交易。

视图标识符本身是由两部分：（我）这是一个随机生成的（II）一个单调递增的整数。第一部分时产生的组被创建，并保持不变，而在该组中至少有一个成员。第二部分是递增每次观发生变化。

这种异构双补视图ID的原因是需要明确标记组的变化只要一成员加入或离开而且每当所有成员离开组和无信息是什么看法的组。事实上，单调递增的标识符唯一使用全组停机后可导致同一ID的重用，破坏二进制日志数据标记的唯一性的复苏。总结一下，第一部分确定每当组从新开始和增量部分，当本集团改变了从这一点上。

18.9.5.3视图的变化

这部分解释了过程控制如何更改视图标识符纳入一个二进制日志事件写入日志，采取以下步骤：

开始：稳定组

所有服务器在线处理从集团来交易。一些服务器可能有点落后于交易复制的条件，但他们最终收敛。本集团作为一个分布式复制的数据库。

图18.1稳定组

Servers S1, S2, and S3 are members of the group. The most recent item in all of their binary logs is transaction T20.

观念的转变：一个成员加入

每当有新的成员加入组，因此执行视图改变，每一个在线服务器队列执行视图更改日志事件。这是因为前排队的看法的变化，一些交易可以排队服务器上的应用等，这些属于旧观点。排队观变化事件后他们保证正确的标记，当这一切发生的时候。

同时，加入组的服务器选择从网络服务器列表供所会员服务通过视图的抽象。一个成员加入视图和在线成员写一个视图更改事件的二进制日志。

图18.11一个成员加入

Server S4 joins the group and looks for a donor. Servers S1, S2, and S3 each queue the view change entry VC4 for their binary logs. Meanwhile, server S1 is receiving new transaction T21.

上人：状态转移

一旦加入集团选择的服务器组中的服务器是要供，一个新的异步复制连接建立两者之间的状态转移的开始（阶段1）。这与捐赠者的互动一直持续到服务器加入集团的应用线程处理视图更改日志事件对应的视图改变时触发服务器加入组进组。换句话说，加入群组服务器复制从供体，直到与视图标识符匹配视图标记已经在标记。

图18.12状态转移：追赶

Server S4 has chosen server S2 as the donor. State transfer is executed from server S2 to server S4 until the view change entry VC4 is reached (view_id = VC4). Server S4 uses a temporary applier buffer for state transfer, and its binary log is currently empty.

视图标识符发送给组中的所有成员在同一逻辑时间，加入组知道在服务器视图标识符应停止复制。这避免了复杂的计算gtid集因为视图ID清晰的标记数据属于每一组视图。

而加入群组服务器复制的捐助，这也是缓存传入交易从组。最终，它会停止复制从供体和开关应用那些缓存。

图18.13排队交易

State transfer is complete. Server S4 has applied the transactions up to T20 and written them to its binary log. Server S4 has cached transaction T21, which arrived after the view change, in a temporary applier buffer while recovering.

完成了

当服务器加入本集团认可与期待视野角度改变日志事件标识符，以供连接终止并开始应用缓存的交易。要理解一个重要的一点是最后的恢复过程。虽然它作为二进制日志的一个标志，划定的观点的变化，角度变化日志事件也扮演另一个角色。它传达的认证信息感知的所有服务器，当服务器加入组进组，换句话说，过去的看法的变化。没有它，加入组服务器就不能够保证必要的信息（检测冲突）后续交易。

“追赶时间（二期）是不确定的，因为它取决于工作量和入组率交易。这个过程是完全在线，加入群组服务器不在本集团任何其他服务器块则是追赶。因此，交易加入群组服务器数量的背后是当进入到2阶段，为此，各不相同，从而增加或减少根据工作量。

当服务器加入组达到零排队的交易和其存储的数据相当于其他成员，其公共状态更改为在线。

图18.14实例在线

Server S4 is now an online member of the group. It has applied cached transaction T21, so its binary log shows the same items as the binary logs of the other group members, and it no longer needs the temporary applier buffer. New incoming transaction T22 is now received and applied by all group members.

分布式恢复18.9.5.4使用建议和局限性

分布式恢复也有一定的局限性。它是基于经典的异步复制，这样可能比较慢，如果加入群组服务器没有配置在所有或提供一个很旧的备份映像。这意味着，如果要传输的数据太大，在1阶段，服务器可能需要很长的时间来恢复。因此，建议在添加一个服务器组，应设置与服务器已经在集团最近的快照。这最大限度地减少1阶段的长度和减少对供体的服务器的影响，因为它具有保存和传输二进制日志。

警告

建议服务器配置之前，它被添加到一个组。这样，一个最小的时间花在回收步骤。

18.9.6可观测性

有很多自动化的内置组复制插件。尽管如此，你可能需要了解什么是发生在幕后。这就是组复制和性能模式成为重要的仪器。整个系统的状态（包括视图、冲突统计和服务状态）可以查询到performance_schema表。分布性质的复制协议的事实，服务器实例同意从而同步交易和元数据使得简单的检查组的状态。例如，您可以连接到组中的一个服务器，获得局部和全局信息的发布选择在组复制相关的绩效模式表报表。有关更多信息，参见18.3节，“监测组复制”

18.9.7组复制性能

18.9.7.1微调组通信线
18.9.7.2消息压缩
18.9.7.3流量控制

本节说明如何使用可用的配置选项来从你的小组获得最佳性能。

18.9.7.1微调组通信线

组通信线程（GCT）运行在一个循环而组复制插件加载。GCT从集团和插件接收消息，处理群体和故障检测的相关工作，发出一些keep-alive消息并处理传入和传出的/服务器/交易。GCT等待队列中的传入消息。当有任何消息，GCT等。通过将此等待更长一点（做一个积极的等待）其实之前睡觉可以证明在某些情况下是有益的。这是因为，操作系统切换的GCT从处理器和上下文切换。

给力的GCT做积极的等待，用group_replication_poll_spin_loops选项，这使得GCT环的循环配置的数量做什么有关，其实之前轮询队列的下一个消息。

例如：

mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;

18.9.7.2消息压缩

当网络带宽的瓶颈，信息压缩可以提供高达30-40%的吞吐量在组通信水平。这一点尤其重要，在荷载作用下的大背景下，服务器组。

表18.8 lz4压缩比不同的二进制日志格式

工作量

比行

比为

mysqlslapd

4

4,1

过

3

9


的连接之间的TCP对等性N在小组的参与者使得发送者发送相同的数据量N时代此外，二进制日志有可能表现出很高的压缩比（见上表）。这使得压缩包含大型交易工作负载的一个引人注目的特点。

图18.15压缩支持

The MySQL Group Replication plugin architecture is shown as described in an earlier topic, with the five layers of the plugin positioned between the MySQL server and the replication group. Compression and decompression are handled by the Group Communication System API, which is the fourth layer of the Group Replication plugin. The group communication engine (the fifth layer of the plugin) and the group members use the compressed transactions with the smaller data size. The MySQL Server core and the three higher layers of the Group Replication plugin (the APIs, the capture, applier, and recovery components, and the replication protocol module) use the original transactions with the larger data size.

压缩发生在组通信机的水平，之前的数据移交给集团通信线程，所以它发生在MySQL用户会话线程的上下文。交易的有效载荷可能之前被发送到组和减压时，接收的压缩。压缩是有条件的，取决于配置的阈值。默认情况下启用压缩。

此外，没有要求该组中的所有服务器都压缩功能可以一起工作。当接收到一个消息，成员检查邮件信封验证是否压缩或不。如果需要，则会员解压缩之前交易，提供给上层。

所使用的压缩算法lz4。压缩是由1000000个字节的阈值默认启用。在字节压缩阈值，可设置为大于默认。在这种情况下，只有一个有效载荷大于阈值的交易被压缩。下面是一个例子，如何设置压缩阈值。

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 2097152;
START GROUP_REPLICATION;

这套压缩阈值2MB。如果一个事务产生一个有效载荷大于2Mb复制信息，例如二进制日志事务条目大于2MB，然后压缩。禁用压缩阈值为0。

18.9.7.3流量控制

组复制确保交易只犯一组多数成员在收到并同意所有被派兼任交易之间的相对顺序。

这种方法效果很好，如果总数量的写入组不超过写本集团任何成员的能力。如果这样做，有些人比别人少写的吞吐量，特别是小于作家的成员，这些成员可以开始滞后的作家。

有一些成员落后组带来了一些不利后果，尤其是，读这样的成员可能会呈现非常老的数据。根据为什么成员是滞后的，团队中的其他成员可能会节省更多或更少的复制环境能够满足潜在的数据传输请求从缓慢的成员。

然而在复制协议的机制，避免太多的距离，在业务应用方面，快与慢的成员之间。这就是所谓的流量控制机制。它试图解决的几个目标：

  1. 保持成员密切足以使缓冲和去同步成员之间小问题；

  2. 迅速适应不断变化的条件下，如在组不同的工作负载或更多的作家；

  3. 给每个成员的公平分享，写的能力；

  4. 在不降低吞吐量超过严格避免资源浪费。

鉴于集体复制的设计，决定是否节流或不可能决定考虑到了两个工作队列：（我）这个认证队列；（II）在二进制日志施放队列。每当一个队列的大小超过设定的阈值，节流装置被触发。只有配置：（我）是否在认证机构或在应用层面，做流量控制或两者；和（II）每个队列的阈值是什么。

流量控制主要取决于两个基本机制：

  1. 成员的监测收集的吞吐量和所有团队成员的队列大小的一些统计上的最大写入压力各成员应是猜测；

  2. 节流，想写超过其公平份额的可用容量在每一时刻的成员。

18.9.7.3.1探针和统计

监控机制的作品，让每一个成员部署一组探针收集工作队列和流量信息。然后传播这些信息对本集团定期分享与其他成员的数据。

这种探针是分散在整个插件堆栈和允许建立一个指标，如：

  • 认证机构的队列大小；

  • 复制者队列大小；

  • 交易认证总数；

  • 远程交易会员申请总数；

  • the number of当地总的交易。

一旦成员接收来自另一成员的统计信息，计算有关多少交易认证的附加指标，应用在过去的监测期间本地执行。

监测数据共享与其他成员定期。监测期内必须足够高，以允许其他成员决定当前的写请求，但足够低，它对集团的带宽的影响最小。信息共享的每一秒，这段时间足以解决问题。

18.9.7.3.2组复制节流

基于度量的聚集在所有的服务器组中，节流机构介入和决定是否限制速度的成员能够执行和提交新的交易。

因此，所有成员获得的指标是每个成员的能力计算的基础：如果一个成员有一个大的队列（用于认证或敷贴线），然后执行新事务的能力应该是接近于标准或应用在最后阶段的。

组内的所有成员的最低容量决定群的实际能力，而当地交易的数量决定了有多少人写它，和，因此，有多少成员，可用容量共享。

这意味着，每一个成员都有一个既定的编写基于有效容量的配额，换句话说，交易数量可以安全的问题，为下一个阶段。作者配额将执行的节流机构如果认证机构或二进制日志施放队列的大小超过了用户定义的阈值。

配额的交易在最后一期的延后数降低，并进一步降低10%允许引发的问题以减少其大小的队列。为了避免大的跳跃在吞吐量一旦队列的大小超过阈值时，吞吐量只允许每一段后，增长10%。

目前的节流机构不惩罚交易低于配额，但延迟完成交易，超过它在监测期结束。因此，如果配额很小的写请求发出一些交易可能延迟接近监测期。

前一个起来下一个
17章复制主页第19章mysql