障害後に Postgres データベースを回復した私の最初の経験 (relatton Base/4123007 のブロック 16490 の無効なページ)

Postgres データベースを完全な機能に復元するという私の最初の成功体験を皆さんと共有したいと思います。 私が Postgres DBMS を知ったのは半年前ですが、それまではデータベース管理の経験がまったくありませんでした。

私は大手 IT 企業で準 DevOps エンジニアとして働いています。 当社では高負荷サービス向けのソフトウェアを開発しており、私はパフォーマンス、保守、導入を担当しています。 私に与えられた標準的なタスクは、XNUMX 台のサーバー上のアプリケーションを更新するというものでした。 アプリケーションは Django で書かれており、更新中に移行 (データベース構造の変更) が実行されます。このプロセスの前に、念のため、標準の pg_dump プログラムを通じて完全なデータベース ダンプを取得します。

ダンプの取得中に予期しないエラーが発生しました (Postgres バージョン 9.5):

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989
pg_dump: The command was: COPY public.ws_log_smevlog [...]
pg_dunp: [parallel archtver] a worker process dled unexpectedly

バグ 「ブロック内に無効なページがあります」 ファイル システム レベルの問題について言及していますが、これは非常に悪いことです。 さまざまなフォーラムで、そうすることが提案されました 完全真空 オプションあり zero_damagged_pa​​ges この問題を解決するために。 さて、試してみましょう...

回復の準備

警告！ データベースを復元する前に、必ず Postgres バックアップを作成してください。 仮想マシンがある場合は、データベースを停止してスナップショットを作成します。 スナップショットを取得できない場合は、データベースを停止し、Postgres ディレクトリの内容 (wal ファイルを含む) を安全な場所にコピーします。 私たちのビジネスで最も重要なことは、事態を悪化させないことです。 読む それ.

データベースは概ね機能したので、通常のデータベース ダンプに限定しましたが、破損したデータのあるテーブルは除外しました (オプション) -T、--exclude-table=TABLE pg_dump 内)。

サーバーは物理的なものであり、スナップショットを取得することはできませんでした。 バックアップは削除されました。次に進みましょう。

ファイルシステムチェック

データベースの復元を試みる前に、ファイル システム自体がすべて正常であることを確認する必要があります。 間違いがあった場合は修正してください。そうしないと事態がさら​​に悪化するだけです。

私の場合、データベースを含むファイルシステムは次の場所にマウントされました。 "/srv" タイプは ext4 でした。

データベースの停止: systemctl停止 [メール保護] ファイル システムが誰にも使用されておらず、次のコマンドを使用してアンマウントできることを確認します。 lsof:
lsof +D /srv

Redis データベースも使用していたので、それを停止する必要がありました。 "/srv"。 次にアンマウントしました / srv (アンマウント)。

ファイルシステムはユーティリティを使用してチェックされました e2fsck スイッチ -f (ファイルシステムがクリーンとマークされている場合でも強制チェック):

次に、ユーティリティを使用して、 ダンペ2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep チェック済み) チェックが実際に実行されたことを確認できます。

e2fsck ext4 ファイル システム レベルでは問題が見つからなかったことが示されています。つまり、データベースの復元を続行するか、元の状態に戻ることができます。 真空がいっぱい (もちろん、ファイル システムをマウントし直してデータベースを起動する必要があります)。

物理サーバーがある場合は、必ずディスクのステータスを確認してください ( スマートctl -a /dev/XXX) または RAID コントローラーを使用して、問題がハードウェア レベルにあるものではないことを確認します。 私の場合、RAID は「ハードウェア」であることが判明したため、ローカル管理者に RAID のステータスを確認するように依頼しました (サーバーは私から数百キロ離れていました)。 間違いはなかったので、間違いなく復旧に着手できるとのことでした。

試み 1: zero_damagged_pa​​ges

スーパーユーザー権限を持つアカウントを使用して psql 経由でデータベースに接続します。 スーパーユーザーが必要です。なぜなら... オプション zero_damagged_pa​​ges 彼だけが変えることができる。 私の場合はpostgresです:

psql -h 127.0.0.1 -U postgres -s [データベース名]

オプション zero_damagged_pa​​ges 読み取りエラーを無視するために必要です (postgrespro Web サイトから):

PostgreSQL は破損したページ ヘッダーを検出すると、通常、エラーを報告し、現在のトランザクションを中止します。 zero_damaged_pa​​ges が有効な場合、システムは代わりに警告を発行し、メモリ内の破損したページをゼロにして、処理を続行します。 この動作により、データ、つまり破損したページ内のすべての行が破壊されます。

