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

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

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

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

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

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

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

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

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

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

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

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

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

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