PG 日常運(yùn)維中的七個(gè)常見(jiàn)問(wèn)題

PG日常運(yùn)維中的七個(gè)常見(jiàn)問(wèn)題相對(duì)于Oracle來(lái)說(shuō)，PG數(shù)據(jù)庫(kù)的運(yùn)維還是要簡(jiǎn)單不少的。不知道大量數(shù)據(jù)庫(kù)從Oracle遷移到開(kāi)源或者國(guó)產(chǎn)數(shù)據(jù)庫(kù)之后，DBA會(huì)不會(huì)貶值。不過(guò)這個(gè)過(guò)程剛剛開(kāi)始的時(shí)候，DBA不但不會(huì)貶值，反而會(huì)升值，如果你既能干OracleDBA,還能干點(diǎn)PG/MYSQL之類(lèi)的數(shù)據(jù)庫(kù)，那么企業(yè)肯定會(huì)更倚重你。與Oracle泛若煙海的知識(shí)相比，PG的運(yùn)維確實(shí)要簡(jiǎn)單的多。再加上我們從Oracle將系統(tǒng)遷移到PG的時(shí)候會(huì)做大量的SQL優(yōu)化，甚至拆分?jǐn)?shù)據(jù)庫(kù)，因此大多數(shù)PG數(shù)據(jù)庫(kù)的體量也會(huì)比Oracle小不少，這也減輕了數(shù)據(jù)庫(kù)運(yùn)維的難度。最近要給一個(gè)客戶(hù)做一個(gè)PG數(shù)據(jù)庫(kù)日常運(yùn)維優(yōu)化中的常見(jiàn)問(wèn)題的培訓(xùn)，所以我這兩天也在梳理這方面的問(wèn)題。今天我們就來(lái)聊聊PG運(yùn)維中常見(jiàn)的問(wèn)題吧。首先是PG數(shù)據(jù)庫(kù)起不來(lái)了，這個(gè)問(wèn)題可能出現(xiàn)在剛剛部署PG數(shù)據(jù)庫(kù)的時(shí)候，也可能某個(gè)庫(kù)被人瞎搞了一下，就突然起不來(lái)了。PG數(shù)據(jù)庫(kù)的核心是$PGDATA目錄下的文件結(jié)構(gòu)，如果數(shù)據(jù)庫(kù)的文件都是正常的，沒(méi)有被破壞，那么大概率是因?yàn)榄h(huán)境變量設(shè)置，pg_ctl啟動(dòng)參數(shù)或者文件目錄的屬性錯(cuò)誤導(dǎo)致的。如果啟動(dòng)數(shù)據(jù)庫(kù)的時(shí)候遇到7home/pg/data〃hasinvalidpermissions這個(gè)錯(cuò)誤的時(shí)候，那么只要糾正這個(gè)目錄的訪問(wèn)權(quán)限就可以了。如果PG數(shù)據(jù)庫(kù)因?yàn)槟承┪募p壞而無(wú)法啟動(dòng)，那么幸運(yùn)的是大部分情況處理起來(lái)并不麻煩，使用reset_wal工具去做修復(fù)。其次，數(shù)據(jù)庫(kù)如果能正常啟動(dòng)，客戶(hù)端無(wú)法訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)，這種也是很常見(jiàn)的情況。一般情況下遇到此類(lèi)問(wèn)題有幾種情景。一種是網(wǎng)絡(luò)問(wèn)題，防火墻等導(dǎo)致客戶(hù)端無(wú)法訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)的端口，或者客戶(hù)端訪問(wèn)服務(wù)的端口或者IP地址錯(cuò)誤。如果本地的psql也無(wú)法通過(guò)SOCKET連接PG服務(wù)，而且端口也沒(méi)錯(cuò)誤。那么首先我們要檢查一下unixsocket的目錄：postgres=#showunix_socket_d1rector1es;unix_socket_directories/tmp(1row)postgres=#這個(gè)目錄默認(rèn)是/tmp,查看一下這個(gè)目錄下的socket文件是否正常。同時(shí)確保PGDATA環(huán)境變量設(shè)置是與PG數(shù)據(jù)庫(kù)服務(wù)的PGDATA一致的。第三，數(shù)據(jù)庫(kù)用的好好的，突然PG服務(wù)就莫名其妙被殺掉了。這時(shí)候如果你查看一下messages日志，一般會(huì)發(fā)現(xiàn)是SWAP滿了或者系統(tǒng)干脆就沒(méi)設(shè)置SWAPo不知道哪位大俠提出的，既然SWAP會(huì)影響性能，而且我們也不知道LINUX啥時(shí)候回用SWAP,那么我們既然有那么大的物理內(nèi)存，那還用啥SWAP,關(guān)閉SWAP性能更好。因此現(xiàn)在有不少關(guān)閉SWAP的擁冤。實(shí)際上,在沒(méi)有弄明白LINUX內(nèi)存管理原理的情況下關(guān)閉SWAP,是會(huì)引發(fā)更大的風(fēng)險(xiǎn)的，我們一般不太建議完全關(guān)閉SWAP,因?yàn)橛行┨厥馇闆r下，SWAP是可以救命的。遇到這種情況，我們還是建議調(diào)整VM的overcommit_nieniory參數(shù)，swappiness等參數(shù)，以及NUMA的相關(guān)配置。同時(shí)加大SWAP,以確保此類(lèi)現(xiàn)象不再發(fā)生。有些老司機(jī)建議大家調(diào)整oom_score_adj參數(shù)，讓00M發(fā)生的日寸候不挑postmaster等核心PG服務(wù)進(jìn)程去下手，這種方式也是有效的，但是還是那句話，你沒(méi)弄明白這些機(jī)理的時(shí)候去盲目用這些偏方，還是有風(fēng)險(xiǎn)的。設(shè)置一個(gè)足夠大的SWAP可能是更好的方法。第四，白名單配置不正確導(dǎo)致客戶(hù)端無(wú)法訪問(wèn)PG數(shù)據(jù)庫(kù)服務(wù)。對(duì)于PG數(shù)據(jù)庫(kù)來(lái)說(shuō)，HBA配置是默認(rèn)的，這是確保數(shù)據(jù)庫(kù)不被外部隨意攻擊的一道十分重要的屏障。作為PGDBA來(lái)說(shuō)，做精細(xì)的管理是今后避免扯皮的一個(gè)十分重要的工作。因此建議你不要使用0.0.0.0這樣的配置項(xiàng)，最好把能夠訪問(wèn)PG數(shù)據(jù)庫(kù)的IP地址作為粒度來(lái)配置，如果不能做到按照IP地址配置，也要配置到最小的限制單元。想要訪問(wèn)你的PG數(shù)據(jù)庫(kù)，必須是讓你知道的，做到這一點(diǎn)，你才能更好的把控?cái)?shù)據(jù)庫(kù)。pg_hba.conf文件修改后，pg_ctlreload一下就可以更新了，還是十分方便的。第五，表元組膨脹或者FREEZE問(wèn)題，死元組過(guò)多導(dǎo)致的表膨脹是ASTORE存儲(chǔ)的數(shù)據(jù)庫(kù)的常見(jiàn)問(wèn)題。表膨脹會(huì)影響全表掃碼類(lèi)SQL的性能。而FREEZE會(huì)引發(fā)寫(xiě)操作被阻塞。這些問(wèn)題往往是因?yàn)镻G數(shù)據(jù)庫(kù)的一些配置問(wèn)題引發(fā)的。我以前寫(xiě)過(guò)一篇文章《PGAUTOVACUUM的優(yōu)化小技巧》，大家有興趣的話可以去閱讀，因?yàn)槔锩娴膮?shù)調(diào)整還是挺復(fù)雜的，這里就不重復(fù)了。第六，WAL目錄膨脹。WAL目錄膨脹，導(dǎo)致PGDATA目錄滿了，也是常見(jiàn)問(wèn)題。這種情況一般是由于數(shù)據(jù)庫(kù)復(fù)制或者復(fù)制槽的設(shè)置存在問(wèn)題導(dǎo)致的。有些備份工具為了確保能夠備份到所有需要的WAL,也會(huì)通過(guò)設(shè)置一個(gè)復(fù)制槽來(lái)做這方面的控制。而備份工具往往不會(huì)主動(dòng)確認(rèn)復(fù)制狀態(tài)，因此就容易組織WAL被自動(dòng)清除了。PG13后針對(duì)復(fù)制槽的WALSIZE有了很好的控制，PG12后，對(duì)WALSIZE的控制參數(shù)也有了更精細(xì)化的設(shè)置。如果能夠通過(guò)參數(shù)控制的，那么就把這些參數(shù)設(shè)置好。第七，誤刪數(shù)據(jù)。PG的DDL都是可以回滾的，因此防誤刪最重要的是關(guān)閉AUTOCOMMIT。如果你已經(jīng)關(guān)閉了AUTOCOMMIT,那么誤刪數(shù)據(jù)后不要驚慌，直接rollback就可以了。如果真的已經(jīng)COMMIT了，無(wú)法回滾了。那么如果你做的是DDL,那么只能期望你有備份