このオプションを有効にして、テーブルの完全なバキュームを実行してみます。

VACUUM FULL VERBOSE

残念ながら、運が悪かったです。

同様のエラーが発生しました。

INFO: vacuuming "“public.ws_log_smevlog”
WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page
ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_トースト – 「長いデータ」が 8 ページ (デフォルトでは XNUMXkb) に収まらない場合に Poetgres に保存するメカニズム。

試み 2: インデックスの再作成

Google からの最初のアドバイスは役に立ちませんでした。 数分間検索した後、XNUMX 番目のヒントを見つけました。 インデックスの再作成 破損したテーブル。 このアドバイスは多くの場所で見ましたが、自信を呼び起こすものではありませんでした。 インデックスを再作成しましょう:

reindex table ws_log_smevlog

インデックスの再作成 問題なく完了しました。

ただし、これは役に立ちませんでした、 バキュームフル 同様のエラーでクラッシュしました。 私は失敗には慣れているので、インターネットでさらにアドバイスを探し始めたところ、かなり興味深いものを見つけました。 статью.

試行 3: SELECT、LIMIT、OFFSET

上記の記事では、テーブルを XNUMX 行ずつ調べて問題のあるデータを削除することを提案しています。 まず、すべての行を確認する必要がありました。

for ((i=0; i<"Number_of_rows_in_nodes"; i++ )); do psql -U "Username" "Database Name" -c "SELECT * FROM nodes LIMIT 1 offset $i" >/dev/null || echo $i; done

私の場合、テーブルには次のものが含まれていました 1 628 991 ライン！ 十分な配慮が必要でした データのパーティショニング、しかし、これは別の議論のトピックです。 それは土曜日で、私は tmux で次のコマンドを実行して就寝しました。

for ((i=0; i<1628991; i++ )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog LIMIT 1 offset $i" >/dev/null || echo $i; done

朝までに状況を確認することにしました。 驚いたことに、20 時間後にはデータの 2% しかスキャンされていないことがわかりました。 50日も待ちたくなかった。 またしても完全な失敗。

しかし、私は諦めませんでした。 なぜスキャンにこんなに時間がかかるのか不思議でした。 ドキュメント (やはり postgrespro に関するもの) から、次のことがわかりました。

OFFSET は、行の出力を開始する前に、指定された行数をスキップすることを指定します。
OFFSET と LIMIT の両方が指定されている場合、システムは最初に OFFSET 行をスキップし、次に LIMIT 制約の行のカウントを開始します。

LIMIT を使用する場合は、結果の行が特定の順序で返されるように、ORDER BY 句も使用することが重要です。 そうしないと、行の予測できないサブセットが返されます。

明らかに、上記のコマンドは間違っていました。まず、 order by、結果が間違っている可能性があります。 第二に、Postgres は最初に OFFSET 行をスキャンしてスキップする必要があり、増加するにつれて OFFSET 生産性はさらに低下するでしょう。

試み 4: テキスト形式でダンプを取得します。

そこで、一見素晴らしいアイデアが私の頭に浮かびました。それは、ダンプをテキスト形式で取得し、最後に記録された行を分析するというものです。

まず、テーブルの構造を見てみましょう。 ws_log_smevlog:

私たちの場合、列があります 「Id」、行の一意の識別子 (カウンター) が含まれていました。 計画はこんな感じでした。

1. テキスト形式 (SQL コマンドの形式) でダンプの取得を開始します。
2. 特定の時点で、ダンプはエラーにより中断されますが、テキスト ファイルは引き続きディスクに保存されます。
3. テキスト ファイルの最後を見て、正常に削除された最後の行の識別子 (id) を見つけます。

テキスト形式でダンプを取得し始めました。

pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

予想どおり、ダンプは同じエラーで中断されました。

pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989

さらに進んで tail ダンプの最後を見てみました (末尾 -5 ./my_dump.dump) ID の行でダンプが中断されたことを発見しました 186 525。 「問題は ID 186 526 の行にあり、壊れているので削除する必要があります。」 –私は思いました。 ただし、データベースにクエリを実行すると、次のようになります。
«select * from ws_log_smevlog where id=186529「この行ではすべて問題がないことがわかりました...インデックス 186 ～ 530 の行も問題なく機能しました。 もう一つの「素晴らしいアイデア」は失敗しました。 後になって、なぜこれが起こったのか理解しました。テーブルからデータを削除したり変更したりすると、データは物理的に削除されず、「デッドタプル」としてマークされ、その後、 自動バキューム これらの行を削除済みとしてマークし、これらの行を再利用できるようにします。 理解すると、テーブル内のデータが変更され、自動バキュームが有効になっている場合、データは順次には格納されません。

試行 5: SELECT、FROM、WHERE id=

失敗は私たちを強くします。 決して諦めてはいけません。最後までやり遂げて、自分と自分の能力を信じてください。 そこで、別のオプションを試してみることにしました。データベース内のすべてのレコードを 1 つずつ調べてみることです。 テーブルの構造 (上記を参照) がわかっているので、一意の ID フィールド (主キー) があります。 テーブルには 628 行あり、 id 順番に並んでいます。つまり、XNUMX つずつ確認するだけで済みます。

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

理解できない人のために説明すると、このコマンドは次のように機能します。テーブルを行ごとにスキャンし、stdout を / dev / nullただし、SELECT コマンドが失敗した場合は、エラー テキストが出力され (標準エラー出力がコンソールに送信されます)、エラーを含む行が出力されます ( || のおかげで、選択に問題があったことを意味します (コマンドのリターン コード) 0))ではありません。

