背景
1、产品的问题点
- PG 不支持online DDL
2、问题点背后涉及的技术原理
- DDL需要加排他锁, 堵塞所有与被锁对象相关的操作, 包括select.
- 当然, PG很多DDL操作不需要table rewrite, 只需要改元数据, 例如加字段, 某些改字段长度的操作(具体见alter table的语法手册).
3、这个问题将影响哪些行业以及业务场景
- 几乎所有行业, 当需要对大表执行DDL(例如发布变更), 而且这个DDL需要table rewrite时.
4、会导致什么问题?
- 当DDL需要table rewrite时. 那么需要长时间持有排他锁, 如果是个被频繁访问的表, 可能长时间影响业务, 甚至需要停业务来执行DDL.
5、业务上应该如何避免这个坑
- 几乎无解, 无法缩短业务影响时间
- 或者在业务设计的时候尽量避免未来发生table rewrite的结构变更, 如修改字段类型(导致底层存储内容发生变化时).
- 使用trigger, PG的继承功能实现, 非常复杂. 一般用户不懂.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 管理复杂度增加
7、数据库未来产品迭代如何修复这个坑
- PG有个插件pg_repack, 在线垃圾回收, 只短暂的加排他锁, 切换数据文件filenode. 可借鉴类似思想, 实现需要table rewrite的DDL的短暂加排他锁, 而不是整个过程加排他锁.
