本文來自微信公眾號“twt企業(yè)IT社區(qū)”,白鱔(徐戟),南京基石數(shù)據技術有限責任公司技術總監(jiān),在軟件開發(fā)、系統(tǒng)運維、信息系統(tǒng)優(yōu)化、信息系統(tǒng)國產化替代等領域從事技術研究近30年,曾主持開發(fā)了國內首套電信級聯(lián)機實時計費系統(tǒng)、國內首套三檢合一的檢驗檢疫管理系統(tǒng)、銀行綜合大前置平臺(IPP)等大型系統(tǒng)。著有《Oracle RAC日記》、《Oracle DBA優(yōu)化日記》和《DBA的思想天空》等技術專著。信息無障礙研究會專職顧問,深圳市鯤鵬產業(yè)聯(lián)盟高級顧問,Oracle ACE,POSTGRESQL ACE DIRECTOR。個人微信公眾號:白鱔的洞穴
相對于Oracle來說,PG數(shù)據庫的運維還是要簡單不少的。不知道大量數(shù)據庫從Oracle遷移到開源或者國產數(shù)據庫之后,DBA會不會貶值。不過這個過程剛剛開始的時候,DBA不但不會貶值,反而會升值,如果你既能干Oracle DBA,還能干點PG/MYSQL之類的數(shù)據庫,那么企業(yè)肯定會更倚重你。
與Oracle泛若煙海的知識相比,PG的運維確實要簡單的多。再加上我們從Oracle將系統(tǒng)遷移到PG的時候會做大量的SQL優(yōu)化,甚至拆分數(shù)據庫,因此大多數(shù)PG數(shù)據庫的體量也會比Oracle小不少,這也減輕了數(shù)據庫運維的難度。最近要給一個客戶做一個PG數(shù)據庫日常運維優(yōu)化中的常見問題的培訓,所以我這兩天也在梳理這方面的問題。今天我們就來聊聊PG運維中常見的問題吧。
首先是PG數(shù)據庫起不來了,這個問題可能出現(xiàn)在剛剛部署PG數(shù)據庫的時候,也可能某個庫被人瞎搞了一下,就突然起不來了。PG數(shù)據庫的核心是$PGDATA目錄下的文件結構,如果數(shù)據庫的文件都是正常的,沒有被破壞,那么大概率是因為環(huán)境變量設置,pg_ctl啟動參數(shù)或者文件目錄的屬性錯誤導致的。如果啟動數(shù)據庫的時候遇到"/home/pg/data"has invalid permissions這個錯誤的時候,那么只要糾正這個目錄的訪問權限就可以了。
如果PG數(shù)據庫因為某些文件損壞而無法啟動,那么幸運的是大部分情況處理起來并不麻煩,使用reset_wal工具去做修復。
其次,數(shù)據庫如果能正常啟動,客戶端無法訪問數(shù)據庫服務,這種也是很常見的情況。一般情況下遇到此類問題有幾種情景。一種是網絡問題,防火墻等導致客戶端無法訪問數(shù)據庫服務的端口,或者客戶端訪問服務的端口或者IP地址錯誤。
如果本地的psql也無法通過SOCKET連接PG服務,而且端口也沒錯誤。那么首先我們要檢查一下unix socket的目錄:
這個目錄默認是/tmp,查看一下這個目錄下的socket文件是否正常。同時確保PGDATA環(huán)境變量設置是與PG數(shù)據庫服務的PGDATA一致的。
第三,數(shù)據庫用的好好的,突然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ù)據庫服務。對于PG數(shù)據庫來說,HBA配置是默認的,這是確保數(shù)據庫不被外部隨意攻擊的一道十分重要的屏障。作為PG DBA來說,做精細的管理是今后避免扯皮的一個十分重要的工作。因此建議你不要使用0.0.0.0這樣的配置項,最好把能夠訪問PG數(shù)據庫的IP地址作為粒度來配置,如果不能做到按照IP地址配置,也要配置到最小的限制單元。想要訪問你的PG數(shù)據庫,必須是讓你知道的,做到這一點,你才能更好的把控數(shù)據庫。pg_hba.conf文件修改后,pg_ctl reload一下就可以更新了,還是十分方便的。
第五,表元組膨脹或者FREEZE問題,死元組過多導致的表膨脹是ASTORE存儲的數(shù)據庫的常見問題。表膨脹會影響全表掃碼類SQL的性能。而FREEZE會引發(fā)寫操作被阻塞。這些問題往往是因為PG數(shù)據庫的一些配置問題引發(fā)的。我以前寫過一篇文章《PG AUTOVACUUM的優(yōu)化小技巧》,大家有興趣的話可以去閱讀,因為里面的參數(shù)調整還是挺復雜的,這里就不重復了。
第六,WAL目錄膨脹。WAL目錄膨脹,導致PGDATA目錄滿了,也是常見問題。這種情況一般是由于數(shù)據庫復制或者復制槽的設置存在問題導致的。有些備份工具為了確保能夠備份到所有需要的WAL,也會通過設置一個復制槽來做這方面的控制。而備份工具往往不會主動確認復制狀態(tài),因此就容易組織WAL被自動清除了。PG 13后針對復制槽的WAL SIZE有了很好的控制,PG 12后,對WAL SIZE的控制參數(shù)也有了更精細化的設置。如果能夠通過參數(shù)控制的,那么就把這些參數(shù)設置好。
第七,誤刪數(shù)據。PG的DDL都是可以回滾的,因此防誤刪最重要的是關閉AUTOCOMMIT。如果你已經關閉了AUTOCOMMIT,那么誤刪數(shù)據后不要驚慌,直接rollback就可以了。如果真的已經COMMIT了,無法回滾了。那么如果你做的是DDL,那么只能期望你有備份了,因為主備庫有可能都無法救你的命了。如果沒有備份,那么只能從操作系統(tǒng)層面去undelete你的數(shù)據文件,再去做拯救了。如果你做的是dml操作,那么數(shù)據還是有救的。還可以通過reset_wal工具回退到誤操作提交前的點,從而找回數(shù)據。
時間有限,也只想到了這么多,就寫這七條吧,希望這些文字對PG DBA有所幫助。
原題:PG日常運維中的幾個常見問題