[译文]PostgreSQL 设备上剩余空间不足！！！

这是夜间呼叫的最常见原因：您的集群空间不足。如今，我们可以动态添加存储，存储很便宜，而且（通常）我们会监控磁盘空间，以免发生这种情况。

无论如何，我们如何处理这样的问题？

为了模拟这样的问题，我创建了一个虚拟主机，并创建了一个大的空文件，几乎填满了文件系统。然后我只是插入了很多行，直到磁盘空间不足。

总图

这是我解决问题的方法：

在此处查找某些步骤的详细信息：

1. 添加更多磁盘和/或删除不必要的文件

无论您做什么，都不要触摸 $PGDATA 中的任何内容。如果 $PGDATA 包含指向其他目录的链接，也不要触及它们。特别是（我再怎么强调也不为过），永远不要触摸名为pg_xlog或的目录pg_wal，也不要触摸名称由 24 个十六进制数字组成的文件。

有一个例外，以防有人想将 Postgres 日志文件存储在 $PGDATA 中。在这种情况下，如果有很多旧的日志文件，您可以删除它们。我强烈建议您将来正确设置日志。

我强烈建议移动您要删除的文件，而不是简单地删除它们。

2. WAL 是否损坏？

一些日志消息应该让您认为 WAL 文件已损坏。这是一个列表：

• 日志：0/2000040 记录中的资源管理器数据校验和不正确
• LOG：无效的主检查点记录
• PANIC：找不到有效的检查点记录

3.修复WAL损坏

修复 WAL 损坏的最佳方法是恢复流式传输到备用或备份工具的 WAL 副本（如果您的备份工具可以流式传输 WAL）。

但是您可能不会流式传输 WAL 文件，或者它们也可能已损坏。在这种情况下，我强烈建议您在尝试使用该工具之前阅读该 工具的整个文档页面pg_resetwal。此外，在使用之前，您应该将 WAL 目录的内容安全地复制到另一个位置。

4.检查数据损坏

Postgres 可以在所有数据页上启用校验和。遗憾的是，默认情况下此模式不处于活动状态，因此在您的集群中情况并非如此的可能性非常高。

无论如何，如果您启用了校验和，pg_checksums请用于检查数据损坏（请参阅文档）。

如果您的集群上禁用了校验和，请尝试使用pg_dumpall（或多个 pg_dump）强制 Postgres 读取您的所有数据并检查是否有任何损坏。如果您有太多数据无法存储生成的文件（或多个文件），请将输出重定向到/dev/null.

Ubuntu下的例子

这就是我在 Ubuntu 下的做法：

root@elinor:/var/lib# pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
13  main    5432 down   postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log
复制

我的 Postgres 没有运行。

root@elinor:/var/lib# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            480M     0  480M   0% /dev
tmpfs            99M   11M   89M  11% /run
/dev/sda1       9.7G  9.7G     0 100% /
tmpfs           493M     0  493M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           493M     0  493M   0% /sys/fs/cgroup
tmpfs            99M     0   99M   0% /run/user/1000

