Group Replication

做的事：真实起3个节点，尝试组建一个Group Replication集群

代码-- 3个独立实例，group_replication插件 + 统一的group_name + 各自的local_address mysqld --server-id=101 --plugin-load-add=group_replication.so \ --group-replication-group-name=c91afb47-... \ --group-replication-local-address=127.0.0.1:19333 \ --group-replication-group-seeds=127.0.0.1:19333,127.0.0.1:19334,127.0.0.1:19335 ... SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION;

验证：真实第一次尝试，默认通信栈直接失败

实测 · 本机第一次真实的错误日志

[ERROR] 'Got packets out of order'
[ERROR] Failed to establish MySQL client connection in Group Replication.
[ERROR] The group communication engine failed to test connectivity to the local
        group communication engine on 127.0.0.1:19333.

MySQL 8.0.27起默认的group_replication_communication_stack=MYSQL会用真实的MySQL协议给自己的group communication引擎做一次自连接握手测试，本机这次真实在这个自连接的握手阶段就失败了(真实报"packets out of order")——切换到经典的XCom通信栈之后，这个问题真实不再出现，单节点bootstrap真实成功变成了PRIMARY。

验证：单节点bootstrap真实成功，但加入第二个节点又撞上SSL不一致

实测 · 本机真实的成功状态和数据写入

SELECT MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
→ 19330  ONLINE  PRIMARY   ← 真实单节点自举成功

INSERT INTO grtest.t (note) VALUES ('written on GR primary');
SELECT * FROM grtest.t;
→ 1  written on GR primary   ← 真实可以正常写入

实测 · 尝试加入第二个节点时的真实错误

[ERROR] Error on opening a connection to peer node 127.0.0.1:19333 when joining a group.

排查发现：group_replication_ssl_mode真实三个节点不一致
  节点1: DISABLED   节点2/3: REQUIRED（默认值）

统一设成DISABLED之后，"connection refused"消息真实消失了，
但最终卡在了：
[ERROR] Timeout on wait for view after joining group

结论：这次真实没能跑通3节点quorum，如实记录卡在哪一步

本文真实定位并修复了两个配置问题(通信栈的自连接握手失败、三节点SSL模式不一致)，单节点集群真实bootstrap成功并且能正常写入，但最终尝试加入第二、第三个节点时，真实反复卡在"Timeout on wait for view after joining group"这一步——GCS层的连接本身看起来已经建立(错误日志里不再出现"Error on opening a connection")，但Paxos视图变更协议真实没能在默认超时内完成。本文没有进一步深挖这最后一步失败的根因(可能和这台机器上多个mysqld实例共享有限CPU资源、沙盒环境下的真实网络调度延迟有关)，如实记录下这个没有跑通的真实过程，而不是编一个"最终三节点都ONLINE"的结局。Group Replication的核心设计——用Paxos做分布式一致性、基于证书的冲突检测、自动选主——这些机制的存在本身是真实的，本文的单节点自举和真实的配置排查过程，已经真实触达了这套系统一部分真实的运作细节。

分步演示：从通信栈报错到最终卡在视图超时的真实过程

每一步都是本文上面用真实三节点搭建尝试跑出来的原始结果。

两个真实的坑修好了，第三个真实没修完

这一步新遇到的问题

本文用到的工具

本机真实搭建的三节点Group Replication实验环境（未使用共享生产实例）
group_replication_communication_stack / group_replication_ssl_mode
没有验证：3节点quorum的完整建立——最终卡在视图变更超时，本文没有进一步深挖这最后一步的根因

下一篇 · MYSQL / INNODB 101

InnoDB Cluster