減少大型 postgresql 數據庫的遷移時間
我們有一個postgresql 9.4 DB 伺服器，它處理2 個 DB，每個**~800GB**。尚未實施複制。
我們使用 -j 和 -Fd 選項將 pg_dump 時間減少到大約 2 小時。
問題是，我們需要分離 DB，所以我們用 Postgresql 9.6 設置了一個全新的伺服器，但是 pg_restore 需要很長時間（~2 天）。我嘗試使用 -j 並行 pg_restore （4、8、16，雖然 VM 有4 核 CPU和16GB 的 RAM ）並調整****posotgresql.conf中的一些參數，如shared_buffers、Effective_cache_size、work_mem、maintenance_work_mem、wal_buffers等等，但他們對減少恢復時間沒有任何顯著影響。
甚至，我嘗試分別恢復數據和架構，但結果相同。我認為問題是我們有許多具有 15M 記錄的表，它們都有索引，索引會增加恢復時間，但我不確定
我們考慮了複製，所以我們沒有任何明顯的停機時間（同步完成後，我們可以停止舊/主伺服器並將副本/從伺服器更改為主伺服器），但是由於postgresql 伺服器的版本不同，它沒有成功！將主伺服器 postgresql 版本更新到 9.6 然後開始複製將需要這麼長時間！
任何意見和建議將不勝感激！
一個常見問題解答。
pg_upgradewith--link（但要明白你不能輕易回去）；- 邏輯流複製
pglogical- 使用 Londiste 等基於觸發器的邏輯複製
搜尋零停機時間或低停機時間的 PostgreSQL 主要版本升級。
雖然pglogical似乎是一個很棒的工具，但我並沒有採取和破壞 Debian 的 Postgresql 包的穩定性和可靠性。另一方面，我發現我可以通過在硬體資源和 postgresql.conf 文件中的配置和pg_restore 命令的**-j選項之間取得良好平衡來減少恢復時間。**
例如，使用 2*2 核心 CPU、32 GB RAM 和**-j 32**的恢復時間超過 16 小時。
最後，具有 2*2 核心 CPU、16 GB RAM 和**-j 16**的 pg_restore為我解決了。我花了5小時17分鐘！