五个 PostgreSQL 典型故障案例及处理_postgresql archiver service 运行状况警报(1)

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

autovacuum_vacuum_scale_factor = 0.03

autovacuum_analyze_scale_factor = 0.03

问题得到解决

Postgres11.2版本客户端打开column "p.prolang"问题处理

postgres升级到到11版本后，客户端打开会提示

ERROR:column p.proisagg does not exist
LINE 1:…database d on d.datname=current_database() where p.proisagg…
HINT: Perhaps you meant to reference the column “p.prolang”

无法打开函数功能，如下图：

是数据库服务版本高，客户端版本低引起的，通过下载最新pgadmin4-4.6 问题解决。

2、Postgres11.2版本客户端打开column "p.prolang"问题处理

postgres升级到到11版本后，客户端打开会提示

ERROR:column p.proisagg does not exist
LINE 1:…database d on d.datname=current_database() where p.proisagg…
HINT: Perhaps you meant to reference the column “p.prolang”

无法打开函数功能，如下图

是数据库服务版本高，客户端版本低引起的，通过下载最新pgadmin4-4.6 问题解决。

3、Postgres数据库大批量单表导入数据引发性能故障

因公司经营管理策略原因，我们地区部门还是以开发外包和产品服务为主，对测试外包服务销售工作要求占比不高，而测试部门本来有四五个性能测试人员，加上老员工都比较积极做事在测试团队建设管理上不用花费太多精力。估计因为我对数据库、tomcat、linux性能这块了解比较深以前相关的测试环境都是我搭建部署，一直都很稳定，所以公司让我帮忙兼职做公司产品技术运维支持工作，因此我大部分时间都是在做软件产品基础设施搭建研究MYSQL\PG\TOMCAT\Centos等优化配置和数据安全备份方法，作为初学者很多未知领域需要探索学习研究。

这段时间的运维感触是，做为一名技术运维人员需要一个拥有“耐心、静心、探索心、敬业心”，不然心情一爽rm -rf ，后果不敢设想，或者部署配置时日志格式、清理机制、数据存放路径、备份方式没弄好也会导致系统不稳定等问题。

当然有时客户自己也有专职运维人员，但是往往有些技术运维人员，对数据安全等敏感性没那么高，会误操作导致双方一下子手忙脚乱，例如系统缓慢就restart tomcat 或者kill pid 来应急，但是最终的效果是数据不一致或者丢失等现象。例如下面这个问题就是因为客户一下子插入700W笔数据，但是事先没跟我方项目人员沟通导致系统无法正常运行问题。

下午临近下班时，客户突然打电话给我方项目经理说，系统运行很慢，PG数据库服务器卡死，输入top 都要等五六分钟才能响应，但是CPU使用率不高，如下图：

是看到的数据库服务器CPU使用率确实不高，通过free命令

看到内存将耗尽

通过top看到系统调用KSWAPd0，并运行占用时间比较长，于是我让项目经理打电话问客户说在操作什么，是不是在倒数据？

一开始客户说没做任何操作，但是持续监控一段时间查看了内存使用free一直很低，而且kswapd0进程一直被调度使用，

kswapd0进程的作用：它是虚拟内存管理中，负责换页的，操作系统每过一定时间就会唤醒kswapd ，看看内存是否紧张，如果不紧张，则睡眠，在 kswapd 中，有2 个阀值，pages_hige 和 pages_low，当空闲内存页的数量低于 pages_low 的时候，kswapd进程就会扫描内存并且每次释放出32 个free pages，直到 free page 的数量到达pages_high，由于内存实在不够用了, 于是就死掉了.

这说明一点客户在做大量数据插入操作，导致内存不足，引发系统卡顿，但是客户那边说没做任何操作，我们也怀疑是不是被安全攻击等，作为初级运维人员思维确实比较混乱，没有那么多经验，当时应急方式先重启数据库后，内存立马释放正常，但是没过几分钟又重现问题，这时我们双方打电话沟通了下，原来客户是有在对一张已有百万级数据量的表做迁移插入操作，插入数据也是百万级，知道原因后，也知道对应的表后，查看了该表发现客户在做操作时没有对该表的索引等先删除在插入操作导致系统就慢慢的死掉了。----这也是项目运维管理规范问题导致的。

