MySQL:group_replication_start_on_boot vs group_replication_bootstrap_group

这两个 MySQL Group Replication（组复制）的参数非常容易混淆，但它们的核心作用和触发时机完全不同。

简单来说：start_on_boot 决定了 "要不要自动加入组"，而 bootstrap_group 决定了 "要不要新建（初始化）一个组"。

以下是它们的详细对比和使用场景：

1. 核心区别表格

参数	默认值	作用（通俗解释）	正常运行时的状态
`group_replication_start_on_boot`	`ON`	自动加组。当 MySQL 服务启动或重启时，是否自动尝试启动组复制（加入已有的组）。	建议保持 `ON`
`group_replication_bootstrap_group`	`OFF`	引导/新建组。是否将当前节点作为第一个节点，来"凭空"创造一个全新的复制组。	必须保持 `OFF`

2. 深入理解这两个参数

🔄 `group_replication_start_on_boot`（启动时自动加组）

它的作用：这是一个持久化的配置。如果设为 ON，每次服务器重启、MySQL 进程拉起时，它会自动在后台执行 START GROUP_REPLICATION;。
为什么需要它：为了实现自动化。如果不开启，每次服务器断电重启，你都需要手动登录数据库去敲命令让它加入集群。
注意：它只是尝试加入。如果它加入的目标集群根本不存在（或者都挂了），它会报错并加入失败。

🚀 `group_replication_bootstrap_group`（引导/初始化组）

它的作用：这是一个临时的开关。当你的集群是第一次建立，或者所有节点都挂了需要重新把集群拉起来时，必须有且仅有一个节点开启这个参数，作为"带头大哥"来初始化这个组（即 Bootstrap）。
危险性：绝对不能把这个参数写死在配置文件（my.cnf）中并设为 ON！如果写死了，未来这台机器重启时，它不会去寻找现有的集群，而是会自己再凭空创造一个同名的"新集群"，导致整个集群发生脑裂（Split-Brain），数据直接错乱。

3. 正确的使用流程（实战演练）

通过下面这个集群建立的流程，你就能彻底分清它们：

场景 A：第一次建立 3 个节点的 MGR 集群（Node1, Node2, Node3）

在所有节点的 my.cnf 中配置：

复制代码

group_replication_start_on_boot=ON      # 大家都希望以后重启能自动加组
group_replication_bootstrap_group=OFF   # 默认千万别引导，安全第一

在 Node1 上手动引导集群（让 Node1 成为带头大哥）：

复制代码

-- 临时开启引导开关
SET GLOBAL group_replication_bootstrap_group=ON;
-- 启动组复制（此时 Node1 凭空创建了新组）
START GROUP_REPLICATION;
-- 【非常重要】创建成功后，立刻关闭引导开关！防止下次误触发
SET GLOBAL group_replication_bootstrap_group=OFF;

在 Node2 和 Node3 上直接加入：
因为 Node1 已经把组建好了，Node2 和 Node3 只需要直接加入即可：
复制代码
```
START GROUP_REPLICATION;
```

场景 B：日常运维中，Node2 意外宕机重启了

因为 Node2 的 group_replication_start_on_boot=ON，当它的服务器重启、MySQL 服务起来后，它会自动在后台执行 START GROUP_REPLICATION，然后发现 Node1 和 Node3 还在正常运行，于是默默地加入它们，恢复正常。期间完全不需要用到 bootstrap_group。

💡 总结口诀

start_on_boot 是常规武器，开着它，服务器重启了能自己归队。
bootstrap_group 是开天辟地的禁忌武器，只有建新集群（或集群全灭复活）时，让第一个节点临时开一下，用完必须马上关掉。