MySQL 集群在线迁移至 Kubernetes 完整指南

背景与适用场景

对于拥有自建 MySQL 集群的运维团队，迁移至 Kubernetes (K8s) 是实现云原生化、提升资源利用率的重要一步。采用在线迁移方式（不停机迁移）能够显著降低业务影响，同时保持极高的数据一致性。本方案适用于希望在保障服务可用性的前提下，完成核心数据库平台升级的场景。

前提条件

• 目标环境熟悉：掌握如 RadonDB MySQL Kubernetes 等主流 K8s 数据库部署工具的使用。
• 版本兼容性：源端自建集群与目标 K8s 集群的 MySQL 大版本号需保持一致（例如均为 MySQL 8.0.x），以避免底层格式不兼容问题。
• 日志开启：源端自建集群必须开启 Binlog 和 GTID 功能，这是后续实现增量同步的基础。

具体操作顺序

第1步：检查并启用源端 GTID

目的：确保源数据库支持基于全局事务ID的一致性复制，防止主从切换时出现数据错乱。
入口/动作：通过超级管理员账号连接源端 MySQL。

1. 检查当前状态：mysql -uroot -e "select @@gtid_mode,@@log_bin";，输出结果应为 1。
2. 若未开启，依次执行以下命令调整参数（注意顺序不可颠倒）：

   set global ENFORCE_GTID_CONSISTENCY = ON;
   set global GTID_MODE = OFF_PERMISSIVE;
   set global GTID_MODE = ON_PERMISSIVE;
   set global GTID_MODE = ON;

第2步：准备目标集群并导入全量数据

目的：在保持目标写入受限的状态下，快速将源端历史数据加载到 K8s 环境中。
关键动作：使用 screen 防止长进程意外中断；锁定写入以确保快照一致性。

1. 安装监控工具：在操作的终端机器上安装 screen：apt install screen -y。
2. 创建持久会话：运行 screen -S migration 建立一个分离式窗口。
3. 锁定写入：建议在 K8s 侧将应用 scale 或暂停写请求。若目标为多副本，先将其缩减以便管理：kubectl scale mysqlcluster sample --replicas=2。
4. 关闭 Raft 协议干扰：针对 Follower 节点禁用 raft 以加速初始化：kubectl exec -it $(kubectl get po -l role=FOLLOWER,mysql.radondb.com/cluster=sample -o jsonpath="{.items[*].metadata.name}") -c xenon -- xenoncli raft disable。
5. 进入 Leader 容器：kubectl exec -it $(kubectl get po -l role=LEADER,mysql.radondb.com/cluster=sample -o jsonpath="{.items[*].metadata.name}") -c mysql -- bash。
6. 执行不落地管道导入：通过 mysqldump 直接管道传输至 MySQL，避免磁盘 I/O 瓶颈。

   mysqldump --all-databases \
   --single-transaction \
   --triggers \
   --routines \
   --events \
   --max-allowed-packet=805306368 \
   --ignore-table=mysql.user \
   --ignore-table=mysql.db \
   --ignore-table=mysql.tables_priv \
   --set-gtid-purged=ON \
   -uroot -h[源端IP] -p[密码]|mysql -uroot -h127.0.0.1

第3步：配置并验证增量同步

目的：在迁移期间持续捕捉源端的新增变更，缩小最终切换的时间窗口。
入口/动作：回到之前的 screen 会话，重新进入 K8s Leader MySQL 容器。

1. 恢复会话：screen -R migration。
2. 进入 MySQL 客户端，配置主从关系（Auto Position 模式）：

   mysql -uroot -h 127.0.0.1
   CHANGE MASTER TO MASTER_HOST='[源端IP]', MASTER_PORT=[端口], MASTER_USER='root', MASTER_PASSWORD='[密码]', MASTER_AUTO_POSITION=1; start slave;

3. 完成判断：观察同步延迟。使用 xenoncli cluster mysql 命令检查 Seconds_Behind 字段，当数值变为 0 时，表示两端数据已完全对齐。

第4步：数据扩散至其余节点

目的：确保整个 K8s 集群的所有 Pod 均获得完整数据副本，以实现高可用。
动作：按顺序标记 Pod 触发重建同步。

1. 以 sample-mysql-1 为例（即前文禁用了 Raft 的节点）：kubectl label pod sample-mysql-1 rebuild=true。
2. 等待该节点完成初始同步：kubectl logs sample-mysql-1 -c init-sidecar -f。
3. 重复上述标记过程处理其他剩余节点（如 sample-mysql-2）：kubectl label pod sample-mysql-2 rebuild=true。
4. 全部完成后，可恢复正常规模：kubectl scale mysqlcluster sample --replicas=3。

第5步：业务割接切换

目的：将生产流量正式转向新的云原生环境。
操作流程：

• 停止旧库写入：切断所有指向自建集群的业务连接。
• 短暂校验：确认 K8s 侧最后一条增量记录也已同步完毕。
• 启动新负载：将应用配置指向 K8s 提供的 DNS 或服务地址。

第6步：清理同步链路

目的：断开不再需要的备份同步通道，释放系统资源。
入口/动作：在 K8s Leader 容器中执行。

stop slave;
reset slave all;

总结与排错建议

通过上述步骤，成功完成了从传统架构到 Kubernetes 的云原生演进。该方法的优势在于对业务透明，极大地缩短了维护窗口。

注意事项：如果在实际操作中发现大量报错（如内存溢出导致 mysqldump 失败），可尝试增加 --max-allowed-packet 参数或分段导出表结构。另外，若业务允许极短时间的停机（秒级），可采用全量锁表 + 全量同步方案，但这会牺牲部分可用性。

以上就是 MySQL 集群在线迁移到 Kubernetes 的详细步骤内容，更多关于 SQL 数据库管理与云原生部署的资料请关注本站其它相关文章！