KubeBlocks中MySQL集群拓扑server-with-orc模式的故障排查与修复

问题背景

在使用KubeBlocks管理MySQL集群时，用户发现当采用server-with-orc拓扑模式时，集群中的所有Pod都被识别为主节点(primary)，这显然不符合预期的主从复制架构设计。该问题出现在KubeBlocks 1.0.0-beta.21版本中，涉及MySQL 8.0.39社区版。

问题现象分析

通过详细检查集群状态，我们发现以下异常情况：

1. 虽然kbcli显示mysql-0为主节点，mysql-1为从节点，但实际运行情况并非如此
2. 两个MySQL实例都能独立创建数据库和表，没有复制约束
3. 半同步复制状态显示为OFF，表明复制机制未正常工作
4. 虽然mysql-1显示有从节点配置，但实际上它仍然可以接受写操作

技术原理探究

在标准的MySQL主从复制架构中，应该满足以下条件：

1. 主节点可以读写，从节点只能读取
2. 所有写入操作应该通过主节点进行，然后复制到从节点
3. 半同步复制确保至少一个从节点接收到数据变更后才向客户端返回成功

server-with-orc拓扑模式本应通过Orchestrator工具自动管理MySQL复制拓扑，实现高可用和故障转移。但在当前实现中，复制配置存在缺陷。

问题根源

经过技术团队深入分析，发现问题的根本原因在于：

1. Orchestrator默认配置不启用半同步复制
2. 没有自动设置从节点的read_only参数
3. 拓扑模式命名变更未完全同步到所有组件（原topology已重命名为orc、orc-proxysql等）

解决方案

技术团队通过以下方式解决了该问题：

1. 在MySQL配置文件中默认启用半同步复制插件
2. 确保从节点自动设置read_only=1
3. 统一拓扑模式的命名规范
4. 完善Orchestrator与MySQL的集成配置

最佳实践建议

对于使用KubeBlocks部署MySQL集群的用户，建议：

1. 明确区分不同拓扑模式的使用场景
2. 部署后验证复制状态和节点角色
3. 监控半同步复制状态确保数据一致性
4. 定期检查集群拓扑健康状态

总结

这次故障排查展示了分布式数据库系统中复制机制的重要性。通过修复server-with-orc拓扑模式的配置问题，KubeBlocks现在能够更可靠地管理MySQL集群的主从复制架构，确保数据的一致性和服务的高可用性。技术团队将继续优化各种拓扑模式的实现，为用户提供更稳定的数据库即服务体验。