☰

PostgreSQL 8.1 の容量不足で停止しました。データディレクトリは空です。

tag-icon • tag-icon linux postgresql disk-space-utilization gentoo data-recovery
PostgreSQL 8.1 の容量不足で停止しました。データディレクトリは空です。

Gentoo/Linux 2.6.14r5 で PostgreSQL 8.1 を使用しました。私の DB サーバーのディスク容量は以下のとおりです。

db postgresql # df -l
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda3              9775248   2018528   7756720  21% /
udev                   1557872        88   1557784   1% /dev
shm                    1557872         0   1557872   0% /dev/shm
/dev/sda4            281096760 244270836  36825924  87% /var/lib/postgresql
/dev/sdb1            961402192 244780080 667785712  27% /mnt/sdb1

/var/lib/postgresql の下のサブディレクトリ data が空なので、./etc/init.d/postgresql を再起動できません。PostgreSQL 8.1 は 8.0 から更新されたため、/var/lib/postgresql に data.old があります。du -b を実行すると、結果は次のようになります。

     postgresql # du -b
471     ./.ssh
580     ./data
7697    ./paul/Fifthwindow-RogersBuck
19673   ./paul/Fifthwindow-Tattoo/Output
20633   ./paul/Fifthwindow-Tattoo
13762   ./paul/Fifthwindow-Beard/Output
14493   ./paul/Fifthwindow-Beard
3036    ./paul/Fifthwindow-Touch1/Output
10789   ./paul/Fifthwindow-Touch1
56931   ./paul
3624120 ./data.old/base/1
3624120 ./data.old/base/10792
3624120 ./data.old/base/10793
48      ./data.old/base/16394/pgsql_tmp
248802448893    ./data.old/base/16394
48      ./data.old/base/backup
248813321469    ./data.old/base
11370   ./data.old/paul/output_files
14332   ./data.old/paul
122952  ./data.old/pg_subtrans
48      ./data.old/pg_twophase
57416   ./data.old/pg_multixact/members
49224   ./data.old/pg_multixact/offsets
106736  ./data.old/pg_multixact
4880603 ./data.old/global
316494192       ./data.old/pg_clog
48      ./data.old/pg_xlog/archive_status
536872320       ./data.old/pg_xlog
48      ./data.old/pg_tblspc
249678076379    ./data.old
27023   ./scripts/cron/daily
917     ./scripts/cron/weekly
28036   ./scripts/cron
861     ./scripts/runOnce
599794  ./scripts/manual
628811  ./scripts
171463723       ./output
249850258001    .

「pg_dump -h my.host.ip.0 -p 5432 -U postgres -F t -b -v -f "/some/directory/backup.file" mydb」を実行すると、以下のメッセージが表示されます。

pg_dump: dumping contents of table _selections_by_content_last30days
pg_dump: dumping contents of table _selections_by_content_last365days
pg_dump: dumping contents of table actionlog
pg_dump: ERROR:  could not count blocks of relation 1663/16394/17943: No such file or directory
pg_dump: SQL command to dump the contents of table "actionlog" failed: PQendcopy() failed.
pg_dump: Error message from server: ERROR:  could not count blocks of relation 1663/16394/17943: No such file or directory
pg_dump: The command was: COPY public.actionlog (eventdetail, eventdatetime, eventtypeid, consoleid, albumid, trackid, sequenceid, sessionid, contentid, actionlogid, fileid) TO stdout;
pg_dump: *** aborted because of error

助けてください！どんなアイデアでも大歓迎です！

ありがとう！

答え1

ついに原因が分かりました。ディスク パーティション フォルダーが1663/16394/17943別の物理ハード ドライブ上に存在していたためです。そのため、まずそれをマウントしてから次の手順を実行する必要がありました。

それは非常に古いシステムでした。幸いなことに、私はもうそれを管理する必要はありませんでした。

答え2

Postgres サーバーはインターネットからアクセス可能でしたか? 最近 Postgres の脆弱性が公開されましたが、バージョン 8.1 は 2010 年からサポートされていないため、セキュリティ更新は受けられませんでした。OS ベンダーがバックポート更新を提供していない場合 (たとえば RHEL5 や CentOS5 など)、このバージョンを使用するのは不合理です。OS カーネルは 2006 年頃のものですが、OS は今でもセキュリティ更新を受け取っていますか?

システムが侵害され、すべてのデータが削除されたようです。バックアップがない場合は、回復不可能だと思います (普通の人間には)。データベース サーバーがまだ実行中の場合は、テーブル単位でデータをダンプしてみてください。 は正常にダンプされたようですが、_selections_by_content_last30daysテーブル_selections_by_content_last30daysはactionlogダンプされていません。データベースがまだ実行中の場合は、削除されたが停止するまで実際には解放されないファイルがいくつか開いている可能性があります。そこに回復可能なデータがある可能性があります。

古い 8.0 リリースのデータは引き続き回復可能ですが、アクセスするには古いバージョンまたは postgres をコンパイルしてインストールする必要があるため、操作が複雑になります。この操作は別のサーバーで行うことをお勧めします。できるだけ早く安全な場所にコピーしてください。

関連情報