背景
如同其他數據庫一樣，使用時需要注意一些問題，那麼如何使用PG，可以保證長期穩定。
部署形態設計實踐
根據對可靠性、可恢復性、可用性等等的不同要求，選擇部署形態：
1、分佈式部署（例如pg+citus插件）
容量上限：100節點以上，PB級。
計算能力上限：100節點以上，6400核以上。
讀寫帶寬上限：100節點以上，200GB/s以上。
RPO：如果每個計算節點都採用多副本存儲，RPO=0。
RTO：如果每個計算節點都採用HA，RTO可以做到1分鐘內。
使用限制：有一些SQL限制。
適應場景：應用代碼可控程度高的情況下，適合TP和AP業務。
2、單節點本地存儲
容量上限：10TB級。
計算能力上限：64核級。
讀寫帶寬上限：2GB/s級。
RPO：RPO無保障。
RTO：RTO無保障。
使用限制：SQL無限制。
適應場景：測試環境，非生產環境，對數據庫RPO，RTO都沒有要求的環境。
3、單節點多副本存儲
容量上限：32TB級。
計算能力上限：64核級。
讀寫帶寬上限：2GB/s級。
RPO：單機房RPO=0，（如果存儲支持跨機房多副本，可以做到多機房RPO=0）。
RTO：10分鐘級。
使用限制：SQL無限制。
適應場景：非核心場景生產、測試。
4、雙節點共享存儲
容量上限：32TB級。
計算能力上限：64核級。
讀寫帶寬上限：2GB/s級。
RPO：單機房RPO=0，（如果存儲支持跨機房多副本，可以做到多機房RPO=0）。
RTO：1分鐘級。
使用限制：SQL無限制。
適應場景：核心、非核心場景生產。
5、雙節點主備異步複製
容量上限：32TB級（使用遠程存儲），10TB級（使用本機存儲）
計算能力上限：64核級。
讀寫帶寬上限：2GB/s級。
RPO：10GB網絡，REDO延遲毫秒級、1MB以內。（支持跨機房部署）。心跳機制可確保RPO < 60秒
RTO：1分鐘級。
使用限制：SQL無限制。
適應場景：非核心場景生產。
6、雙節點主備半同步複製
容量上限：32TB級（使用遠程存儲），10TB級（使用本機存儲）
計算能力上限：64核級。
讀寫帶寬上限：2GB/s級。
RPO：
無節點或單一節點異常時，可保證RPO=0。
兩個節點都異常時，RPO取決於備份延遲。採用基於PG流複製的持續REDO備份，可以做到RPO毫秒級。
RTO：1分鐘級。
使用限制：SQL無限制。
適應場景：核心、非核心場景生產。
7、三節點及以上多副本全同步複製
容量上限：32TB級（使用遠程存儲），10TB級（使用本機存儲）
計算能力上限：64核級。
讀寫帶寬上限：2GB/s級。
RPO：
小於半數節點異常時，可保證RPO=0。
半數以上節點異常時，RPO取決於 1、10GB網絡，REDO延遲毫秒級、1MB以內。2、備份延遲。採用基於PG流複製的持續REDO備份，可以做到RPO毫秒級。
RTO：1分鐘級。
使用限制：SQL無限制。
適應場景：核心場景生產。
8、計算存儲分離（存儲多副本）（比如阿里雲POLARDB PG）
容量上限：100TB級。
計算能力上限：16節點，1024核級。
讀寫帶寬上限：32GB/s級。
RPO：單機房RPO=0，（如果存儲支持跨機房多副本，可以做到多機房RPO=0）。
RTO：15秒級。
使用限制：SQL無限制。
適應場景：核心、非核心場景生產。
9、計算存儲分離（存儲多副本）+ 雙機房半同步
容量上限：100TB級。
計算能力上限：16節點，1024核級。
讀寫帶寬上限：32GB/s級。
RPO：
無節點或單一節點異常時，可保證RPO=0。
兩個節點都異常時，RPO取決於備份延遲。採用基於PG流複製的持續REDO備份，可以做到RPO毫秒級。
RTO：15秒級。
使用限制：SQL無限制。
適應場景：核心、非核心場景生產。
10、計算存儲分離（存儲多副本）+ 多機房多副本全同步
容量上限：100TB級。
計算能力上限：16節點，1024核級。
讀寫帶寬上限：32GB/s級。
RPO：
小於半數節點異常時，可保證RPO=0。
半數以上節點異常時，RPO取決於 1、10GB網絡，REDO延遲毫秒級、1MB以內。2、備份延遲。採用基於PG流複製的持續REDO備份，可以做到RPO毫秒級。
RTO：15秒級。
使用限制：SQL無限制。
適應場景：核心場景生產。
11、只讀節點
使用限制：SQL無限制。
適應場景：擴展讀能力。
12、非核心功能
12.1、業務透明的讀寫分離
使用限制：SQL無限制。
適應場景：擴展讀能力。
12.2、跨庫交互
使用限制：SQL無限制。
適應場景：跨庫DBLINK，跨庫外部表，跨庫物化視圖。
12.3、單元化
使用限制：SQL無限制。
適應場景：多實例共享少量數據，多寫。
使用實踐(規約) - 避坑大法
1、連接數過多（2000以上），可能導致性能下降。
建議使用連接池（例如應用程序使用連接池，或者使用pgbouncer之類的連接池）。連接到數據庫的連接在10倍CPU核數以內，達到最高的處理吞吐能力。
2、大吞吐高併發的短連接，性能下降。
建議使用長連接。
3、長連接，長期不釋放重建。如果連接訪問了大量元數據，可能導致內存佔用過大。
建議設置空閒長連接釋放機制。確保不會出現大量內存霸佔的情況。
《PostgreSQL relcache在長連接應用中的內存霸佔"坑"》
4、長事務，以及未結束的2PC事務。
最老事務開始後產生的垃圾版本，無法被垃圾回收進程回收。長事務可能導致垃圾膨脹。
5、業務死鎖
6、檢查點過短
檢查點設置過短，導致FPW狂寫，性能下降嚴重。
建議max wal size, min wal size設置為shared buffer 2倍以及一半。
7、大內存未使用huge page
大內存，未設置shared buffer為huge page，可能導致hash table巨大無比，浪費內存，OOM等連鎖反應。
建議32G以上shared buffer，使用huge page。
8、不合理的索引
導致DML性能下降，SELECT性能下降。
建議刪除，或修改索引定義。
9、不合理的SQL
《PostgreSQL 如何查找TOP SQL (例如IO消耗最高的SQL) (包含SQL優化內容) - 珍藏級》
10、pending list 未合併過大
使用GIN倒排索引，如果寫入量特別大，可能導致PENDING LIST合併不及時，當有大量PENDING LIST數據時，查詢性能下降急劇。
11、ctype使用錯誤，例如要查詢中文模糊查詢加速（pg_trgm），使用ctype=c會導致中文模糊查詢無法使用索引。
《PostgreSQL 中英文混合分詞特殊規則(中文單字、英文單詞) - 中英分明》
12、數據存放不合理導致IO放大
例如空間查詢為切片，組必要條件查詢未分區。
《PostgreSQL 空間切割(st_split, ST_Subdivide)功能擴展 - 空間對象網格化 (多邊形GiST優化)》
《PostgreSQL 空間st_contains，st_within空間包含搜索優化 - 降IO和降CPU(bound box) (多邊形GiST優化)》
13、IO太弱，頻繁更新產生垃圾，垃圾回收不及時，膨脹
建議使用SSD硬盤。
14、關閉自動垃圾回收，會導致垃圾無法自動回收，膨脹。
建議打開自動垃圾回收。
15、長時間鎖等待
業務邏輯問題，長時間鎖等待，可能引發雪崩，連接耗盡等問題。
16、長時間大鎖等待，例如在業務系統中高峰期使用DDL語句，可能導致長時間大鎖等待。引發雪崩。
建議對DDL操作前，加鎖超時參數，避免雪崩。
17、分區過多，導致查詢效率下降，連接內存佔用過大。
建議合理的設置分區數，例如對於高併發頻繁操作的表，建議64個以內分區。對於時間分區表，建議不需要查詢的分區或者已經清理數據的分區，從分區中deatch出去，減少優化器壓力。
18、DDOS
如果對外開放了連接監聽，即使攻擊者沒有密碼，也可以使用DDOS攻擊來消耗數據庫連接，即利用認證超時的時間窗口，大量建連接，等認證超時，實際上已佔用SLOT。導致連接耗盡。
19、濫用超級用戶權限賬號。
建議業務使用普通權限賬號。
20、事務號回捲
如果長事務一直存在並導致了FREEZE無法凍結，超過20億事務後，數據庫為了避免事務號回捲，會強制停庫，需要進入單用戶進行修復。
21、FREEZE風暴
在9.6以前的版本，FREEZE會導致全表掃描，導致IO風暴。可以預測和防止。
《PostgreSQL Freeze 風暴預測續 - 珍藏級SQL》
《PostgreSQL freeze 風暴導致的IOPS飆升 - 事後追溯》
《PostgreSQL的"天氣預報" - 如何預測Freeze IO風暴》
22、slot 堵塞
使用slot進行流複製（邏輯或物理）時，未消耗的日誌會在數據庫中保留（不會被清理），如果消耗日誌很慢可能導致REDO佔用空間巨大，甚至導致膨脹到佔滿磁盤。
有一些SLOT建立後，不需消費它，更加危險。
23、standby feedback
standby 開啟feedback後，standby上面的SQL會反饋給主庫，主庫會延遲迴收垃圾，減少STANDBY的SQL與REDO APPLY回放衝突。
但是如果垃圾產生較多，並且autovacuum nap time 喚醒很頻繁，會導致CPU和IO的升高。
《PostgreSQL物理"備庫"的哪些操作或配置，可能影響"主庫"的性能、垃圾回收、IO波動》
24、delay vacuum
主庫開啟vacuum delay，並且垃圾產生較多，並且autovacuum nap time 喚醒很頻繁，會導致CPU和IO的升高。
原因和23一樣。
25、大表分區
《HTAP數據庫 PostgreSQL 場景與性能測試之 45 - (OLTP) 數據量與性能的線性關係(10億+無衰減), 暨單表多大需要分區》
內部原理
瞭解原理後，知道為什麼要這些最佳實踐
《阿里雲 PostgreSQL 產品生態；案例、開發管理實踐、原理、學習資料、視頻；PG天天象上沙龍記錄 - 珍藏級》
監控
《PostgreSQL Oracle 兼容性之 - performance insight - AWS performance insight 理念與實現解讀 - 珍藏級》
《PostgreSQL 如何查找TOP SQL (例如IO消耗最高的SQL) (包含SQL優化內容) - 珍藏級》
《PostgreSQL AWR報告(for 阿里雲ApsaraDB PgSQL)》
《PostgreSQL 實時健康監控 大屏 - 低頻指標 - 珍藏級》
《PostgreSQL 實時健康監控 大屏 - 高頻指標(服務器) - 珍藏級》
《PostgreSQL 實時健康監控 大屏 - 高頻指標 - 珍藏級》
《PostgreSQL pgmetrics - 多版本、健康監控指標採集、報告》
日常維護
培訓
體系化培訓內容
規範
PostgreSQL 許願鏈接
您的願望將傳達給PG kernel hacker、數據庫廠商等, 幫助提高數據庫產品質量和功能, 說不定下一個PG版本就有您提出的功能點. 針對非常好的提議，獎勵限量版PG文化衫、紀念品、貼紙、PG熱門書籍等，獎品豐富，快來許願。開不開森.