PG数据库快速INSERT大量数据

临时删除index

有时候我们在备份和导入大量数据时，这个时候可以先把index删除掉。导入在建index。

4、Postgres异常断电导致启动失败解决方法

问题起因：

前段时间客户生产服务器，突然不小心弄断电了，虽然运维人员重启服务后，看似能正常访问，但是出现主从无法正常同步数据问题，而重新启动服务后，报could not connet to server。。。。postgresql/.s.PGSQL.5432，后台日志出现，accepting TCP/IP connections on port 5432等一串错误信息。突发性断电导致异常终止，这是数据库的postmaster.pid 文件仍健在，但是其实不起作用，在后台数据库日志也可以看到如下错误信息，lock file “postmaster.pid” already exists，这时建议先cp 备份另存下，以防改错，然后在直接mv postmaster.pid 迁移到其他地方 ，然后重启数据库服务，即可解决问题。而启动的时候出现启动失败，具体情况请看下下面的文章：《postgres启动失败问题分析与处理 》

原理分析：

当我们启动PostgresSQL时，会在PostgreSQL中的数据文件夹生成postmaster.pid 文件，该文件主要是记录启动时对应的进程号等相关信息，如果该文件已经存在，在启动时，会导致进程号无法对应，最终启动失败，原理如下：

１、26385: 代表Postgres主进程的PID

２、/home/postgresql_data: 代表数据目录

３、5432: 代表数据库监听端口，在postgresql.conf中对应port = 5432

４、5432001 229376:代表的是共享内存的地址(shared memory segments中的key和shmid)。

5、Postgres启动失败问题分析与处理

很多企业使用开源的操作系统例如centos，也是用开源的数据库例如mysql或者postgres，在安装使用过程中经常出现一些不可预知的错误，导致安装失败或者启动失败等。

例如需要安装gcc 或者最新lib等，也有因为安全控件问题阻挡软件正常安装使用，或者有时平常运行好好的，突然重新启动竟然报错，让人捉摸不清问题原因。

这两天客户一个系统使用postgres数据库，做了主从，但是因为断电问题导致主从数据同步出现问题，该项目经理让我帮忙分析处理，出于个人懒，

就找了17年帮他们项目组搭建的postgre现有设置好的主从测试开发环境，该环境持续运行一年半，一直没出现问题，我想模拟下，客户生产

故障，一个原因是模拟直接kill 主库进程，一个模拟强制断电关机看是否能正常启动，并自动主从数据同步，结果世事难料，在模拟直接kill掉进程后，竟然启动不了，具体错误如下：

看了半天错误信息，看到了ERROR: Unable to open policy
//etc/selinux/targeted/policy/policy.30.

[root@DB1 postgresql_data]# journalctl -xe

9月 27 12:43:59 DB1 dbus[784]: [system] Activating service name=‘org.fedoraproject.Setroubleshootd’ (using servicehelper)

9月 27 12:43:59 DB1 dbus-daemon[784]: dbus[784]: [system] Activating service name=‘org.fedoraproject.Setroubleshootd’ (using servicehelper)

9月 27 12:43:59 DB1 dbus-daemon[784]: ERROR: policydb version 30 does not match my version range 15-29

9月 27 12:43:59 DB1 dbus-daemon[784]: ERROR: Unable to open policy //etc/selinux/targeted/policy/policy.30.

9月 27 12:43:59 DB1 python[9716]: detected unhandled Python exception in ‘/usr/sbin/setroubleshootd’

9月 27 12:43:59 DB1 abrt-server[9721]: Not saving repeating crash in ‘/usr/sbin/setroubleshootd’

9月 27 12:43:59 DB1 dbus-daemon[784]: Traceback (most recent call last):

