InnoDB Cluster 常见管理命令

InnoDB Cluster 是 MySQL 官方推出的高可用解决方案，整合了 MySQL Server、MySQL Shell 和 MySQL Router 等组件，能实现集群的自动故障转移、成员管理与模式切换，极大简化了 MySQL 高可用架构的部署与运维。本文基于实际操作场景，整理了 InnoDB Cluster 日常管理中高频使用的命令，涵盖连接、状态查询、成员管理、主从切换等核心操作，助力运维人员高效管控集群。

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

所有集群管理操作需通过 MySQL Shell 连接到集群中的任一实例（建议优先连接主节点，如示例中的 192.168.184.151），命令格式如下：

bash 复制代码

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

注意：实际使用时需替换 mgr_user（集群管理用户）、BgIka^123（用户密码）和 192.168.184.151（实例IP）为自身环境信息，密码建议避免明文输入，可省略 -p 后手动交互输入。

二、集群状态与结构查询

连接实例后，需先定义集群变量（后续操作通过该变量调用集群方法），再执行状态、结构与配置的查询命令，掌握集群当前健康度。

1. 定义集群变量

首次操作需通过集群名称（示例为 Cluster01）获取集群对象，后续命令可直接通过 cluster 变量调用：

javascript 复制代码

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

2. 查看集群整体状态

查询集群成员列表、角色（主/从）、健康状态、复制状态等核心信息，是运维中最常用的检查命令：

javascript 复制代码

cluster.status();

执行后会返回类似如下关键信息：

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

3. 显示集群详细结构

查看集群成员的具体配置（如实例地址、权重、故障转移优先级等），便于确认成员属性：

javascript 复制代码

cluster.describe();

4. 查看集群配置选项

查询集群的全局配置，如故障转移超时时间、复制延迟阈值、多主模式开关等：

javascript 复制代码

cluster.options();

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

根据业务需求（如扩容、下线故障实例），需对集群成员进行添加或移除操作，操作前建议先通过 cluster.status() 确认目标实例状态。

1. 移除集群成员

移除实例前需确保该实例处于 SECONDARY 角色（主节点需先切换角色），命令支持 IP:端口 或 主机名:端口 两种格式：

javascript 复制代码

# 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. 添加集群成员

添加新实例前需确保：实例已初始化、与集群其他节点网络互通、数据已同步（或支持自动增量同步），命令格式与移除类似：

javascript 复制代码

# 二选一，添加 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 节点切换为新主节点，命令如下：

javascript 复制代码

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

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

2. 切换为多主模式

多主模式适用于分布式写入场景（需确保业务无写入冲突），切换命令需在主节点的 MySQL Shell 中执行：

javascript 复制代码

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

3. 切换回单主模式

若业务不再需要多主写入，可切换回单主模式，并指定新的主节点（示例为 maria-01:3306）：

javascript 复制代码

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

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

1. 查看复制统计信息

通过查询 MySQL 系统表 performance_schema.replication_group_member_stats，可监控 MySQL 组复制（Group Replication）中单个成员节点的事务处理状态、冲突情况及队列信息，是排查复制延迟、数据一致性问题的关键视图。以下逐字段解析含义，并结合示例数据说明实际意义：

sql 复制代码

SELECT * FROM performance_schema.replication_group_member_stats\G

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

字段名	含义	示例解读
CHANNEL_NAME	复制通道名称，组复制默认使用 `group_replication_applier` 通道（负责"应用"从其他成员同步过来的事务）。	示例值 `group_replication_applier` 表示该统计数据对应组复制的默认应用通道，无自定义通道配置。
VIEW_ID	组复制的"视图ID"，用于标识当前集群的成员拓扑（成员加入/离开会导致视图ID更新，格式为 `[集群初始化ID]:[视图版本号]`）。	示例值 `17648371625947332:7` 表示： - 前半段 `17648371625947332` 是集群初始化时生成的唯一ID； - 后半段 `7` 表示当前是第7版成员视图（集群曾有6次成员变更，如节点加入/退出）。
MEMBER_ID	组复制成员节点的唯一ID（UUID格式），与 `performance_schema.replication_group_members` 表的 `MEMBER_ID` 一一对应，用于定位具体节点。	示例值 `532e3c83-d0c0-11f0-8a53-000c29aab861` 是当前查询节点的UUID，可通过它关联查询节点的IP、端口等基础信息。

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

