面试的时候被问倒了一个问题
如果新代码部署的时候,涉及到数据库改动 data migration ,整个改动需要 5 个小时才能完成 请问如何实现 zero downtime deployment ?
比如 ruby on rails ,postgresql 用 puma ,docker 部署
1
TheSixWings 2022-02-20 08:01:56 +08:00
蓝绿部署?
|
2
66450146 2022-02-20 08:13:23 +08:00 via iPhone
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 基本上所有的后端迁移都适用,除非用户量少那可以跳过第四步 |
3
66450146 2022-02-20 08:13:59 +08:00 via iPhone
说错了,可以跳过的是第三步……
|
4
gamesover OP @TheSixWings 我看了一下,蓝绿部署好像并没有直接解决数据库改动的问题
如果新程序对数据库做了改动,导致新程序只能读新数据库中结构,读旧数据库结构就会出错 你怎么逐步迁移? 还要考虑,旧程序在线上时,用户依然会时刻修改数据 反正我没看懂 |
6
disk 2022-02-20 13:11:54 +08:00
如果数据库表结构大幅改动,可以有一个中间层去缓存迁移过程中产生数据库变更,迁移完成后二次同步。不管怎么样,单个用户一定会在某一时刻受到影响,不下线不代表完全无缝。
|
8
66450146 2022-02-20 17:26:31 +08:00 via iPhone
@gamesover 弄两套就是了,在软件里面做适配处理同时有两套的情况,然后数据慢慢迁移,全部复制完并验证以后把旧库放到冷存储里面归档
|
9
gengchun 2022-02-20 20:05:25 +08:00
这个不是面试题有问题,或者你理解有问题。
如果只是数据迁移的话,直接放个数据库代理中间件,然后蓝绿部署切流量就好了。最多就是部署的配置改一下数据库地址这种。 如果是表结构改动。正常的思路是由开发方面负责的。不可能只需要几小时。像 @66450146 说的这个过程会持续很长时间,几个月都有可能。中间可能涉及好几个代码版本。 |
10
wajika 2022-02-24 10:04:11 +08:00
刚好最近遇到类似的问题, 我们是单节点 mysql 数据库,有张大表需要迁移出来,表的大小将近 4.5 千万,select 或是其他方法取数据很慢,用分页的话取到后面 offset 变大就 timeout 了。
我们领导的意思也是 二楼这种思路,两个数据库一起跑,不过我们的 schema 没变。 我觉得这种问题 没有一步到位的解决方法, 既然 schema 变了,那么中间肯定要有路由控制分流了,然后配合二楼说的两套数据库一起跑,应该能解决问题吧? |
11
wajika 2022-02-24 10:05:54 +08:00
其实这种问题,反过来说明,他们的 devops 做的并不好。 至少版本控制没设计
|
12
gamesover OP |
13
wajika 2022-02-25 16:04:10 +08:00
我没接触过,但是既然你都提到 zero downtime deployment 为什么不搜一下,这种解决方案好多,主要还是版本控制。
有个类似的文章你可以参考 https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database |
14
hanyuwei70 2022-09-06 14:56:14 +08:00
改了数据表结构之后的不停机部署必然是开发关心的东西……运维能够做的很有限
|