MySQL InnoDB Cluster常用管理命令

MySQL InnoDB Cluster作为官方的高可用方案，整合了Server、Shell和Router三大组件，能自动化处理故障转移、成员管理和模式切换。今天不说那些大道理，直接上一份日常运维中用得最多的高频命令清单——连接、状态检查、成员增删、主从切换，一应俱全，拿来即用。

一、基础准备：连接 MySQL 实例

所有集群管理操作，都得先从 MySQL Shell 连上集群中的某个实例开始。建议优先连主节点（比如这里的 192.168.184.151），命令格式很直接：

# 格式：mysqlsh -u[用户名] -p'[密码]' -h[实例IP] -P[端口，默认3306可省略]mysqlsh -umgr_user -p'BgIka^123' -h192.168.184.151

提醒一点：实际使用时，记得把 mgr_user、密码和 IP 换成你自己的。密码最好别直接敲在命令行里，省略 -p 后手动交互输入更安全。

二、集群状态与结构查询

连上之后，第一步是定义集群变量，后续所有操作都通过这个变量来调方法。先摸清集群当前的健康度再说。

1. 定义集群变量

用集群名称（示例是 Cluster01）获取集群对象，后续命令直接用 cluster 变量调用：

# 格式：var cluster = dba.getCluster('[集群名称]')var cluster = dba.getCluster('Cluster01')

2. 查看集群整体状态

这是运维中最常用的检查命令，没有之一。它会把集群成员列表、角色（主/从）、健康状态、复制状态一股脑儿展示出来：

cluster.status();

执行后，关键信息一目了然：

• 集群名称与版本
• 各成员实例的 IP:端口、角色（PRIMARY/SECONDARY）
• 复制同步状态（SYNCED/ERROR）
• 集群整体健康度（OK/WARNING/ERROR）

3. 显示集群详细结构

想看每个成员的具体配置——地址、权重、故障转移优先级这些？用这个命令：

cluster.describe();

4. 查看集群配置选项

全局配置比如故障转移超时时间、复制延迟阈值、多主模式开关，统统在这：

cluster.options();

三、集群成员管理：增删实例

扩容或下线故障节点，是家常便饭。操作前先用 cluster.status() 确认目标实例状态，稳一手。

1. 移除集群成员

移除前要确保目标实例是 SECONDARY 角色（主节点得先切换）。命令支持 IP:端口 或 主机名:端口 两种格式：

# 1. 先确认集群状态，找到目标实例（示例为 192.168.184.153）cluster.status();# 2. 移除实例（二选一，根据环境选择地址格式）cluster.removeInstance('mgr_user@192.168.184.153:3306');# 或使用主机名（需确保主机间能解析）cluster.removeInstance('mgr_user@maria-03:3306');# 3. 移除后再次确认状态，确保实例已从集群中删除cluster.status();

2. 添加集群成员

加新实例之前，有几个前提得满足：实例得初始化好、与集群其他节点网络互通、数据能同步（或支持自动增量同步）。命令格式和移除差不多：

# 二选一，添加 192.168.184.153 实例到集群cluster.addInstance('mgr_user@192.168.184.153:3306');# 或使用主机名cluster.addInstance('mgr_user@maria-03:3306');

加成功后，新实例自动加入复制集群，角色默认是 SECONDARY。

四、主节点管理：手动切换与模式切换

InnoDB Cluster 支持 单主模式（默认，只有一个 PRIMARY）和 多主模式（多个 PRIMARY，支持并行写入）。根据业务需求切换模式，或者手动指定主节点，都是常规操作。

1. 手动切换主节点（单主模式下）

原主节点要维护升级时，手动把某个 SECONDARY 节点扶正：

# 格式：cluster.setPrimaryInstance('管理用户@目标实例地址')cluster.setPrimaryInstance('mgr_user@192.168.184.153:3306');# 或使用主机名cluster.setPrimaryInstance('mgr_user@maria-03:3306');

注意：切换过程中集群会短暂停止写入，最好在业务低峰期做，并且确保目标节点数据与原主节点完全同步。

2. 切换为多主模式

多主模式适合分布式写入场景，当然前提是业务上能处理好写入冲突。切换命令在主节点的 MySQL Shell 中执行：

