使用克隆将生产数据库迁移到 Percona Everest (MySQL) 的方法
内容提要
本文介绍了将生产数据库迁移到Percona Everest的解决方案，包括了环境分析、配置计算、安装和集群创建、用户对齐和克隆、复制启用以及最后的配置和测试。
延伸解读
克隆前必须对齐系统用户
Percona Everest 使用 Operator 创建 root、operator、xtrabackup、monitor、replication 等系统用户。这些用户必须同样存在于源库中，且权限一致，否则克隆完成后集群无法正常工作。文章建议先用 pt-show-grants 从新集群导出用户创建语句，在源库执行，并检查是否有冲突。此外，还需创建临时迁移用户，在源库授予 backup_admin，在接收端授予 CLONE_ADMIN 等权限，克隆完成后删除。
克隆时需临时禁用 Galera 并阻止 Operator 重启
由于 Galera 库处于活动状态会导致克隆失败，文章指出必须在接收端将 wsrep_provider 设为 none，并停止 Operator 对 Pod 的探针监控。具体做法是：在配置中添加 wsrep_provider=none，待 Pod 启动后，通过 kubectl exec 创建 /var/lib/mysql/sleep-forever 文件，使节点进入无限循环，防止 Operator 重启 Pod。此时集群端点不可用，HAProxy Pod 也会停止，这属于正常现象。克隆完成后需移除该文件和 wsre
克隆后需手动配置异步复制
克隆完成后，新集群的数据与源库在克隆时刻一致，但后续变更需要异步复制来同步。文章提到，Percona Everest v1.0.1 尚未暴露 Operator 原生的远程异步复制功能，因此只能手动配置。需要在源库创建复制用户并授权 REPLICATION SLAVE，在接收端执行 CHANGE REPLICATION SOURCE TO 并启动复制。这种手动方式在 Pod 故障时需人工干预恢复复制，而 Operator 原生方式可自动处理。
迁移后验证与切换注意事项
数据迁移完成后，文章强调必须进行数据完整性验证和性能基准测试。可以使用 mysqlcheck 或 pt-table-checksum 检查一致性，用 sysbench 或 EXPLAIN 分析性能。同时要制定详细的切换计划，包括维护窗口、最终数据同步和切换步骤，并始终备份平台。切换后需设置监控（如 PMM）并更新文档。这些步骤确保迁移后系统稳定可靠。
Q&A
迁移数据库到Percona Everest的第一步是什么？
第一步是了解当前环境，包括CPU、内存和磁盘利用率等。
如何计算迁移所需的资源配置？
可以使用mysqloperatorcalculator工具来计算最佳配置。
在迁移过程中如何确保用户权限一致？
需要对系统用户进行对齐，确保源和目标系统的用户权限一致。
克隆插件的状态如何检查？
可以通过查询INFORMATION_SCHEMA.PLUGINS来检查克隆插件的状态。
如何在迁移后验证数据完整性？
可以使用mysqlcheck或Percona的pt-table-checksum工具进行数据完整性验证。
如何启用异步复制以保持数据库同步？
在源数据库上创建复制用户，并在接收系统上配置复制源以启用异步复制。