root@elinor:/var/lib# ll -h
total 8.1G
drwxr-xr-x 38 root      root      4.0K Mar  8 14:39 ./
drwxr-xr-x 13 root      root      4.0K Sep 30 15:52 ../
drwxr-xr-x  4 root      root      4.0K Sep 30 15:50 AccountsService/
drwxr-xr-x  2 root      root      4.0K Mar 21 13:58 VBoxGuestAdditions/
drwxr-xr-x  5 root      root      4.0K Mar  9 03:40 apt/
drwxr-xr-x  8 root      root      4.0K Mar 21 13:58 cloud/
drwxr-xr-x  2 root      root      4.0K May  5  2018 command-not-found/
drwxr-xr-x  2 root      root      4.0K Mar  8 14:06 dbus/
drwxr-xr-x  2 root      root      4.0K Apr 16  2018 dhcp/
drwxr-xr-x  2 root      root      4.0K Mar  8 14:06 dkms/
drwxr-xr-x  7 root      root      4.0K Mar  8 14:30 dpkg/
drwxr-xr-x  2 root      root      4.0K Apr 20  2020 git/
drwxr-xr-x  3 root      root      4.0K Sep 30 15:51 grub/
drwxr-xr-x  2 root      root      4.0K Sep 30 15:51 initramfs-tools/
drwxr-xr-x  2 landscape landscape 4.0K Sep 30 15:51 landscape/
drwxr-xr-x  2 root      root      4.0K Mar  9 06:25 logrotate/
drwxr-xr-x  2 root      root         0 Mar 21 14:36 lxcfs/
drwxr-xr-x  2 lxd       nogroup   4.0K Mar 21 13:58 lxd/
drwxr-xr-x  2 root      root      4.0K Sep 30 15:51 man-db/
drwxr-xr-x  2 root      root      4.0K Apr 24  2018 misc/
drwxr-xr-x  2 root      root      4.0K Mar  9 06:25 mlocate/
drwxr-xr-x  2 root      root      4.0K Mar  6  2017 os-prober/
drwxr-xr-x  2 root      root      4.0K Sep 30 15:50 pam/
drwxr-xr-x  2 root      root      4.0K Apr  4  2019 plymouth/
drwx------  3 root      root      4.0K Sep 30 15:49 polkit-1/
drwxr-xr-x  3 postgres  postgres  4.0K Mar  8 14:30 postgresql/
drwxr-xr-x  2 root      root      4.0K Sep 30 15:49 python/
drwxr-xr-x 18 root      root      4.0K Mar 21 14:04 snapd/
drwxr-xr-x  3 root      root      4.0K Sep 30 15:49 sudo/
drwxr-xr-x  6 root      root      4.0K Mar  8 14:06 systemd/
-rw-r--r--  1 root      root      8.0G Mar  8 14:39 test
drwxr-xr-x  2 root      root      4.0K Mar  8 14:06 ubuntu-release-upgrader/
drwxr-xr-x  3 root      root      4.0K Mar  8 14:30 ucf/
drwxr-xr-x  2 root      root      4.0K Feb 17  2020 unattended-upgrades/
drwxr-xr-x  2 root      root      4.0K Mar  8 14:06 update-manager/
drwxr-xr-x  4 root      root      4.0K Mar 21 13:59 update-notifier/
drwxr-xr-x  3 root      root      4.0K Sep 30 15:50 ureadahead/
drwxr-xr-x  2 root      root      4.0K Sep 30 15:50 usbutils/
drwxr-xr-x  3 root      root      4.0K Sep 30 15:49 vim/
复制

/ 文件系统已 100% 满。有一个名为8GB文件test下 /var/lib。

root@elinor:/var/lib# tail /var/log/postgresql/postgresql-13-main.log 
2021-03-08 14:45:08.919 UTC [22579] FATAL:  could not write to file "pg_wal/xlogtemp.22579": No space left on device
复制

仔细检查一下，设备空间不足是 Postgres 停止的根本原因。

root@elinor:/var/lib# rm -f test
root@elinor:/var/lib# du -sh .
243M
复制

我删除了测试文件。

root@elinor:/var/lib# pg_ctlcluster 13 main start
root@elinor:/var/lib# tail /var/log/postgresql/postgresql-13-main.log 
2021-03-21 14:38:49.859 UTC [2414] LOG:  starting PostgreSQL 13.2 (Ubuntu 13.2-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
2021-03-21 14:38:49.860 UTC [2414] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2021-03-21 14:38:49.861 UTC [2414] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-03-21 14:38:49.887 UTC [2420] LOG:  database system was shut down at 2021-03-08 14:45:08 UTC
2021-03-21 14:38:49.963 UTC [2414] LOG:  database system is ready to accept connections.
复制

一旦 Postgres 能够在设备上再次写入，它就会很好地启动。

每当这种事情发生时，保持冷静，你会看到你可以解决它。

文章来源：https://mydbanotebook.org/post/no_space_left_on_device/