admin 管理员组文章数量: 1086019
2024年3月13日发(作者：帅气撩人高冷动漫男头 冷酷 古风)
PG日常运维中的七个常见问题
相对于
OraCIe
来说，
PG
数据库的运维还是要简单不少的。不知道大量数据库
从
OraCIe
迁移到开源或者国产数据库之后，
DBA
会不会贬值。不过这个过程刚刚
开始的时候，
DBA
不但不会贬值，反而会升值，如果你既能干
OraeIeDBA,
还能干
点
PG/MYSQ1
之类的数据库，那么企业肯定会更倚重你。
与
OraC1e
泛若烟海的知识相比，
PG
的运维确实要简单的多。再加上我们从
OraCIe
将系统迁移到
PG
的时候会做大量的
SQ1
优化，甚至拆分数据库，因此大
多数
PG
数据库的体量也会比
OraCIe
小不少，这也减轻了数据库运维的难度。最
近要给一个客户做一个
PG
数据库日常运维优化中的常见问题的培训，所以我这
两天也在梳理这方面的问题。今天我们就来聊聊
PG
运维中常见的问题吧。
首先是
PG
数据库起不来了，这个问题可能出现在刚刚部署
PG
数据库的时候，
也可能某个库被人瞎搞了一下，就突然起不来了。
PG
数据库的核心是$
PGDATA
目录下的文件结构，如果数据库的文件都是正常的，没有被破坏，那么大概率是
因为环境变量设置，
pg/t1
启动参数或者文件目录的属性错误导致的。如果启动数
据库的时候遇到
7home∕pg∕data"hasinva1idpermissions
这个错误的时候，那么只要纠
正这个目录的访问权限就可以了。如果
PG
数据库因为某些文件损坏而无法启动，
那么幸运的是大部分情况处理起来并不麻烦，使用
reset_wa1
工具去做修复。
其次，数据库如果能正常启动，客户端无法访问数据库服务，这种也是很常
见的情况。一般情况下遇到此类问题有几种情景。一种是网络问题，防火墙等导
致客户端无法访问数据库服务的端口，或者客户端访问服务的端口或者
IP
地址
错误。如果本地的
PSq1
也无法通过
SOeKET
连接
PG
服务，而且端口也没错误。
那么首先我们要检查一下
unixSoCket
的目录：
postgres=#showunix_socket_d1rector1es;
unix-socket_directories
∕tmp
(1row)
postgres=#
这个目录默认是
∕tmp,
查看一下这个目录下的
SoCket
文件是否正常。同时确保
PGDATA
环境变量设置是与
PG
数据库服务的
PGDATA
一致的。
第三，数据库用的好好的，突然
PG
服务就莫名其妙被杀掉了。这时候如果
你查看一下
messages
日志，一般会发现是
SWAP
满了或者系统干脆就没设置
SWAPo
不知道哪位大侠提出的，既然
SWAP
会影响性能，而且我们也不知道
1INUX
啥时候回用
SWAP,
那么我们既然有那么大的物理内存，那还用啥
SWAP,
关闭
SWAP
性能更好。因此现在有不少关闭
SWAP
的拥塞。实际上,在没有弄明白
11NUX
内存管理原理的情况下关闭
SWAP,
是会引发更大的风险的，我们一般不太
建议完全关闭
SwAP,
因为有些特殊情况下，
SWAP
是可以救命的。遇到这种情况，
我们还是建议调整
VM
的
OVerCOmmitmemory
参数，
Swappiness
等参数，以及
NUMA
的相关配置。同时加大
SWAP,
以确保此类现象不再发生。有些老司机建议大家调
整
oomscoreadj
参数，让
OOM
发生的时候不挑
postmaster
等核心
PG
服务进程去下
手，这种方式也是有效的，但是还是那句话，你没弄明白这些机理的时候去盲目
用这些偏方，还是有风险的。设置一个足够大的
SWAP
可能是更好的方法。
第四，白名单配置不正确导致客户端无法访问
PG
数据库服务。对于
PG
数据
库来说，
HBA
配置是默认的，这是确保数据库不被外部随意攻击的一道十分重要
的屏障。作为
PGDBA
来说，做精细的管理是今后避免扯皮的一个十分重要的工
作。因此建议你不要使用
0.0.0.0
这样的配置项，最好把能够访问
PG
数据库的
IP
地址作为粒度来配置，如果不能做到按照
IP
地址配置，也要配置到最小的限制单
元。想要访问你的
PG
数据库，必须是让你知道的，做到这一点，你才能更好的
把控数据库。
pg_
文件修改后，
pg_ct1re1oad
一下就可以更新了，还是十分
方便的。
第五，表元组膨胀或者
FREEZE
问题，死元组过多导致的表膨胀是
ASTORE
存储的数据库的常见问题。表膨胀会影响全表扫码类
SQ1
的性能。而
FREEZE
会
引发写操作被阻塞。这些问题往往是因为
PG
数据库的一些配置问题引发的。我
以前写过一篇文章《
PGAUTOVACUUM
的优化小技巧》，大家有兴趣的话可以去
阅读，因为里面的参数调整还是挺复杂的，这里就不重复了。
第六，
WA1
目录膨胀。
WA1
目录膨胀，导致
PGDATA
目录满了，也是常见
问题。这种情况一般是由于数据库复制或者复制槽的设置存在问题导致的。有些
备份工具为了确保能够备份到所有需要的
WΛ1,
也会通过设置一个复制槽来做这
方面的控制。而备份工具往往不会主动确认复制状态，因此就容易组织
WA1
被
自动清除了。
PG13
后针对复制槽的
WA1SIZE
有了很好的控制，
PG12
后，对
WA1SIZE
的控制参数也有了更精细化的设置。如果能够通过参数控制的，那么就
把这些参数设置好。
第七，误删数据。
PG
的
DD1
都是可以回滚的，因此防误删最重要的是关闭
AUTOCOMMIT
。如果你已经关闭了
AUTOa)MM1T,
那么误删数据后不要惊慌，直
接
ro11back
就可以了。如果真的已经
COMMIT
了，无法回滚了。那么如果你做的
是
DD1,
那么只能期望你有备份了，因为主备库有可能都无法救你的命了。如果没
有备份，那么只能从操作系统层面去
UndeIete
你的数据文件，再去做拯救了。如
果你做的是
dm1
操作，那么数据还是有救的。还可以通过
reset_wa1
工具回退到误
操作提交前的点，从而找回数据。
版权声明：本文标题：PG 日常运维中的七个常见问题 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://roclinux.cn/b/1710300773a566845.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论