Kubernetes如何用StatefulSet部署有状态数据库及解决MySQL扩容同步问题

你当前使用的是官方原生MySQL 5.7镜像的单实例StatefulSet部署，没有内置主从数据同步逻辑。StatefulSet扩容时新生成的mysql-1 Pod会基于PVC模板创建全新的空存储卷，初始化空白的MySQL实例，和原有mysql-0 实例之间没有任何数据同步机制，因此会出现第二个副本数据为空的问题。
MySQL本身是单写多读的有状态服务，不能像无状态服务（如Apache）那样直接通过HPA扩容副本就实现负载分担，必须先配置集群同步逻辑。

方案1：手动配置MySQL主从复制适配StatefulSet #

属于轻量化适配方案，无需更换现有部署架构，改造成本低：

• 改造MySQL镜像，新增启动脚本自动识别实例角色：StatefulSet生成的Pod命名固定为mysql-0、mysql-1依次递增，脚本判断Pod序号，序号为0的实例自动配置为master节点，开启binlog、设置唯一server-id；序号≥1的实例自动配置为slave节点
• slave节点启动时通过无头服务的固定DNSmysql-0.mysql连接master，拉取全量备份后开启异步数据同步
• 调整HPA规则，扩容后新增的slave节点会自动完成数据同步，可承担读流量负载，写流量统一转发至master节点即可

方案2：使用成熟MySQL Operator托管集群 #

无需自行开发主从同步逻辑，稳定性更高：

• 可选MySQL官方推出的MySQL Operator for Kubernetes、Percona XtraDB Cluster Operator等成熟开源方案
• Operator会自动管控集群的主从拓扑、数据同步、故障转移、备份恢复全流程，你只需配置集群的规模阈值，即可配合HPA实现自动扩缩容，扩容后新实例会自动加入集群完成全量+增量数据同步

方案3：替换为GKE配套托管数据库 #

运维成本最低，适合生产环境使用：

• 直接使用GCP提供的Cloud SQL for MySQL实例，产品本身内置自动扩缩容、高可用、只读副本自动配置能力，无需自行维护MySQL集群的同步逻辑
• Cloud SQL可通过VPC内网和GKE集群连通，性能和安全性都符合生产级要求

• 原生MySQL集群仅支持单主写入，所有写流量必须统一指向master节点，不能直接将流量负载均衡到所有副本，否则会出现数据不一致问题
• 如果业务需要多节点写入的分布式架构，需替换为支持分布式事务的NewSQL数据库如TiDB等

内容的提问来源于stack exchange，提问作者alex