9月 27 12:43:59 DB1 dbus-daemon[784]: File “/usr/sbin/setroubleshootd”, line 30, in

9月 27 12:43:59 DB1 dbus-daemon[784]: from setroubleshoot.util import log_debug

9月 27 12:43:59 DB1 dbus-daemon[784]: File “/usr/lib64/python2.7/site-packages/setroubleshoot/util.py”, line 291, in

9月 27 12:43:59 DB1 dbus-daemon[784]: from sepolicy import get_all_file_types

9月 27 12:43:59 DB1 dbus-daemon[784]: File “/usr/lib64/python2.7/site-packages/sepolicy/init.py”, line 798, in

9月 27 12:43:59 DB1 dbus-daemon[784]: raise e

9月 27 12:43:59 DB1 dbus-daemon[784]: ValueError: Failed to read //etc/selinux/targeted/policy/policy.30 policy file

9月 27 12:43:59 DB1 dbus[784]: [system] Activated service ‘org.fedoraproject.Setroubleshootd’ failed: Launch helper exited with unknown return code 1

9月 27 12:43:59 DB1 dbus-daemon[784]: dbus[784]: [system] Activated service ‘org.fedoraproject.Setroubleshootd’ failed: Launch helper exited with unknown return code 1

9月 27 12:43:59 DB1 dbus-daemon[784]: dbus[784]: [system] Activating service name=‘org.fedoraproject.Setroubleshootd’ (using servicehelper)

9月 27 12:43:59 DB1 dbus[784]: [system] Activating service name=‘org.fedoraproject.Setroubleshootd’ (using servicehelper)

9月 27 12:43:59 DB1 fprintd[9127]: ** Message: No devices in use, exit

9月 27 12:43:59 DB1 dbus-daemon[784]: ERROR: policydb version 30 does not match my version range 15-29

9月 27 12:43:59 DB1 dbus-daemon[784]: ERROR: Unable to open policy //etc/selinux/targeted/policy/policy.30.

修改selinux 比较麻烦，时间有限，我选择流氓做法，直接设置SELINUX=disabled，然后在重新启动postgres，竟然报数据文件目录权限问题，如下：

9月 27 12:37:26 DB1 systemd[1]: Starting PostgreSQL 9.5 database server…

9月 27 12:37:26 DB1 pg_ctl[3560]: < 2018-09-27 12:37:26.211 CST >FATAL: data directory “/home/postgresql_data” has group or world access

9月 27 12:37:26 DB1 pg_ctl[3560]: < 2018-09-27 12:37:26.211 CST >DETAIL: Permissions should be u=rwx (0700).

9月 27 12:37:27 DB1 pg_ctl[3560]: pg_ctl: 无法启动服务器进程

9月 27 12:37:27 DB1 pg_ctl[3560]: 检查日志输出.

9月 27 12:37:27 DB1 systemd[1]: postgresql-9.5.service: control process exited, code=exited status=1

9月 27 12:37:27 DB1 systemd[1]: Failed to start PostgreSQL 9.5 database server.

9月 27 12:37:27 DB1 systemd[1]: Unit postgresql-9.5.service entered failed state.

9月 27 12:37:27 DB1 systemd[1]: postgresql-9.5.service failed.

根据错误信息提示，信息给得很详细，postgresql的数据文件权限被改了，现在不是0700(只有用户权限)。

重新 chmod 700 -R 赋权后重启，问题解决，启动成功，该数据库运行接近两年，一直相安无事，这次竟然报该错误信息。

参考连接 ：
五个 PostgreSQL 典型故障案例及处理 ：https://mp.weixin.qq.com/s/tMSRMZgAHaE1cBE0Yb2X6w

PostgreSQL数据库错误：检测到ShareLock死锁处理
http://www.talkwithtrend.com/Article/244327
postgres11.2版本客户端打开column "p.prolang"问题处理
http://www.talkwithtrend.com/Article/244473

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-29SnDhYF-1713453107587)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！