【DB吐槽大會】第17期 - PG 不支援online DDL

背景

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的短暫加排他鎖, 而不是整個過程加排他鎖.

https://github.com/digoal/blog/blob/master/202109/20210902_05.md#postgresql-%E8%AE%B8%E6%84%BF%E9%93%BE%E6%8E%A5 https://github.com/digoal/blog/issues/76