PG日常运维中的七个常见问题.docx
PG日常运维中的七个常见问题相对于OraCIe来说，PG数据库的运维还是要简单不少的。不知道大量数据 库从OraCIe迁移到开源或者国产数据库之后，DBA会不会贬值。不过这个过程 刚刚开始的时候，DBA不但不会贬值，反而会升值，如果你既能干OraeIe DBA, 还能干点PG/MYSQL之类的数据库，那么企业肯定会更倚重你。与OraCle泛若烟海的知识相比，PG的运维确实要简单的多。再加上我们从 OraCIe将系统迁移到PG的时候会做大量的SQL优化，甚至拆分数据库，因此大 多数PG数据库的体量也会比OraCIe小不少，这也减轻了数据库运维的难度。最 近要给一个客户做一个PG数据库日常运维优化中的常见问题的培训，所以我这 两天也在梳理这方面的问题。今天我们就来聊聊PG运维中常见的问题吧。首先是PG数据库起不来了，这个问题可能出现在刚刚部署PG数据库的时 候，也可能某个库被人瞎搞了一下，就突然起不来了。PG数据库的核心是$PGDATA 目录下的文件结构，如果数据库的文件都是正常的，没有被破坏，那么大概率是 因为环境变量设置，pg/tl启动参数或者文件目录的属性错误导致的。如果启 动数据库的时候遇到7homepgdata" has invalid permissions这个错误的时 候，那么只要纠正这个目录的访问权限就可以了。如果PG数据库因为某些文件 损坏而无法启动，那么幸运的是大部分情况处理起来并不麻烦，使用reset_wal 工具去做修复。其次，数据库如果能正常启动，客户端无法访问数据库服务，这种也是很常 见的情况。一般情况下遇到此类问题有几种情景。一种是网络问题，防火墙等导 致客户端无法访问数据库服务的端口，或者客户端访问服务的端口或者IP地址 错误。如果本地的PSql也无法通过SOeKET连接PG服务，而且端口也没错误。 那么首先我们要检查一下unix SoCket的目录：postgres=# show unix_socket_d1rectorles;unix-socket_directoriestmp(1 row)postgres=#这个目录默认是tmp,查看一下这个目录下的SoCket文件是否正常。同时 确保PGDATA环境变量设置是与PG数据库服务的PGDATA 一致的。第三，数据库用的好好的，突然PG服务就莫名其妙被杀掉了。这时候如果 你查看一下messages日志，一般会发现是SWAP满了或者系统干脆就没设置 SWAPo不知道哪位大侠提出的，既然SWAP会影响性能，而且我们也不知道LINUX 啥时候回用SWAP,那么我们既然有那么大的物理内存，那还用啥SWAP,关闭 SWAP性能更好。因此现在有不少关闭SWAP的拥塞。实际上,在没有弄明白LlNUX 内存管理原理的情况下关闭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_ctl reload一下就可以更 新了，还是十分方便的。第五，表元组膨胀或者FREEZE问题，死元组过多导致的表膨胀是ASTORE 存储的数据库的常见问题。表膨胀会影响全表扫码类SQL的性能。而FREEZE会 引发写操作被阻塞。这些问题往往是因为PG数据库的一些配置问题引发的。我 以前写过一篇文章PG AUTOVACUUM的优化小技巧，大家有兴趣的话可以去阅 读，因为里面的参数调整还是挺复杂的，这里就不重复了。第六，WAL目录膨胀。WAL目录膨胀，导致PGDATA目录满了，也是常见问 题。这种情况一般是由于数据库复制或者复制槽的设置存在问题导致的。有些 备份工具为了确保能够备份到所有需要的WL,也会通过设置一个复制槽来做 这方面的控制。而备份工具往往不会主动确认复制状态，因此就容易组织WAL 被自动清除了。PG 13后针对复制槽的WAL SIZE有了很好的控制，PG 12后， 对WAL SIZE的控制参数也有了更精细化的设置。如果能够通过参数控制的，那 么就把这些参数设置好。第七，误删数据。PG的DDL都是可以回滚的，因此防误删最重要的是关闭 AUTOCOMMIT。如果你已经关闭了 AUTOa)MMlT,那么误删数据后不要惊慌，直接 rollback就可以了。如果真的已经COMMIT 了，无法回滚了。那么如果你做的是 DDL,那么只能期望你有备份了，因为主备库有可能都无法救你的命了。如果没 有备份，那么只能从操作系统层面去UndeIete你的数据文件，再去做拯救了。 如果你做的是dml操作，那么数据还是有救的。还可以通过reset_wal工具回 退到误操作提交前的点，从而找回数据。
