验证零停机数据库列重命名迁移方案的可行性

本文中的「迁移」指数据库中任何非向后兼容的变更，比如重命名、拆分或删除列。我梳理了零停机重命名字段的最小步骤，希望有实操经验的人帮忙验证思路。前提：必须具备滚动部署能力，否则无法实现零停机迁移

初始状态与目标 #

• 初始状态：生产环境运行V1版本，使用table1.oldColumn
• 目标：零停机将table1.oldColumn重命名为table1.newColumn

迁移步骤 #

1. 新增目标字段：执行SQL创建新列

   ALTER TABLE table1 ADD COLUMN newColumn(...)
   

2. 滚动部署V2版本，代码需包含以下逻辑：
   • 查询操作：仍使用oldColumn，比如SELECT oldColumn FROM table1 WHERE userId = 1001——此时只有oldColumn有完整数据，newColumn仅包含部分数据
   • 更新操作：同时操作两列，若newColumn无值则从oldColumn复制，避免持续变化的oldColumn无法同步
   • 插入操作：同时写入两列，比如INSERT INTO table1 (oldColumn, newColumn) VALUES ('abcd', 'abcd')
   • 删除操作：
     • 常规删除整行不影响列，比如DELETE FROM table1 WHERE userId = 1001
     • 若该列是唯一键，仍使用oldColumn，比如DELETE FROM table1 WHERE oldColumn = 'xyz'
3. 同步历史数据：运行后台脚本，将newColumn中缺失的值从oldColumn复制过去，消除两列数据差异
4. 滚动部署V3版本，代码全量切换为使用newColumn：查询、更新、插入、删除操作均不再依赖table1.oldColumn
5. 清理旧字段：执行SQL删除不再使用的列

   ALTER table1 DROP COLUMN oldColumn
   

注意事项 #

• 步骤3的历史数据同步脚本，可以作为V2版本启动时的数据库迁移步骤执行
• 步骤5的旧字段删除操作，可以作为V3版本启动时的数据库迁移步骤执行

迁移流程回顾 #

1. 初始阶段：newColumn为空，所有数据仅写入oldColumn
2. V1→V2滚动部署阶段：部分实例开始同时写入两列，但仍有V1实例只写oldColumn，此时两列数据存在差异
3. V2全量部署完成：所有新数据都会同时写入两列，通过镜像操作保持同步
4. 历史数据同步前：newColumn缺少创建前的旧数据，以及滚动部署期间V1实例写入的数据
5. 同步脚本执行后：oldColumn中newColumn缺失的数据全部被复制，两列数据完全一致

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