我正在尝试在 MySQL 5.7.21 上启用 MySQL 组复制插件，根据文档 ( https://dev.mysql.com/doc/refman/5.7/en/group-replication.html应该在 5.7 中可用)

当我尝试通过 MySQL 启用插件时：

我在 MySQL 中的插件的输出：

这是插件目录的内容：

这些是我的配置的内容：

猫 /etc/mysql/my.cnf

我想知道我是否使用了错误版本的 MySQL，或者是否需要其他一些步骤来安装组复制插件？

我在提议者任务（xcom_base.c）中看到了这样的代码段

这threepahse是int const threephase = 0和force_delivery == 0这里

push_msg_eq正常的paxos是否包括准备、接受和学习阶段

但是 push_msg_2p 将跳过准备阶段并直接发送接受请求

我想知道为什么，非常感谢。

我使用以下链接将 mysql master 配置为 master 组复制https://www.digitalocean.com/community/tutorials/how-to-configure-mysql-group-replication-on-ubuntu-16-04

我使用上面的链接连接了两个不同的服务器。第一个服务器已连接。但是第二台服务器没有连接，它给出了错误

我使用 mysql> START GROUP_REPLICATION; 此命令配置第二个服务器。但我收到以下错误日志

请任何人帮我解决这个错误

我有一个部署在 kubernetes(k8s) 上的 3 节点 mysql InnoDB 集群。每个 mysql 节点都是一个 k8s POD。为了测试可用性，我手动删除了对应的docker容器mysql主节点（使用命令'docker rm xxxx -f）。正如预期的那样，k8s 成功地重新创建了容器。但是，新创建的一个未能加入集群（更具体地说，未能加入组复制）。它抱怨该成员在当前组中没有交易。但是，额外的事务是将 SESSION.GTID_NEXT 设置为 AUTOMATIC 的操作。我不知道为什么它在 binlog 中并使重新加入失败。有人能给我一些提示或建议吗？非常感谢！

MySQL 版本是 mysql-community-server-minimal-5.7.20-1。它是从 rpm 安装的。

InnodDB 集群是通过采用现有的复制组创建的。这说我首先创建了复制组，然后创建了集群。

MySQL日志是这样的：

2018-03-12T08：17：21.208124Z 0 [注意] 插件 group_replication 报告：'新状态 x_run' 2018-03-12T08：17：21.218361Z 0 [错误] 插件 group_replication 报告：'此成员执行的事务比那些出现在群里。本地事务：925deea1-75db-4e92-86a9-00259c8d8078:1-50 > 组事务：925deea1-75db-4e92-86a9-00259c8d8078:1-2' 2018-03-12T08:17:21.218433Z 0 [错误] 插件 group_replication报告：'该成员包含组中不存在的事务。该成员现在将退出该组。2018-03-12T08:17:21.218444Z 0 [Note] 插件 group_replication 报告：'要强制此成员进入组，您可以使用 group_replication_allow_local_disjoint_gtids_join 选项' 2018-03-12T08:17:21.218493Z 3 [Note] 插件 group_replication 报告：' 正在等待视图修改' 2018-03-12T08:17:21.218546Z 0 [注意] 插件 group_replication 报告：'选择了地址为 t-baj3bsrg4cp000a1sp3g-mysql-0.mysql:3306 的新主节点，启用冲突检测直到新主应用所有中继日志。2018-03-12T08:17:21.218597Z 15 [注意] 插件 group_replication 报告：“此服务器正在作为主要成员工作。” 2018-03-12T08:17:21.218634Z 0 [注意] 插件 group_replication 报告：'组成员更改为 t-baj3bsrg4cp000a1sp3g-mysql-0.mysql:3306，t-baj3bsrg4cp000a1sp3g-mysql-1.mysql:3306，在视图 1520842242792 ：3。2018-03-12T08:17:21.218655Z 0 [注意] 插件 group_replication 报告：'地址为 t-baj3bsrg4cp000a1sp3g-mysql-2.mysql:3306 的成员在复制组中被声明为在线' 2018-03-12T08:17: 21. 218825Z 4 [错误] 插件 group_replication 报告：'无法更新服务器端的认证结果，thread_id：136' 2018-03-12T08:17:21.218838Z 4 [错误] 插件 group_replication 报告：'事件处理错误！出现错误：1' 2018-03-12T08:17:21.218849Z 4 [错误] 插件 group_replication 报告：'在组复制的应用程序进程上执行期间出现致命错误。服务器现在将离开该组。2018-03-12T08:17:21.218864Z 4 [警告] 插件 group_replication 报告：“跳过离开操作：正在进行的离开组的并发尝试。” 2018-03-12T08:17:21.218996Z 7 [注意] 读取通道“group_replication_applier”的中继日志事件时出错：从属 SQL 线程被杀死 无法在服务器端更新认证结果，thread_id: 136' 2018-03-12T08:17:21.218838Z 4 [错误] 插件 group_replication 报告：'事件处理错误！出现错误：1' 2018-03-12T08:17:21.218849Z 4 [错误] 插件 group_replication 报告：'在组复制的应用程序进程上执行期间出现致命错误。服务器现在将离开该组。2018-03-12T08:17:21.218864Z 4 [警告] 插件 group_replication 报告：“跳过离开操作：正在进行的离开组的并发尝试。” 2018-03-12T08:17:21.218996Z 7 [注意] 读取通道“group_replication_applier”的中继日志事件时出错：从属 SQL 线程被杀死 无法在服务器端更新认证结果，thread_id: 136' 2018-03-12T08:17:21.218838Z 4 [错误] 插件 group_replication 报告：'事件处理错误！出现错误：1' 2018-03-12T08:17:21.218849Z 4 [错误] 插件 group_replication 报告：'在组复制的应用程序进程上执行期间出现致命错误。服务器现在将离开该组。2018-03-12T08:17:21.218864Z 4 [警告] 插件 group_replication 报告：“跳过离开操作：正在进行的离开组的并发尝试。” 2018-03-12T08:17:21.218996Z 7 [注意] 读取通道“group_replication_applier”的中继日志事件时出错：从属 SQL 线程被杀死 2018-03-12T08:17:21.218849Z 4 [错误] 插件 group_replication 报告：'在组复制的应用程序进程上执行期间出现致命错误。服务器现在将离开该组。2018-03-12T08:17:21.218864Z 4 [警告] 插件 group_replication 报告：“跳过离开操作：正在进行的离开组的并发尝试。” 2018-03-12T08:17:21.218996Z 7 [注意] 读取通道“group_replication_applier”的中继日志事件时出错：从属 SQL 线程被杀死 2018-03-12T08:17:21.218849Z 4 [错误] 插件 group_replication 报告：'在组复制的应用程序进程上执行期间出现致命错误。服务器现在将离开该组。2018-03-12T08:17:21.218864Z 4 [警告] 插件 group_replication 报告：“跳过离开操作：正在进行的离开组的并发尝试。” 2018-03-12T08:17:21.218996Z 7 [注意] 读取通道“group_replication_applier”的中继日志事件时出错：从属 SQL 线程被杀死

故障节点上显示的 Bin 日志事件是：

+--------------------------------------------+----- +----------------+------------+-------------+------ -------------------------------------+ | 日志名称 | 位置 | 事件类型 | 服务器_id | 结束日志位置 | 信息 | +--------------------------------------------+----- +----------------+------------+-------------+------ -------------------------------------+ | t-baj3bsrg4cp000a1sp3g-mysql-0-bin.000003 | 4 | 格式描述 | 100 | 123 | 服务器版本：5.7.20-log，Binlog 版本：4 | | t-baj3bsrg4cp000a1sp3g-mysql-0-bin.000003 | 123 | 上一个_gtids | 100 | 190 | 925deea1-75db-4e92-86a9-00259c8d8078:1-50 | +--------------------------------------------+----- +----------------+------------+-------------+------ -------------------------------------------------+

binlog 文件中显示的 925deea1-75db-4e92-86a9-00259c8d8078:1-50 的事务：

仅供参考，根据 mysql 日志，设置 group_replication_allow_local_disjoint_gtids_join 选项对我有用。但是，请参阅选项group_replication_allow_local_disjoint_gtids_join的最新文档，它将在 mysql 5.7.22 中删除。所以，我必须找出问题的根本原因。谢谢！

我正在尝试使用 HA MySQL 设置创建一个 Laravel 应用程序。所以我登陆了 MySQL Group Replication，三台服务器处于多主模式，并且 MySQL 服务器前面有一个负载均衡器。

在我发现 MySQL Group Replication 无法在我的 Laravel 应用程序中处理级联语句之前，这非常有效。解决此问题的唯一方法是从多主设置更改为单主设置，其余服务器作为从属服务器。

在 MySQL Group Replication 中，如果 master 宕机，它会自动指定其中一个 slave 作为新的 master。但我不知道如何在我的应用程序中处理这个问题。我能想到的最好的办法是在主服务器出现故障时手动更改 Laravel 中的 MySQL 服务器 IP。我不能再使用负载均衡器设置，因为只有主服务器可以接受写入。

有谁知道我可以在 Laravel 中处理 MySQL 服务器的自动更改的方法吗？任何帮助深表感谢！

我有两个 MySQL 服务器，它们在同一组复制上运行。设置已通过以下步骤完成：

1. 第一台服务器是具有大量数据的生产服务器。
2. 我将它设置为只读并转储数据，然后在备用 MySQL 服务器上恢复它
3. 恢复后，我执行“START GROUP_REPLICATION”并成功加入组。所有数据在两台服务器之间同步良好。

但是我发现了另一个错误：每次我重新加载后备 MySQL（通过重新启动服务）时，它都会自动加入组但永远停留在 RECOVERING 中，我等了 3 天但它仍在 RECOVERING 中。我检查了日志，在两台服务器上都没有看到任何错误，除了回退以只读方式运行并保持在 RECOVERING 之外，一切看起来都很好。

我错过了哪一步？

我的组配置是（我按照https://www.digitalocean.com/community/tutorials/how-to-configure-mysql-group-replication-on-ubuntu-16-04上的 DigitalOcean 帮助页面的说明进行操作）：

二进制日志 #log_bin = /data/databases/mysql_bin199 expire_logs_days = 14

sync_binlog = 1 binlog_format = ROW

常规复制设置 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_format = ROW transaction_write_set_extraction = XXHASH64 松散组复制_引导组 = 关闭

松散组复制启动启动启动=开启松散组复制ssl模式=需要松散组复制恢复使用ssl=1

共享复制组配置loose-group_replication_group_name =

“9dc4ae01-6664-437a-83f8-80546d58e025”松散组复制ip_whitelist =“172.AAA.BBB.166,138.AAA.BBB.199”松散组复制组种子=“172.AAA.BBB.166:33061,138.AAA.BBB .199:33061"

单主模式还是多主模式？取消注释这两行

对于多主模式，任何主机都可以接受写入

松散组复制强制更新everywhere_checks = ON

主机特定的复制配置 server_id = 2 report_host = "138.AAA.BBB.199" 松散组复制本地地址 =

“138.AAA.BBB.199:33061”

以下是第一台服务器上的 MySQL 日志：

2018-06-08T06:10:12.167400Z 0 [警告] 插件 group_replication

报告：'从组中删除的成员：138.AAA.BBB.199:3306'

2018-06-08T06:10:12.167475Z 0 [注意] 插件 group_replication

报告：'组成员更改为 172.AAA.BBB.166:3306 正在查看

15271181169364149:11。2018-06-08T06:11:59.032666Z 0 [注意] 插件

group_replication 报告：'成员加入组：

138.AAA.BBB.199:3306' 2018-06-08T06:11:59.032722Z 0 [注意] 插件 group_replication 报告：'组成员身份更改为

172.AAA.BBB.166:3306、138.AAA.BBB.199:3306 在视图 15271181169364149:12。

以下是备用服务器上的 MySQL 日志：

2018-06-11T09:22:57.490896Z 0 [警告] 选项“max_allowed_pa​​cket”：

无符号值 3221225472 调整为 1073741824

2018-06-11T09:22:57.490942Z 0 [警告] InnoDB 的使用是强制性的

从 MySQL 5.7 开始。以前的选项，如 '--innodb=0/1/OFF/ON' 或

'--skip-innodb' 被忽略。2018-06-11T09:22:57.491057Z 0 [警告]

语法“--log_warnings/-W”已弃用，将在

未来的版本。请改用“--log_error_verbosity”。

2018-06-11T09:22:57.491098Z 0 [警告] 带有隐式的 TIMESTAMP

不推荐使用默认值。请用

--explicit_defaults_for_timestamp 服务器选项（有关详细信息，请参阅文档）。2018-06-11T09:22:57.492972Z 0 [注意] /usr/sbin/mysqld

(mysqld 5.7.22-log) 从进程 31633 开始...

2018-06-11T09:22:57.500063Z 0 [警告] InnoDB：使用

innodb_locks_unsafe_for_binlog 已弃用。这个选项可能是

在未来的版本中删除。请使用 READ COMMITTED 事务

而是隔离级别；请参阅

http://dev.mysql.com/doc/refman/5.7/en/set-transaction.html

2018-06-11T09:22:57.500175Z 0 [注意] InnoDB：打孔支持

可用 2018-06-11T09:22:57.500191Z 0 [注意] InnoDB：互斥锁和

rw_locks 使用 GCC atomic builtins 2018-06-11T09:22:57.500200Z 0 [注意]

InnoDB：使用事件互斥锁 2018-06-11T09:22:57.500205Z 0 [注意]

InnoDB：GCC 内置 __atomic_thread_fence() 用于内存屏障

2018-06-11T09:22:57.500209Z 0 [注意] InnoDB：压缩表使用

zlib 1.2.3 2018-06-11T09:22:57.500213Z 0 [注意] InnoDB：使用 Linux

本机 AIO 2018-06-11T09:22:57.500430Z 0 [注意] InnoDB：数量

池：1 2018-06-11T09:22:57.500575Z 0 [注意] InnoDB：使用 CPU crc32

说明 2018-06-11T09:22:57.501015Z 0 [错误] InnoDB: 失败

创建检查扇区文件，errno:13 请确认 O_DIRECT 是

支持并删除文件 /data/check_sector_size（如果存在）。

2018-06-11T09:22:57.502305Z 0 [注意] InnoDB：初始化缓冲池，

总大小 = 4G，实例 = 8，块大小 = 128M

2018-06-11T09:22:57.799065Z 0 [注意] InnoDB：完成初始化

缓冲池 2018-06-11T09:22:57.857325Z 0 [注意] InnoDB：如果

mysqld执行用户授权，页面清理线程优先级可以

被改变。请参阅 setpriority() 的手册页。

2018-06-11T09:22:57.870317Z 0 [注意] InnoDB：支持的最高文件

格式是梭子鱼。2018-06-11T09:22:58.081570Z 0 [注意] InnoDB：

为临时表创建共享表空间

2018-06-11T09:22:58.081656Z 0 [注意] InnoDB：设置文件

'/data/databases/ibtmp1' 大小为 12 MB。物理写入文件

满的; 请稍候... 2018-06-11T09:22:58.116190Z 0 [注意] InnoDB:

文件“/data/databases/ibtmp1”大小现在为 12 MB。

2018-06-11T09:22:58.117279Z 0 [注意] InnoDB: 96 重做回滚

段找到。96 个重做回滚段处于活动状态。

2018-06-11T09:22:58.117293Z 0 [注意] InnoDB: 32 非重做回滚

段处于活动状态。2018-06-11T09:22:58.117670Z 0 [注意] InnoDB：

等待清除开始 2018-06-11T09:22:58.168094Z 0 [注意]

InnoDB：5.7.22 开始；日志序列号 51745666191

2018-06-11T09:22:58.168309Z 0 [注意] InnoDB：加载缓冲池

来自 /data/databases/ib_buffer_pool 2018-06-11T09:22:58.168558Z 0

[注意] 插件 'FEDERATED' 已禁用。2018-06-11T09:22:58.183268Z 0

[警告] CA 证书 /etc/mysql/mysql-ssl/ca-cert.pem 是 self

签。2018-06-11T09:22:58.184615Z 0 [注意] 服务器主机名

（绑定地址）：'138.AAA.BBB.199'；端口：3306

2018-06-11T09:22:58.184636Z 0 [注] - '138.AAA.BBB.199' 解析为

'138.AAA.BBB.199'; 2018-06-11T09:22:58.184668Z 0 [注意] 服务器套接字

在 IP 上创建：'138.AAA.BBB.199'。2018-06-11T09:22:58.186203Z 0

[警告] 'user' 条目 'mysql.session@localhost' 被忽略

--skip-name-resolve 模式。2018-06-11T09:22:58.186220Z 0 [警告] 'user' 条目 'mysql.sys@localhost' 在 --skip-name-resolve 中被忽略

模式。2018-06-11T09:22:58.186238Z 0 [警告]“用户”条目

'phpmadsys@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.186260Z 0 [警告]“用户”条目

'phpmyadmin@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.186308Z 0 [警告] 'db' 条目 'performance_schema

mysql.session@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.186313Z 0 [警告] 'db' 条目 'sys

mysql.sys@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.186318Z 0 [警告] 'db' 条目 'phpmyadmin

phpmadsys@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.186322Z 0 [警告] 'db' 条目 'performance_schema

datadog@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.186327Z 0 [警告] 'db' 条目 'phpmyadmin

phpmyadmin@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.186340Z 0 [警告] 'proxies_priv' 条目'@

root@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.188628Z 0 [警告] 'tables_priv' 条目 'user

mysql.session@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.188649Z 0 [警告] 'tables_priv' 条目

'sys_config mysql.sys@localhost' 在 --skip-name-resolve 模式下被忽略。

2018-06-11T09:22:58.192624Z 0 [警告] --relay-log 和

--relay-log-index 被使用；因此，当此 MySQL 服务器充当从属服务器并更改其主机名时，复制可能会中断！请用

'--relay-log=dvm02-relay-bin' 来避免这个问题。

2018-06-11T09:22:58.206545Z 0 [注意] 事件调度程序：加载 0 个事件

2018-06-11T09:22:58.206745Z 0 [注意] /usr/sbin/mysqld: 准备好

连接。版本：'5.7.22-log' 套接字：

'/var/run/mysqld/mysqld.sock' 端口：3306 MySQL 社区服务器

(GPL) 2018-06-11T09:22:58.207175Z 2 [注意] 插件 group_replication

报告：'组通信 SSL 配置：

group_replication_ssl_mode：“需要”；server_key_file:

“/etc/mysql/mysql-ssl/server-key.pem”；server_cert_file:

“/etc/mysql/mysql-ssl/server-cert.pem”；客户端密钥文件：

“/etc/mysql/mysql-ssl/server-key.pem”；客户端证书文件：

“/etc/mysql/mysql-ssl/server-cert.pem”；ca_file:

“/etc/mysql/mysql-ssl/ca-cert.pem”；ca_path: ""; 密码：“”；

tls_version: "TLSv1,TLSv1.1"; crl_file: ""; crl_path: ""'

2018-06-11T09:22:58.207378Z 2 [警告] 插件 group_replication

报告：'[GCS] 自动将 IPv4 localhost 地址添加到

白名单。必须添加它。

2018-06-11T09:22:58.207820Z 2 [注意] 插件 group_replication

报告：'初始化组通信与配置：

group_replication_group_name：“9dc4ae01-6664-437a-83f8-80546d58e025”；

group_replication_local_address：“138.AAA.BBB.199:33061”；

group_replication_group_seeds：

“172.AAA.BBB.166:33061,138.AAA.BBB.199:33061”；

group_replication_bootstrap_group：假；

group_replication_poll_spin_loops：0；

group_replication_compression_threshold：1000000；

group_replication_ip_whitelist: "172.AAA.BBB.166,138.AAA.BBB.199"'

2018-06-11T09:22:58.207853Z 2 [注意] 插件 group_replication

报告：'[GCS] 配置的加入尝试次数：0'

2018-06-11T09:22:58.207859Z 2 [注意] 插件 group_replication

报告：“[GCS] 尝试加入之间的配置时间：5 秒”

2018-06-11T09:22:58.207878Z 2 [注意] 插件 group_replication

报告：'会员配置：member_id：2；member_uuid：

“822868f9-52a0-11e8-aa0e-1e45f9551f27”；单主模式：“假”；

group_replication_auto_increment_increment：7；'

2018-06-11T09:22:58.209024Z 3 [注] 'CHANGE MASTER TO FOR CHANNEL

'group_replication_applier' 已执行'。以前的状态

master_host=''，master_port=0，master_log_file=''，

master_log_pos=4，master_bind=''。新状态 master_host='',

master_port=0，master_log_file=''，master_log_pos=4，master_bind=''。

2018-06-11T09:22:58.216904Z 6 [注意] 通道的从属 SQL 线程

'group_replication_applier' 已初始化，在日志中开始复制

'FIRST' 在位置 0，中继日志

'./dvm02-relay-bin-group_replication_applier.000071' 位置：4

2018-06-11T09:22:58.216931Z 2 [注意] 插件 group_replication

报告：“组复制应用程序模块已成功初始化！”

2018-06-11T09:22:58.241357Z 0 [注意] 插件 group_replication

报告：'XCom 协议版本：3' 2018-06-11T09:22:58.241397Z 0

[注意] 插件 group_replication 报告：'XCom 已初始化并准备就绪

接受端口 33061 上的传入连接'

2018-06-11T09:22:59.213826Z 0 [注意] InnoDB：缓冲池加载

完成于 180611 11:22:59 2018-06-11T09:23:00.316791Z 0 [注]

插件 group_replication 报告：'组成员身份更改为

172.AAA.BBB.166:3306、138.AAA.BBB.199:3306 在视图 15271181169364149:16 上。

22.22.22.22 上的配置文件：

我按照文档说的那样制作：

到目前为止一切正常...

我在 33.33.33.33 上有一个配置文件：

我也关注文档：

一切都还好。。

但是当我进入

在 33.33.33.33 上发生错误：

错误 3092 (HY000)：服务器未正确配置为组的活动成员。请参阅错误日志的更多详细信息。

错误日志：

该怎么办？

MySQL版本：8.0.12

我想知道我们如何区分服务器上的主从复制和组复制。

辅助服务器会在 mysql 组复制中充当从属服务器吗？如果是，为什么在组复制成员上显示从属状态返回空集。

设置：

• master master 中的三个 mysql group 复制节点。
• 一切正常。我可以添加用户/数据库并插入/更新数据。
• 每个节点都绑定到一个私有 IP 地址。
• 我创建了一个 bash 脚本来连接到 mysql 以删除用户。
• 使用脚本删除数据库可以正常工作。

问题：

以下命令将不会运行。我可以创建用户和数据库并删除数据库，但不能删除用户。我不知道它是复制问题还是特权问题。

• 删除 mysql.user WHERE user='testme123';
• 从 mysql.db 中删除用户='testme123';
• 如果存在'testme123'则删除用户；

第 1 行的 ERROR 3098 (HY000)：该表不符合外部插件的要求。

日志：[错误] 插件 group_replication 报告：'表用户不使用 InnoDB 存储引擎。这与组复制不兼容。

我通过本地 mysql 控制台得到同样的错误，也以 root 身份登录。

问题）：

• 什么可以阻止这种情况？
• 如何解决我缺少的问题？

我有 3 台服务器的 MySQL 组复制。其中一个遇到错误，由于连接到供体服务器时出错，无法在复制列表中恢复其 ONLINE 状态。

[Repl] 通道“group_replication_recovery”的从 I/O：连接到主“repl@PRIV_IP_HERE:3306”时出错 - 重试时间：60 次重试：1，错误代码：MY-002061

我在所有 3 台服务器上重新初始化了组复制。在第一台服务器上引导复制列表有效，但其他 2 台服务器都无法成功加入组（卡在 RECOVERING 状态）。

如何修复此组复制恢复过程？