相较于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都能被备份，一些备份工具也通过设置一个replicationslot来控制这一点。备份工具往往不会主动确认复制状态，所以很容易防止WAL被自动清除。PG13之后，replicationslot的WALSIZE得到了很好的控制。PG12之后，WALSIZE的控制参数也设置得更加精细。如果可以通过参数控制，那就把这些参数设置好。第七，误删除数据。PG的DDL是可以回滚的，所以防止误删最重要的就是关掉AUTOCOMMIT。如果你关闭了AUTOCOMMIT，误删数据后不要惊慌，回滚即可。如果已经COMMIT，则无法回滚。所以如果你在做DDL，那只能寄希望于你有一个备份，因为主备数据库不一定能保住你的命。如果没有备份，那你只能从操作系统层面去恢复你的数据文件，然后保存。如果你是做dml操作，那么数据还是会保存的。也可以使用reset_wal工具回滚到提交错误操作之前的点，从而找回数据。今天时间有限，想到这么多，就写这七篇吧。希望这些话对PGDBA有所帮助。
