假设有 user 微服务和 user 表.
user 微服务新增了一个迭代 v1.0.2 ,但是有一个 break change ,需要:
目前有两种方案:
这里只是举一个例子。
方案 1 感觉用的不少,但个人感觉线上 ddl 还是选择方案 2 dba 处理更稳妥一点, 特别是数据量大时涉及到锁表啥的。
请问什么情况下使用方案 1 ,什么情况下使用方案 2 ?想要各位后端大佬们的一些好的实践方案。
1
sagaxu 20 小时 36 分钟前
大表加个字段可能要锁表几个小时,DBA 处理可以缩短到秒级
|
2
zakokun 20 小时 33 分钟前 1
删除字段这个行为没必要,线上业务从来不应该删除字段;即使要删除,那也是稳定运行了 N 个版本以后,确认没影响了才删除,谁会一上线就急匆匆的删除字段啊
只要不删除字段,那就是正常发布就行了,先加字段,然后发新版本,没啥特别的 |
3
EricXuu 20 小时 19 分钟前 via Android
先找 dba 加字段赋默认值,然后起一个刷数服务刷数。
删除字段不必要。确实要删,先去掉代码里的引用,稳定几个版本后删字段。 |
4
JYii 20 小时 2 分钟前 2
通常 DDL 操作都要走 OA 审批,到 DBA 去操作。
一个点是让开发操作少一点风险;另外一点数据库分配给 web 服务的权限不足,没法操作。 当然你要说你有权限,那应该默认你可以随便搞 |
6
billzhuang 19 小时 11 分钟前
postgres 几乎没有这个问题。
|
9
xuelu520 17 小时 30 分钟前
不走 migrate 。
加入大表加字段什么的操作,锁表好久呢,这种肯定要闲时半夜去执行的。 另外有些字段是要先上线的,不好控制时间。 |
10
ilucio 16 小时 34 分钟前
dba 操作就没事了,rename 的时候找一个
|
13
Tidusy 10 小时 52 分钟前
我这边刚出了一个线上故障。新增字段设置了默认值,上线后 auto-migrate 直接往存量数据刷数,把数据库卡了
|