幸運なことに、フィールド上にインデックスが作成されていました id:

これは、目的の ID を持つ行を見つけるのにそれほど時間はかからないことを意味します。 理論的には機能するはずです。 さて、コマンドを実行しましょう tmux そして寝ましょう。

朝までに、約 90 件のエントリが閲覧されたことがわかりました。これは 000% 強です。 以前の方法 (5%) と比較すると、優れた結果が得られました。 でも2日も待ちたくなかった…

試行 6: SELECT、FROM、WHERE id >= および id

顧客はデータベース専用の優れたサーバー、つまりデュアルプロセッサを持っていました。 インテルXeon E5-2697 v2、私たちの場所には48ものスレッドがありました！ サーバーの負荷は平均的で、約 20 スレッドを問題なくダウンロードできました。 RAM も十分で、384 ギガバイトもありました。

したがって、コマンドを並列化する必要がありました。

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

ここでは美しくエレガントなスクリプトを書くことができましたが、私は最も速い並列化方法を選択しました。つまり、範囲 0 ～ 1628991 を手動で 100 レコードの間隔に分割し、次の形式の 000 個のコマンドを個別に実行します。

for ((i=N; i<M; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

しかし、それだけではありません。 理論的には、データベースへの接続にもある程度の時間とシステム リソースがかかります。 1 を接続するのはあまり賢明ではありませんでした。あなたも同意するでしょう。 したがって、628 対 991 の接続ではなく 1000 行を取得しましょう。 その結果、チームは次のように変わりました。

for ((i=N; i<M; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

tmux セッションで 16 個のウィンドウを開き、次のコマンドを実行します。

1) for ((i=0; i<100000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
2) for ((i=100000; i<200000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
…
15) for ((i=1400000; i<1500000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
16) for ((i=1500000; i<1628991; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

XNUMX日後、最初の結果が届きました！ つまり、(XXX と ZZZ の値は保持されなくなりました):

ERROR:  missing chunk number 0 for toast value 37837571 in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value XXX in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value ZZZ in pg_toast_106070
146000

これは、829 行にエラーが含まれていることを意味します。 最初と 000 番目の問題レコードの ID は 830 ～ 000 の間で、146 番目の問題レコードの ID は 000 ～ 147 の間でした。次に、問題レコードの正確な ID 値を見つける必要がありました。 これを行うには、問題のあるレコードの範囲をステップ 000 で調べ、ID を特定します。

for ((i=829000; i<830000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070
829449
for ((i=146000; i<147000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070
146911

ハッピーエンド

問題のある行が見つかりました。 psql 経由でデータベースにアクセスし、それらを削除しようとします。

my_database=# delete from ws_log_smevlog where id=829417;
DELETE 1
my_database=# delete from ws_log_smevlog where id=829449;
DELETE 1
my_database=# delete from ws_log_smevlog where id=146911;
DELETE 1

驚いたことに、オプションなしでもエントリは問題なく削除されました。 zero_damagged_pa​​ges.

それからデータベースに接続しました。 バキュームフル （これを行う必要はなかったと思います）そして最後に、次を使用してバックアップを正常に削除しました pg_dump。 ダンプはエラーなしで取得されました。 その問題はとても愚かな方法で解決されました。 たくさんの失敗を経て、何とか解決策を見つけることができたので、喜びは際限がありませんでした。

謝辞と結論

これが、実際の Postgres データベースを復元するという私の最初の経験の結果です。 私はこの経験を長い間忘れないでしょう。

そして最後に、ドキュメントをロシア語に翻訳してくださった PostgresPro に感謝の意を表したいと思います。 完全無料のオンラインコース、問題の分析中に非常に役立ちました。

出所： habr.com