# 在 192.168.184.151（原主节点）的 MySQL Shell 中执行cluster.switchToMultiPrimaryMode();# 查看切换后状态（所有节点角色变为 PRIMARY）cluster.status();

3. 切换回单主模式

如果业务不再需要多主写入，切回来很简单，同时指定新的主节点（示例为 maria-01:3306）：

# 格式：cluster.switchToSinglePrimaryMode('目标主节点地址')cluster.switchToSinglePrimaryMode('maria-01:3306');# 查看切换后状态（仅指定节点为 PRIMARY，其余为 SECONDARY）cluster.status();

五、复制与成员信息深度查询

1. 查看复制统计信息

通过 performance_schema.replication_group_member_stats 这个系统表，能监控组复制中单个成员的事务处理状态、冲突情况及队列信息。排查复制延迟和数据一致性问题时，这是关键视图。字段含义结合示例数据来看，会更直观：

SELECT * FROM performance_schema.replication_group_member_statsG

1. 基础标识字段（定位成员与复制通道）

2. 事务队列与校验统计（监控事务流转效率）

3. 事务提交与冲突历史（追溯数据一致性状态）

4. 本地与远程事务细分（区分事务来源）

从示例数据可以得出几个结论：

1. 集群状态健康：无队列积压（0）、无冲突（0）、无本地回滚（0）；
2. 数据完全一致：所有校验通过的事务（6个远程+1个本地）均已在全集群提交；
3. 复制效率正常：远程事务应用及时，无延迟风险。

2. 查看集群成员列表（全节点通用）

在任一集群实例中执行以下 SQL，所有成员的 ID、地址、角色与状态一览无余：

SELECT * FROM performance_schema.replication_group_members;

返回结果包含：

• MEMBER_HOST：成员IP/主机名
• MEMBER_PORT：端口
• MEMBER_ROLE：角色（PRIMARY/SECONDARY）
• MEMBER_STATE：状态（ONLINE/OFFLINE/RECOVERING）

3. 列出关联的 MySQL Router 实例

MySQL Router 是集群的入口，负责流量分发。想知道当前哪些 Router 连了集群？在主节点的 MySQL Shell 中执行：

cluster.listRouters();

六、组复制启停（应急操作）

组复制（Group Replication）是 InnoDB Cluster 的核心机制。如果某节点需要临时下线修复，可以手动启停它的组复制。

1. 关闭组复制（目标节点执行）

在要下线的节点（示例为 192.168.184.153）的 MySQL Shell 中执行：

# 关闭当前节点的组复制STOP GROUP_REPLICATION;# 切换到主节点（192.168.184.151）查看集群状态，确认该节点已离线cluster.status();

2. 启动组复制（目标节点执行）

故障修好了？在该节点（192.168.184.152）的 MySQL Shell 中重启组复制，节点会自动重新加入集群：

# 启动当前节点的组复制START GROUP_REPLICATION;# 切换到主节点查看状态，确认该节点已重新上线（状态变为 ONLINE）cluster.status();

七、操作注意事项

1. 权限与安全：集群管理用户（如 mgr_user）需要 GROUP_REPLICATION_ADMIN、CLUSTER_ADMIN 等权限。生产环境中，密码别明文输入，建议用 MySQL 密钥文件或交互输入。
2. 数据备份：执行成员删除、模式切换等关键操作前，先把数据全量备份一遍，防止手误。
3. 网络与解析：节点间确保 3306（数据库端口）、33061（组复制端口）等端口互通。如果用了主机名（如 maria-03），记得配好 /etc/hosts 解析。
4. 状态校验：所有操作前后，养成习惯跑一遍 cluster.status() 检查集群状态，确保没有 ERROR 或 OFFLINE 节点再继续下一步。

结语

上面整理的这些命令，覆盖了 InnoDB Cluster 日常运维的核心场景——从连接查询到成员管理，再到模式切换，基本就是一套随身工具箱。实际用的时候，结合业务场景（单主还是多主、读写分离等）和集群规模灵活调整就好。当然，如果想更深入理解背后的原理，建议仔细研读 MySQL 官方文档，这样才能保证集群长期稳定运行。