字段名	含义	示例解读
COUNT_TRANSACTIONS_IN_QUEUE	已从其他成员接收、但尚未开始校验和应用的事务数量（队列长度）。	示例值 `0` 表示无待处理事务，队列无积压，复制延迟风险低。若该值持续增长，可能是CPU资源不足或事务执行缓慢导致应用阻塞。
COUNT_TRANSACTIONS_CHECKED	节点已接收并完成一致性校验的事务总数（包括本地发起和远程同步的事务）。	示例值 `6` 表示当前节点累计校验了6个事务，所有事务均通过"是否与其他成员冲突"的校验。
COUNT_CONFLICTS_DETECTED	校验过程中检测到的事务冲突总数（组复制核心指标，冲突会导致事务回滚或重试）。	示例值 `0` 表示无冲突事务，集群数据一致性良好。若该值大于0，需排查冲突原因（如多节点同时修改同一行数据，未合理设计主键或唯一索引）。
COUNT_TRANSACTIONS_ROWS_VALIDATING	校验时需要比对行数据的事务数量（仅当事务修改数据时触发，只读事务无需行校验）。	示例值 `1` 表示有1个事务在校验阶段需要比对具体行的数据（确认是否被其他节点修改），其余5个事务可能是只读或无需行校验的操作。

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

字段名	含义	示例解读
TRANSACTIONS_COMMITTED_ALL_MEMBERS	已在集群所有成员节点上成功提交的事务ID列表（格式为 `[发起节点UUID]:[事务序列号范围]`）。	示例值包含3段事务： 1. `1c783805-d0da-11f0-87d1-000c295cba4b:1-1126`：来自节点A的事务1~1126； 2. `aec1a885-d0c0-11f0-84c1-000c295cba4b:1-8`：来自节点B的事务1~8； 3. `cc759266-d0eb-11f0-915e-000c295cba4b:1-55:1000053`：来自节点C的事务1~55和1000053（可能是间隙事务或特殊标记）。这些事务已在所有节点提交，集群数据完全一致。
LAST_CONFLICT_FREE_TRANSACTION	最近一个无冲突提交的事务ID（若从未发生冲突，则为最新提交的事务）。	示例值 `cc759266-d0eb-11f0-915e-000c295cba4b:55` 表示：最近一次无冲突提交的事务是节点C的第55号事务，后续无新冲突（与 `COUNT_CONFLICTS_DETECTED=0` 一致）。

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

字段名	含义	示例解读
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE	从其他成员同步过来、已进入应用队列但尚未应用的事务数量（`COUNT_TRANSACTIONS_IN_QUEUE` 的子集，仅统计远程事务）。	示例值 `0` 表示无远程事务积压，远程事务应用及时。
COUNT_TRANSACTIONS_REMOTE_APPLIED	从其他成员同步过来并已成功应用的事务总数。	示例值 `6` 表示当前节点累计应用了6个来自其他节点的事务（与 `COUNT_TRANSACTIONS_CHECKED=6` 一致，说明所有校验通过的事务均为远程事务）。
COUNT_TRANSACTIONS_LOCAL_PROPOSED	当前节点本地发起并提交到集群的事务总数（本地事务需先"提议"给集群，经校验后同步到其他节点）。	示例值 `1` 表示当前节点发起过1个本地事务，且该事务已通过校验并同步到其他节点（因 `TRANSACTIONS_COMMITTED_ALL_MEMBERS` 包含本地事务ID）。
COUNT_TRANSACTIONS_LOCAL_ROLLBACK	当前节点本地发起但因冲突或错误被回滚的事务总数。	示例值 `0` 表示本地发起的事务均成功提交，无回滚，本地业务操作正常。

示例数据整体结论

从当前查询结果可判断：

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

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

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

sql 复制代码

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 实例信息（如 Router 名称、地址、版本）：

javascript 复制代码

# 在主节点（如 192.168.184.151）的 MySQL Shell 中执行
cluster.listRouters();

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

组复制（Group Replication）是 InnoDB Cluster 实现高可用的核心机制，若需临时下线某节点（如修复故障），可手动启停该节点的组复制。

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

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

sql 复制代码

# 关闭当前节点的组复制
STOP GROUP_REPLICATION;

# 切换到主节点（192.168.184.151）查看集群状态，确认该节点已离线
cluster.status();

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

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

sql 复制代码

# 启动当前节点的组复制
START GROUP_REPLICATION;

# 切换到主节点查看状态，确认该节点已重新上线（状态变为 ONLINE）
cluster.status();

七、操作注意事项

权限与安全 ：集群管理用户（如 mgr_user）需具备 GROUP_REPLICATION_ADMIN、CLUSTER_ADMIN 等权限；生产环境中避免明文输入密码，建议通过 MySQL 密钥文件或交互输入。
数据备份：执行成员删除、模式切换等关键操作前，需对集群数据进行全量备份，防止操作失误导致数据丢失。
网络与解析 ：集群节点间需确保 3306（数据库端口）、33061（组复制端口）等端口互通；若使用主机名（如 maria-03），需配置节点间的主机名解析（如 /etc/hosts）。
状态校验 ：所有操作前后均建议执行 cluster.status() 校验集群状态，确保无 ERROR 或 OFFLINE 节点后再继续操作。

结语

本文整理的命令覆盖了 InnoDB Cluster 从连接、查询到成员管理、模式切换的核心场景，是日常运维的"工具箱"。实际使用中，需结合业务场景（如单主/多主、读写分离）与集群规模灵活调整，同时建议参考 MySQL 官方文档深入理解命令背后的原理，确保集群长期稳定运行。