运维日记丨一次备份恢复过程中引发的服务宕机

新运维新数据 2022-11-12

549

各位新朋友～记得先点蓝字关注我哦～

情景再现

记得有一次做逻辑备份的时候，恢复阶段出现了the server terminated abnormally，我一下子就梦中惊醒忽坐起，以为遇到了什么百年一遇的Bug。

为了确定是不是真的宕机了，随后看了一下pg进程，发现确实不存在postgres相关数据库进程。

既然是数据库的问题，那我们肯定是要去看看最新的数据库错误日志，来判断是什么引起的宕机。

$ tail -50f $PGDATA/log/postgresql-2021-03-30_104942.csv

错误日志显示，NO space left on divice，pg_wal目录下没有空余的设备空间了

查看系统磁盘空间确认磁盘空间信息，证实磁盘空间已经撑满了

所以基本确定是磁盘空间不足导致的异常宕机，那就简单了，已经确定了大致方向，我们接下来就可以看看是哪个环节导致磁盘爆满的根因。从根目录下逐级查看一下哪个目录占用比较大的磁盘空间，追踪到pg_wal目录占用了很大的空间（该磁盘共计100G）

由于在做备份恢复过程中，wal日志也会不断记录必要信息，按照常理来说根据max_wal_size（默认1G）的设置，在wal日志达到阈值的时候会自动清理，那为什么wal日志到了一定量没有被清理掉？带着这个疑问便着手排查wal的相关配置。

1、查看wal日志配置

思考为什么会产生大量的WAL日志，刚提到我最先想到的就是max_wal_size（在自动 WAL 检查点之间允许 WAL 增长到的最大尺寸，简单理解就是WAL日志所在目录的最大保留值，当然也会受其它参数影响），可以在postgresql.conf文件或者postgresql.auto.conf文件中查看，由于数据库无法启动，只能通过查看配置文件中的参数信息来判断，且postgresql.auto.conf优先级比postgresql.conf高。

$ cat $PGDATA/postgresql.conf | grep max_wal_size
或者
$ cat $PGDATA/postgresql.auto.conf | grep max_wal_size

可以看到该配置参数大小仍为默认值1GB，既然这个值正常，那就是其它的影响因素了。

如果由于日志输出率的短期峰值导致超过max_wal_size，不需要的段文件将被移除直到系统回到这个限制以下。低于该限制时，系统会再利用足够的 WAL 文件来覆盖直到下一个检查点之前的需要。如果开启了归档模式，那么归档成功了，才会被清除，但是如果归档命令是失效的，那么WAL目录会一直增长，不会自动删除WAL，会使得此目录被撑爆。既然归档会影响这个值，接下来我们就看看归档的设置。

2、查看归档配置

老方法通过参数文件查看归档相关的参数配置

$ cat $PGDATA/postgresql.conf | grep archive

数据库是开启了归档的而且归档命令也没有写错，顺着这个目录我们看一下归档有没有生成。

$ ls -l pgdata/archivedir/

不幸的是，没有这个归档目录，因此归档命令是无效的，也就导致了WAL目录会一直堆积

关于WAL的异常堆积，还有一个角度可以考虑，那就是关注一下当前实例是否存在备库，如果存在备库，就需要看一下是不是断连了，如果主备库断连了，主库为备库保留必要的WAL不删除而造成膨胀，另外，如果配备了复制槽，更容易发生这种情况。

操作步骤

我们创建该归档目录，并删除一部分数据库日志或者一些不需要的文件来确保能有足够的磁盘空间来启动数据库服务

$ mkdir -p pgdata/archivedir
$ pg_ctl start

手动执行一下切换档操作

$ psql
postgres# select pg_switch_wal();

再查看一下pg_wal目录大小，发现已经清理了堆积的WAL日志文件，并且已经将旧的WAL文件存入了归档目录。

$ du -sh
289M .

实践总结

如果出现类似WAL日志剧增的情况，可以通过以下两个方面排查：

查看是否是主备断连导致的主库日志堆积（包括复制槽的使用）
如果主备关系没有问题或者只是单点的实例，那就检查归档是否失败，查看归档目录的文件时间及连续性，或者通过视图pg_stat_archiver判断归档状态

postgres=# select last_archived_wal,last_archived_time,failed_count,last_failed_time from pg_stat_archiver;
-[ RECORD 1 ]------+--
last_archived_wal  | 000000010000000000000024
last_archived_time | 2021-03-30 16:59:33.788265+08
failed_count       | 0
last_failed_time   |

美创是国内领先的数据库服务提供商。服务团队拥有PG ACED 1名、Oracle&PG ACE 3人、DSI智库专家5名、DSMM测评师7名、OCM 20余人、数十名Oracle OCP、MySQL OCP、TDSQL TCP、OceanBase OBCP、TiDB PTCP、达梦 DCP、人大金仓、红帽RHCA、中间件weblogic、tuxedo、CISP-DSG、CISSP、CDGA、CDPSE、CZTP、CDSP等认证人员，著有《DBA攻坚指南：左手Oracle，右手MySQL》，《Oracle数据库性能优化方法和最佳实践》，《Oracle内核技术揭秘》，《Oracle DBA实战攻略》等多本数据库书籍。运维各类数据库合计5000余套，精通Oracle、MySQL、SQLServer、DB2、PostgreSQL、MongoDB、Redis、TDSQL、OceanBase、达梦、人大金仓等主流商业和开源数据库。美创拥有完善的运维体系和人员培养体系，并同时提供超融合、私有云整体服务解决方案、数据安全咨询及运营服务方案等，已为金融、政府、企业、能源等多个行业的客户提供量身定制的各类服务，赢得了客户的高度赞誉和广泛认可。

数据库 oracle归档模式归档日志

文章转载自新运维新数据，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

运维日记丨一次备份恢复过程中引发的服务宕机

评论