Mysql innodb cluster 在什么情况下，节点会发生切换

郑全

MySQL InnoDB Cluster 节点切换（故障转移）情况触发切换的常见场景1. Primary 节点不可用（最常见）

• Primary 节点崩溃（crash）
• Primary 节点网络不通
• MySQL 服务异常停止
• 严重错误导致实例宕机
  

→ Group Replication 自动选举新的 Primary，Secondary 节点自动升主
2. 网络分区（Network Partition）

• 节点之间心跳超时（默认 5 秒）
• 脑裂场景：集群被分割成两个子集，且都无法获得多数票
• 少数派节点会被驱逐（evicted）
  

3. 节点无响应

• InnoDB Cluster 默认 35 秒 超时（group_replication_member_expel_timeout，最大可配置到 3600 秒）
• 节点在超时窗口内无响应 → 被标记为 suspect → 驱逐出集群
• 触发新一轮选举
  

4. 多数派（Quorum）丢失

• 3 节点集群中 2 个节点同时故障
• 剩余节点失去多数派，无法继续接受写入
• 集群进入只读或不可用状态
  

5. 手动触发切换-- 管理员主动发起切换SELECT dba.failover();

• 维护窗口、硬件更换等场景
  

6. 节点严重性能问题

• 节点长期卡住（长时间锁等待、OOM）
• 被路由层（MySQL Router）标记为不健康
• 踢出并切换到其他节点
  

---

切换流程简述Primary 宕机   
↓
Group Replication 检测心跳超时（~5s）   
↓
节点状态 → UNREACHABLE → EVICTED   
↓
剩余节点重新投票获取多数派（quorum）   
↓
选举新的 Primary（通常基于成员优先级）   
↓
MySQL Router 重路由连接   
↓
应用透明切换（读流量自动分发到新 Primary/Secondary）

---

影响切换时间的因素

---

减少意外切换的建议

• 合理设置 expel_timeout，不要设得太小避免网络抖动误判
• 使用 3 节点集群，保证多数派和高可用
• 确保节点间网络稳定（同机房/低延迟链路）
• 监控节点健康（内存、磁盘、连接数）
• 设置合理的成员优先级，重要节点优先成为 Primary
  

郑全

如何检查并确认是什么原因导致发生了切换




MySQL InnoDB Cluster 切换原因排查
1. 查看 Group Replication 状态（第一时间）

-- 查看当前集群成员状态

SELECT * FROM performance_schema.replication_group_members;

-- 查看当前 Primary

SELECT * FROM performance_schema.replication_group_members
WHERE member_role = 'PRIMARY';

-- 查看成员详细信息

SELECT   member_id,  member_host,  member_port,  member_state,  member_role,  member_version
FROM performance_schema.replication_group_members;

关键状态字段：member_state = ONLINE / RECOVERING / UNREACHABLE / OFFLINE

---

2. 查看 Group Replication 消息（判断是否为网络/超时）
-- 查看成员连接/通信统计

SELECT * FROM performance_schema.replication_group_member_stats;

-- 重点关注这些列：
-- count_transactions_checked: 已检查的事务数
-- count_transactions_in_proposal: 待提议的事务数  
-- last_conflict_free_transaction: 最后无冲突事务
-- count_disconnects: 断开次数（关键！）

---

3. 查看错误日志（最重要）
# MySQL 日志路径（根据安装方式）
cat /var/log/mysql/error.log#
或cat /opt/mysql/8.0/data/error.log#

关键搜索词：grep
grep -i "group replication" error.log
grep -i "evict" error.log          # 驱逐相关
grep -i "primary" error.log
grep -i "timeout" error.log
grep -i "unreachable" error.log
grep -i "quorum" error.log
grep -i "member" error.log
典型日志标志：

---

4. MySQL Shell 检查
# 连接管理接口
mysqlsh --uri clusteradmin@localhost:3306
# 查看集群状态
var cluster = dba.getCluster()
cluster.status()
# 查看详细信息（包含各节点延迟、状态）
cluster.status({"extended":1})
# 查看集群拓扑cluster.listRouters()

---

5. 查看切换前后时间点（定位时间线）
-- 查看事务时间线（需要开启 performance_schema）
SELECT   member_id,  COUNT_TRANSACTIONS_ROWS_VALIDATING,  LAST_CONFLICT_FREE_TRANSACTION
FROM performance_schema.replication_group_member_stats;

-- 查看选举信息（MySQL 8.0+）
SELECT   event_name,  timer_wait,  processlist_state
FROM performance_schema.events_transactions_history_long
WHERE thread_id IN
(  SELECT thread_id   FROM performance_schema.replication_group_member_stats)
LIMIT 20;

---

6. 系统层面排查（如果不是 MySQL 自身问题）
# 查看 CPU/内存/OOM
top -b1 | head -20
dmesg | grep -i "oom"
dmesg | grep -i "kill"

# 查看网络丢包/断开
netstat -iip -s link
cat /proc/net/dev
# 查看磁盘 I/O 是否饱和
iostat -x 1 5
dmesg | grep -i "io error"

# 查看 MySQL 进程是否被 OOM Kill
journalctl -u mysql | grep -i "killed"

---

7. 常见切换原因对照

---

快速排查路径
① 查 error.log 关键词
（evict/timeout/quorum/elected）   

↓② 查 performance_schema.replication_group_members
（当时各节点状态）   

↓③ 查 performance_schema.replication_group_member_stats（断开次数）   

↓④ 查系统层面（dmesg/top/netstat）
   排除 OOM/网络   

↓⑤ 综合时间线定位根因