PostgreSQL 災難恢復選項
我的客戶有一個相當大的（總“數據”文件夾大小為 200G）PostgreSQL 數據庫，我們正在製定災難恢復計劃。到目前為止，我們已經確定了三種不同類型的災難：硬體中斷、負載過多和由於錯誤執行的錯誤遷移（如 DELETE 或 ALTER TABLE DROP COLUMN）導致的意外數據失去。
前兩種似乎很容易緩解，但我們無法為第三種類型製定一個好的緩解計劃。我建議使用 ZFS 和頻繁（每小時）快照，但“ZFS”現在意味著“OpenIndiana”，我們的 Ops 工程師在這方面沒有太多專業知識，因此使用 OpenIndiana 會帶來另一個風險。同事們試圖說服我，從 PostgreSQL PITR 備份恢復可以和從 ZFS 快照恢復一樣快，但我非常懷疑重播 50G 的存檔 WAL 是否可以被認為是“快速”的。
我們還缺少哪些其他選擇？ZFS 是唯一可行的選擇嗎？我們能否在 Linux 環境中獲得快速的 Pg DB 恢復時間？
為什麼 FreeBSD 不是執行 ZFS 和 PostgreSQL 的可行選擇？FreeBSD ZFS 開發人員與 Illumos 團隊密切合作，最近 Pawel Jakub Dawidek（首先將 ZFS 移植到 FreeBSD 的人）添加了對 ZFS 的 SSD TRIM 支持。這很可能很快也會添加到 Illumos ZFS 程式碼中。
FreeBSD 和 ZFS 的另一個優勢是GEOM框架。在 Solaris 上，當將整個磁碟添加到 ZFS 池中時，ZFS 會自動啟用它們的寫記憶體。當 ZFS 只管理磁碟的離散切片時，不會這樣做，因為它不知道其他切片是否由非寫記憶體安全文件系統（如 UFS）管理。由於其GEOM框架，FreeBSD 實現可以處理分區的磁碟刷新，因此不受此限制。