基于Helm在K8s集群中部署MySQL 8.0高可用架构：一主两从实战指南

1. 环境准备与Helm基础配置在开始部署MySQL 8.0高可用架构之前我们需要确保Kubernetes集群环境已经就绪。我建议使用至少3个节点的集群这样能够更好地分散主从节点的负载。记得上次我在测试环境只用两个节点时就遇到过节点故障导致服务中断的情况。首先检查kubectl和helm的版本兼容性。实测发现helm 3.8与k8s 1.22的组合最稳定运行以下命令验证环境kubectl version --short helm version接下来添加bitnami的helm仓库这个仓库维护了大量经过生产验证的数据库chart。我比较过多个仓库bitnami的更新频率和文档支持都是最好的helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update对于持久化存储根据我的踩坑经验建议提前准备好StorageClass。如果是测试环境可以使用local-path但生产环境强烈建议用云厂商的块存储或者配置好的NFS。曾经有个项目因为用了hostPath存储节点宕机后数据全丢教训深刻。2. 定制MySQL Helm Chart参数下载MySQL chart后重点需要修改values.yaml文件。这个文件有400多行配置但实际需要关注的只有几个关键部分。我把它们整理成几个配置组认证配置组auth: rootPassword: YourStrongPassword123! database: app_db username: app_user password: UserPassword456! replicationUser: replicator replicationPassword: ReplicaPass789!架构配置组architecture: replication # 必须设为replication才能启用主从 primary: name: mysql-primary secondary: name: mysql-secondary replicaCount: 2 # 两个从节点存储配置组primary: persistence: storageClass: ssd-storageclass size: 50Gi secondary: persistence: storageClass: ssd-storageclass size: 50Gi性能调优组primary: configuration: |- [mysqld] innodb_buffer_pool_size4G max_connections500 sync_binlog1特别提醒root密码不要用简单密码上次我们有个测试环境被黑了就是因为用了默认密码。建议生成随机密码并存入Kubernetes Secret。3. 部署与验证主从架构执行部署命令时我习惯加上--atomic参数这样如果部署失败会自动回滚helm install mysql-cluster bitnami/mysql \ --version9.7.0 \ -f values.yaml \ --atomic \ --timeout 10m部署完成后验证Pod状态应该看到1个主节点和2个从节点kubectl get pods -l app.kubernetes.io/instancemysql-cluster主从复制验证是个关键步骤。我通常用这个三板斧在主库创建测试数据在从库查询是否同步检查复制状态具体操作# 连接到主库 kubectl run mysql-client --rm -i --tty \ --image docker.io/bitnami/mysql:8.0.32 \ --env MYSQL_HOSTmysql-cluster-primary \ --env MYSQL_PASSWORDYourStrongPassword123! \ -- mysql -u root -p$MYSQL_PASSWORD -h $MYSQL_HOST -e CREATE DATABASE test_sync; # 连接到任意从库验证 kubectl run mysql-client --rm -i --tty \ --image docker.io/bitnami/mysql:8.0.32 \ --env MYSQL_HOSTmysql-cluster-secondary \ --env MYSQL_PASSWORDYourStrongPassword123! \ -- mysql -u root -p$MYSQL_PASSWORD -h $MYSQL_HOST -e SHOW DATABASES;如果看到test_sync数据库说明复制正常工作。还可以检查更详细的复制状态kubectl exec mysql-cluster-primary-0 -- mysql -uroot -p$ROOT_PASSWORD -e SHOW MASTER STATUS\G kubectl exec mysql-cluster-secondary-0 -- mysql -uroot -p$ROOT_PASSWORD -e SHOW SLAVE STATUS\G4. 高可用保障与故障处理在生产环境运行MySQL集群还需要考虑以下几个高可用场景主节点故障恢复 当主节点宕机时我们需要快速检测并故障转移。可以通过配置livenessProbe来实现自动恢复primary: livenessProbe: enabled: true initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 command: - sh - -c - mysqladmin ping -uroot -p${MYSQL_ROOT_PASSWORD}从节点延迟监控 在主库执行以下命令监控复制延迟SHOW SLAVE HOSTS; SELECT * FROM performance_schema.replication_group_member_stats;备份策略 建议配置定期备份可以使用k8s的CronJob配合mysqldumpkubectl create cronjob mysql-backup \ --imagedocker.io/bitnami/mysql:8.0.32 \ --schedule0 2 * * * \ --envMYSQL_HOSTmysql-cluster-primary \ --envMYSQL_PASSWORDYourStrongPassword123! \ -- mysqldump -u root -p$MYSQL_PASSWORD -h $MYSQL_HOST --all-databases /backups/mysql-$(date \%Y\%m\%d).sql遇到主从不同步时我常用的修复步骤是停止从库复制STOP SLAVE;重新配置主库信息开始复制START SLAVE;检查错误日志SHOW SLAVE STATUS\G5. 性能优化实战技巧根据线上运行经验这几个参数对MySQL 8.0在k8s中的性能影响最大InnoDB缓冲池configuration: |- [mysqld] innodb_buffer_pool_size4G # 建议分配物理内存的50-70% innodb_buffer_pool_instances4连接池配置primary: resources: limits: memory: 8Gi requests: memory: 8Gi secondary: resources: limits: memory: 4Gi requests: memory: 4Gi网络优化service: type: ClusterIP annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb对于读写分离场景可以配置Service将读请求路由到从节点secondary: service: annotations: service.beta.kubernetes.io/load-balancer-source-ranges: app-server-ip/32监控方面建议启用Prometheus指标metrics: enabled: true serviceMonitor: enabled: true interval: 30s最后提醒一个常见陷阱MySQL的PID文件路径在容器内可能不同需要确保配置正确否则会导致优雅终止失败。我在values.yaml中通常会这样配置primary: configuration: |- [mysqld] pid-file/opt/bitnami/mysql/tmp/mysqld.pid