扫一扫
关注微信公众号

PG日常运维中的几个常见问题,你注意到了吗?
2022-12-02   51CTO

  相对于Oracle来说,PG数据库的运维还是要简单不少的。不知道大量数据库从Oracle迁移到开源或者国产数据库之后,DBA会不会贬值。不过这个过程刚刚开始的时候,DBA不但不会贬值,反而会升值,如果你既能干OracleDBA,还能干点PG/MYSQL之类的数据库,那么企业肯定会更倚重你。
 
  与Oracle泛若烟海的知识相比,PG的运维确实要简单的多。再加上我们从Oracle将系统迁移到PG的时候会做大量的SQL优化,甚至拆分数据库,因此大多数PG数据库的体量也会比Oracle小不少,这也减轻了数据库运维的难度。最近要给一个客户做一个PG数据库日常运维优化中的常见问题的培训,所以我这两天也在梳理这方面的问题。今早我们就来聊聊PG运维中常见的问题吧。
 
  首先是PG数据库起不来了,这个问题可能出现在刚刚部署PG数据库的时候,也可能某个库被人瞎搞了一下,就突然起不来了。PG数据库的核心是$PGDATA目录下的文件结构,如果数据库的文件都是正常的,没有被破坏,那么大概率是因为环境变量设置,pg_ctl启动参数或者文件目录的属性错误导致的。如果启动数据库的时候遇到"/home/pg/data"hasinvalidpermissions这个错误的时候,那么只要纠正这个目录的访问权限就可以了。
 
  如果PG数据库因为某些文件损坏而无法启动,那么幸运的是大部分情况处理起来并不麻烦,使用reset_wal工具去做修复。有兴趣了解详情的朋友可以去公众号翻阅我以前写过的一篇文章《上点硬菜:聊聊PG数据库的故障修复》,这里就不重复描述了。
 
  其次,数据库如果能正常启动,客户端无法访问数据库服务,这种也是很常见的情况。一般情况下遇到此类问题有几种情景。一种是网络问题,防火墙等导致客户端无法访问数据库服务的端口,或者客户端访问服务的端口或者IP地址错误。
 
  如果本地的psql也无法通过SOCKET连接PG服务,而且端口也没错误。那么首先我们要检查一下unixsocket的目录:
 
 
  这个目录默认是/tmp,查看一下这个目录下的socket文件是否正常。同时确保PGDATA环境变量设置是与PG数据库服务的PGDATA一致的。
 
  第三,数据库用的好好的,突然PG服务就莫名其妙被杀掉了。这时候如果你查看一下messages日志,一般会发现是SWAP满了或者系统干脆就没设置SWAP。不知道哪位大侠提出的,既然SWAP会影响性能,而且我们也不知道LINUX啥时候回用SWAP,那么我们既然有那么大的物理内存,那还用啥SWAP,关闭SWAP性能更好。因此现在有不少关闭SWAP的拥趸。实际上,在没有弄明白LINUX内存管理原理的情况下关闭SWAP,是会引发更大的风险的,我们一般不太建议完全关闭SWAP,因为有些特殊情况下,SWAP是可以救命的。
 
  遇到这种情况,我们还是建议调整VM的overcommit_memory参数,swappiness等参数,以及NUMA的相关配置。同时加大SWAP,以确保此类现象不再发生。有些老司机建议大家调整oom_score_adj参数,让OOM发生的时候不挑postmaster等核心PG服务进程去下手,这种方式也是有效的,但是还是那句话,你没弄明白这些机理的时候去盲目用这些偏方,还是有风险的。设置一个足够大的SWAP可能是更好的方法。
 
  第四,白名单配置不正确导致客户端无法访问PG数据库服务。对于PG数据库来说,HBA配置是默认的,这是确保数据库不被外部随意攻击的一道十分重要的屏障。作为PGDBA来说,做精细的管理是今后避免扯皮的一个十分重要的工作。因此建议你不要使用0.0.0.0这样的配置项,最好把能够访问PG数据库的IP地址作为粒度来配置,如果不能做到按照IP地址配置,也要配置到最小的限制单元。想要访问你的PG数据库,必须是让你知道的,做到这一点,你才能更好的把控数据库。pg_hba.conf文件修改后,pg_ctlreload一下就可以更新了,还是十分方便的。
 
  第五,表元组膨胀或者FREEZE问题,死元组过多导致的表膨胀是ASTORE存储的数据库的常见问题。表膨胀会影响全表扫码类SQL的性能。而FREEZE会引发写操作被阻塞。这些问题往往是因为PG数据库的一些配置问题引发的。我以前写过一篇文章《PGAUTOVACUUM的优化小技巧》,大家有兴趣的话可以到公众号去阅读,因为里面的参数调整还是挺复杂的,这里就不重复了。
 
  第六,WAL目录膨胀,WAL目录膨胀,导致PGDATA目录满了,也是常见问题。这种情况一般是由于数据库复制或者复制槽的设置存在问题导致的。有些备份工具为了确保能够备份到所有需要的WAL,也会通过设置一个复制槽来做这方面的控制。而备份工具往往不会主动确认复制状态,因此就容易组织WAL被自动清除了。PG13后针对复制槽的WALSIZE有了很好的控制,PG12后,对WALSIZE的控制参数也有了更精细化的设置。如果能够通过参数控制的,那么就把这些参数设置好。
 
  第七,误删数据。PG的DDL都是可以回滚的,因此防误删最重要的是关闭AUTOCOMMIT。如果你已经关闭了AUTOCOMMIT,那么误删数据后不要惊慌,直接rollback就可以了。如果真的已经COMMIT了,无法回滚了。那么如果你做的是DDL,那么只能期望你有备份了,因为主备库有可能都无法救你的命了。如果没有备份,那么只能从操作系统层面去undelete你的数据文件,再去做拯救了。如果你做的是dml操作,那么数据还是有救的。还可以通过reset_wal工具回退到误操作提交前的点,从而找回数据。
 
  今天时间有限,也只想到了这么多,就写这七条吧,希望这些文字对PGDBA有所帮助。​

热词搜索:

上一篇:数据安全“体检”神器!昂楷科技 “数据安全检查工具箱”全新发布
下一篇:最后一页

分享到: 收藏