?相對于Oracle來說，PG數(shù)據(jù)庫的運維還是要簡單不少的。不知道大量數(shù)據(jù)庫從Oracle遷移到開源或者國產數(shù)據(jù)庫之后，DBA會不會貶值。不過這個過程剛剛開始的時候，DBA不但不會貶值，反而會升值，如果你既能干Oracle DBA，還能干點PG/MYSQL之類的數(shù)據(jù)庫，那么企業(yè)肯定會更倚重你。

與Oracle泛若煙海的知識相比，PG的運維確實要簡單的多。再加上我們從Oracle將系統(tǒng)遷移到PG的時候會做大量的SQL優(yōu)化，甚至拆分數(shù)據(jù)庫，因此大多數(shù)PG數(shù)據(jù)庫的體量也會比Oracle小不少，這也減輕了數(shù)據(jù)庫運維的難度。最近要給一個客戶做一個PG數(shù)據(jù)庫日常運維優(yōu)化中的常見問題的培訓，所以我這兩天也在梳理這方面的問題。今早我們就來聊聊PG運維中常見的問題吧。

首先是PG數(shù)據(jù)庫起不來了，這個問題可能出現(xiàn)在剛剛部署PG數(shù)據(jù)庫的時候，也可能某個庫被人瞎搞了一下，就突然起不來了。PG數(shù)據(jù)庫的核心是$PGDATA目錄下的文件結構，如果數(shù)據(jù)庫的文件都是正常的，沒有被破壞，那么大概率是因為環(huán)境變量設置，pg_ctl啟動參數(shù)或者文件目錄的屬性錯誤導致的。如果啟動數(shù)據(jù)庫的時候遇到"/home/pg/data" has invalid permissions這個錯誤的時候，那么只要糾正這個目錄的訪問權限就可以了。

如果PG數(shù)據(jù)庫因為某些文件損壞而無法啟動，那么幸運的是大部分情況處理起來并不麻煩，使用reset_wal工具去做修復。有興趣了解詳情的朋友可以去公眾號翻閱我以前寫過的一篇文章《上點硬菜：聊聊PG數(shù)據(jù)庫的故障修復》，這里就不重復描述了。

其次，數(shù)據(jù)庫如果能正常啟動，客戶端無法訪問數(shù)據(jù)庫服務，這種也是很常見的情況。一般情況下遇到此類問題有幾種情景。一種是網(wǎng)絡問題，防火墻等導致客戶端無法訪問數(shù)據(jù)庫服務的端口，或者客戶端訪問服務的端口或者IP地址錯誤。

如果本地的psql也無法通過SOCKET連接PG服務，而且端口也沒錯誤。那么首先我們要檢查一下unix socket的目錄：

這個目錄默認是/tmp，查看一下這個目錄下的socket文件是否正常。同時確保PGDATA環(huán)境變量設置是與PG數(shù)據(jù)庫服務的PGDATA一致的。

第三，數(shù)據(jù)庫用的好好的，突然PG服務就莫名其妙被殺掉了。這時候如果你查看一下messages日志，一般會發(fā)現(xiàn)是SWAP滿了或者系統(tǒng)干脆就沒設置SWAP。不知道哪位大俠提出的，既然SWAP會影響性能，而且我們也不知道LINUX啥時候回用SWAP，那么我們既然有那么大的物理內存，那還用啥SWAP，關閉SWAP性能更好。因此現(xiàn)在有不少關閉SWAP的擁躉。實際上，在沒有弄明白LINUX內存管理原理的情況下關閉SWAP，是會引發(fā)更大的風險的，我們一般不太建議完全關閉SWAP，因為有些特殊情況下，SWAP是可以救命的。

遇到這種情況，我們還是建議調整VM的overcommit_memory參數(shù)，swappiness等參數(shù)，以及NUMA的相關配置。同時加大SWAP，以確保此類現(xiàn)象不再發(fā)生。有些老司機建議大家調整oom_score_adj參數(shù)，讓OOM發(fā)生的時候不挑postmaster等核心PG服務進程去下手，這種方式也是有效的，但是還是那句話，你沒弄明白這些機理的時候去盲目用這些偏方，還是有風險的。設置一個足夠大的SWAP可能是更好的方法。

第四，白名單配置不正確導致客戶端無法訪問PG數(shù)據(jù)庫服務。對于PG數(shù)據(jù)庫來說，HBA配置是默認的，這是確保數(shù)據(jù)庫不被外部隨意攻擊的一道十分重要的屏障。作為PG DBA來說，做精細的管理是今后避免扯皮的一個十分重要的工作。因此建議你不要使用0.0.0.0這樣的配置項，最好把能夠訪問PG數(shù)據(jù)庫的IP地址作為粒度來配置，如果不能做到按照IP地址配置，也要配置到最小的限制單元。想要訪問你的PG數(shù)據(jù)庫，必須是讓你知道的，做到這一點，你才能更好的把控數(shù)據(jù)庫。pg_hba.conf文件修改后，pg_ctl reload一下就可以更新了，還是十分方便的。

第五，表元組膨脹或者FREEZE問題，死元組過多導致的表膨脹是ASTORE存儲的數(shù)據(jù)庫的常見問題。表膨脹會影響全表掃碼類SQL的性能。而FREEZE會引發(fā)寫操作被阻塞。這些問題往往是因為PG數(shù)據(jù)庫的一些配置問題引發(fā)的。我以前寫過一篇文章《PG AUTOVACUUM的優(yōu)化小技巧》，大家有興趣的話可以到公眾號去閱讀，因為里面的參數(shù)調整還是挺復雜的，這里就不重復了。

第六，WAL目錄膨脹，WAL目錄膨脹，導致PGDATA目錄滿了，也是常見問題。這種情況一般是由于數(shù)據(jù)庫復制或者復制槽的設置存在問題導致的。有些備份工具為了確保能夠備份到所有需要的WAL，也會通過設置一個復制槽來做這方面的控制。而備份工具往往不會主動確認復制狀態(tài)，因此就容易組織WAL被自動清除了。PG 13后針對復制槽的WAL SIZE有了很好的控制，PG 12后，對WAL SIZE的控制參數(shù)也有了更精細化的設置。如果能夠通過參數(shù)控制的，那么就把這些參數(shù)設置好。

第七，誤刪數(shù)據(jù)。PG 的DDL都是可以回滾的，因此防誤刪最重要的是關閉AUTOCOMMIT。如果你已經(jīng)關閉了AUTOCOMMIT，那么誤刪數(shù)據(jù)后不要驚慌，直接rollback就可以了。如果真的已經(jīng)COMMIT了，無法回滾了。那么如果你做的是DDL，那么只能期望你有備份了，因為主備庫有可能都無法救你的命了。如果沒有備份，那么只能從操作系統(tǒng)層面去undelete你的數(shù)據(jù)文件，再去做拯救了。如果你做的是dml操作，那么數(shù)據(jù)還是有救的。還可以通過reset_wal工具回退到誤操作提交前的點，從而找回數(shù)據(jù)。

今天時間有限，也只想到了這么多，就寫這七條吧，希望這些文字對PG DBA有所幫助。?