【DB吐槽大會】第10期 - 不支援 flashback query

背景

1、産品的問題點

• 沒有Query級别的閃回功能, 當發生DML誤操作後, 恢複資料比較困難.

2、問題點背後涉及的技術原理

• flashback query屬于查詢“資料”在過去某個時刻的狀态, 實作方法舉例:
• 需要有舊的tuple版本, 以及事務送出或復原狀态, 事務結束時間的資訊.

• • 這種實作方法需要保留舊版本和事務結束時間, 可能導緻UNDO資料膨脹.

• 或: 采用快照, 通過快照+WAL回放的形式回到過去狀态.

• • 這種實作方法需要支援快照, 可能導緻額外的copy on write開銷

• 最好僅僅針對重點表開啟閃回功能.

3、這個問題将影響哪些行業以及業務場景

• 所有行業

4、會導緻什麼問題?

• 發生DML誤操作後, 依賴備份+時間點恢複功能. 恢複資料比較困難.

5、業務上應該如何避免這個坑

• 資料備份+WAL歸檔, 時間點恢複後将資料導出, 再導入到生産環境.
• 使用觸發器, 将DML的UNDO操作記錄下來, 使用UNDO語句復原.
• 使用快照檔案系統, 例如ZFS, 在ZFS上建立實體流複制從庫, 當需要恢複時通過快照+WAL回放的形式回到過去狀态. 将資料導出, 再導入到生産環境.

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 管理難道較大, 一般開發人員不懂, 較為複雜度

7、資料庫未來産品疊代如何修複這個坑

• 核心層支援: 表級别多版本管理, 同時使用UNDO復原段代替資料檔案記憶體儲多版本.
• 核心層支援, partial PIRT. 表級别的資料檔案+WAL時間點恢複.

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