滚动更新期间如何处理旧版本应用存储的数据库数据？

1. 让新旧服务实现双向数据兼容（核心方案） #

这是零停机部署中处理数据库 schema 变更的关键原则，能从根源避免过渡阶段的数据断层：

• 旧版本服务：修改代码，在创建/更新用户时，除写入username外，还要按业务规则拆分填充firstname和lastname（比如按空格分割、默认填充空值或专属标识）。
• 新版本服务：读取数据时，若firstname/lastname为空，自动从username解析填充；写入数据时，同时更新username和firstname/lastname，保持字段同步。
  如此一来，过渡期间不管是旧还是新版本服务生成的用户数据，两组字段都会有有效值，无需事后补数据。

2. 补充增量数据迁移环节 #

如果旧版本服务无法修改（比如已固化不再迭代），可以调整部署流程，增加增量处理步骤：

• 第一步：执行初始全量迁移，将部署前的username批量拆分为firstname/lastname。
• 第二步：启动滚动/蓝绿部署，在新旧服务共存期间，运行持续增量迁移脚本（或用数据库触发器），实时把旧服务写入的username拆分填充到对应新字段。
• 第三步：确认旧版本服务完全下线后，停止增量迁移，username字段可保留到后续版本再删除。

3. 调整部署顺序（蓝绿部署适配方案） #

如果采用蓝绿部署，可将迁移环节后置，规避过渡阶段的数据问题：

• 第一步：部署新版本服务到蓝环境，暂时不切换流量，新版本仅读取数据库，不执行写入操作（或写入时同时兼容新旧字段）。
• 第二步：执行全量数据迁移，覆盖所有历史用户记录。
• 第三步：将流量切换到新版本服务，此时新版本处理所有读写请求，且写入时同步更新username字段（为回滚留后路）。
• 第四步：确认新版本稳定运行后，后续版本再删除username字段。

流程疏漏说明 #

当前流程的核心问题是仅覆盖了迁移前的历史数据，未考虑过渡阶段的增量数据，且未实现新旧服务的双向数据兼容。零停机部署下的数据库 schema 变更，必须保证「新旧版本服务同时运行时，都能正确读写数据库」，否则必然出现数据不一致的情况。

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