如果有大量数据需要 data migration，如何实现 zero downtime deployment?

[gamesover]

面试的时候被问倒了一个问题

如果新代码部署的时候，涉及到数据库改动 data migration ，整个改动需要 5 个小时才能完成 请问如何实现 zero downtime deployment ？

比如 ruby on rails ，postgresql 用 puma ，docker 部署

[TheSixWings]

蓝绿部署?

[66450146]

1. Make the application able to run on either backend
2. Make the new backend and run it in parallel with the old one
3. Migrate the data incrementally by enrolling a small percentage of users to the new backend
4. Enroll all users in the new backend and create all new data into the new backend
5. Backfill old data into the new backend

基本上所有的后端迁移都适用，除非用户量少那可以跳过第四步

[66450146]

说错了，可以跳过的是第三步……

[gamesover]

@TheSixWings 我看了一下，蓝绿部署好像并没有直接解决数据库改动的问题

如果新程序对数据库做了改动，导致新程序只能读新数据库中结构，读旧数据库结构就会出错

你怎么逐步迁移？

还要考虑，旧程序在线上时，用户依然会时刻修改数据

反正我没看懂

[gamesover]

@66450146 对应的数据库呢？弄两套吗？说实话，没看懂这样子就可以解决数据库问题

[disk]

如果数据库表结构大幅改动，可以有一个中间层去缓存迁移过程中产生数据库变更，迁移完成后二次同步。不管怎么样，单个用户一定会在某一时刻受到影响，不下线不代表完全无缝。

[gamesover]

@disk 谢谢答复

我就是这个意思，看了几遍，好像没看出来，让用户完全不受影响的办法

[66450146]

@gamesover 弄两套就是了，在软件里面做适配处理同时有两套的情况，然后数据慢慢迁移，全部复制完并验证以后把旧库放到冷存储里面归档

[gengchun]

这个不是面试题有问题，或者你理解有问题。

如果只是数据迁移的话，直接放个数据库代理中间件，然后蓝绿部署切流量就好了。最多就是部署的配置改一下数据库地址这种。

如果是表结构改动。正常的思路是由开发方面负责的。不可能只需要几小时。像 @66450146 说的这个过程会持续很长时间，几个月都有可能。中间可能涉及好几个代码版本。

[wajika]

刚好最近遇到类似的问题， 我们是单节点 mysql 数据库，有张大表需要迁移出来，表的大小将近 4.5 千万，select 或是其他方法取数据很慢，用分页的话取到后面 offset 变大就 timeout 了。
我们领导的意思也是 二楼这种思路，两个数据库一起跑，不过我们的 schema 没变。

我觉得这种问题 没有一步到位的解决方法， 既然 schema 变了，那么中间肯定要有路由控制分流了，然后配合二楼说的两套数据库一起跑，应该能解决问题吧？

[wajika]

其实这种问题，反过来说明，他们的 devops 做的并不好。 至少版本控制没设计

[gamesover]

@wajika 你可以两套数据库一起跑，但在一起跑的时候，数据依然在时刻改变

比如一起跑了 1 天，这一天时间旧表的数据也在改动，如何把改动反映到新表中？

[wajika]

我没接触过，但是既然你都提到 zero downtime deployment 为什么不搜一下，这种解决方案好多，主要还是版本控制。
有个类似的文章你可以参考
https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database

[hanyuwei70]

改了数据表结构之后的不停机部署必然是开发关心的东西……运维能够做的很有限