运行 pg_resetxlog 后 PostgreSQL 损坏

0 postgresql postgresql-9.3 barman

我们在 Ubuntu 14.04 上使用 PostgreSQL 9.3 版。这个 PostgreSQL 服务器在我们所有的应用服务器 (Odoo) 之间共享,所以我们让它在单独的环境中运行。

星期六,我们在此数据库服务器上发现磁盘已满问题。在我们进一步调查中,我们发现备份服务器(酒保)已关闭。因此所有存档日志都保留在数据库服务器上。这占用了整个磁盘。我们的数据库备份服务器可能在一个月前停止工作。

通过谷歌搜索,我们找到了一个解决方案,即通过重置 pg_xlog 文件来解决这个问题。所以我们使用 pg_restxlog 命令清理日志文件。正如论坛所说,磁盘已清除,我们重新启动了服务器。但是没有找到数据库:-(。我们使用 psql - list 命令列出。到目前为止没有任何效果。我们也无法从酒保恢复备份。然后我们继续调查,我们发现所有数据都在基本文件夹下保持安全Postgres 的主要数据路径。

我们执行重置日志的步骤如下。

  1. 尝试停止数据库服务器

    须藤服务 postgresql 停止

  2. 以 Postgres 用户身份登录

    须藤 su - postgres

  3. 运行重置命令。

    /usr/lib/postgresql/9.3/bin/pg_resetxlog -f /var/lib/postgresql/9.3/main/

  4. 禁用 postgres.conf 文件中的酒保配置以停止备份过程一段时间。

  5. 并重启服务器

/var/lib/postgresql/9.3/main/的文件内容

postgres@server2:~$ du -h 9.3/main/
12K     9.3/main/pg_notify
28M     9.3/main/base/2735749
73M     9.3/main/base/4172290
46M     9.3/main/base/4410494
81M     9.3/main/base/3002089
43M     9.3/main/base/4282962
47M     9.3/main/base/3377227
130M    9.3/main/base/4098067
44M     9.3/main/base/1682791
58M     9.3/main/base/3377231
4.0K    9.3/main/base/pgsql_tmp
6.1M    9.3/main/base/12030
41M     9.3/main/base/4280118
54M     9.3/main/base/3149391
45M     9.3/main/base/4202614
49M     9.3/main/base/3344071
45M     9.3/main/base/2985056
51M     9.3/main/base/2120822
18G     9.3/main/base/3655712
25M     9.3/main/base/2759574
40M     9.3/main/base/4388978
52M     9.3/main/base/2435773
53M     9.3/main/base/4236740
55M     9.3/main/base/3386464
6.2M    9.3/main/base/12035
201M    9.3/main/base/4112218
54M     9.3/main/base/1625789
635M    9.3/main/base/149656
40M     9.3/main/base/4190162
25M     9.3/main/base/4090019
150M    9.3/main/base/4338686
6.2M    9.3/main/base/1
86M     9.3/main/base/2101485
185M    9.3/main/base/3453985
48M     9.3/main/base/4244883
41M     9.3/main/base/4160039
47M     9.3/main/base/3377180
38M     9.3/main/base/4150310
8.9G    9.3/main/base/2926431
47M     9.3/main/base/1693701
28M     9.3/main/base/4153341
25M     9.3/main/base/2744130
74M     9.3/main/base/2023404
29M     9.3/main/base/3231291
28M     9.3/main/base/2749185
43M     9.3/main/base/4371923
47M     9.3/main/base/3410953
47M     9.3/main/base/4313961
50M     9.3/main/base/4399246
49M     9.3/main/base/3402258
84M     9.3/main/base/3379836
64M     9.3/main/base/2777796
30G     9.3/main/base
5.8M    9.3/main/global
88K     9.3/main/pg_multixact/offsets
256K    9.3/main/pg_multixact/members
348K    9.3/main/pg_multixact
4.0K    9.3/main/pg_xlog/archive_status
33M     9.3/main/pg_xlog
100K    9.3/main/pg_stat_tmp
4.0K    9.3/main/pg_serial
4.0M    9.3/main/pg_clog
4.0K    9.3/main/pg_stat
52K     9.3/main/pg_subtrans
4.0K    9.3/main/pg_tblspc
4.0K    9.3/main/pg_twophase
4.0K    9.3/main/pg_snapshots
30G     9.3/main/
Run Code Online (Sandbox Code Playgroud)

Gab*_*ini 5

我想现在已经太晚了。如果你使用 pg_resetxlog,你需要非常小心,最重要的是,知道你在做什么。

由于 PostgreSQL 的健壮性,在这种情况下您所要做的就是释放 Barman 服务器中的空间,例如删除目录中最旧的备份。然后,一旦空间被回收,PostgreSQL 就可以恢复传送 WAL 文件并自动恢复。

我知道对你来说为时已晚,但我希望我的回复能够在未来帮助某人并阻止他们运行 pg_resetxlog。