電源喪失によってデータベースコンテナが破損したことを示す警告サインとは？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Are the Warning Signs That a Database Container Was Corrupted by Power Loss?

データベースが通常のクラッシュリカバリを完了できない場合や、その後にチェックサム、ページ、ログシーケンス、テーブル、インデックスの不整合を報告する場合は、破損を疑ってください。

正常でないシャットダウンが発生したからといって、データベースが自動的に破損したことを意味するわけではありません。PostgreSQL、MySQL、MariaDBなどのエンジンは、コミット済みの状態を復旧するために、ジャーナルや先行書き込みログを使用します。復旧が繰り返される、エンジンが終了する、同じクエリで無効なページに到達する、チェックサムに失敗する、テーブルが消える、インデックスがテーブルデータと矛盾する、またはバックアップや整合性チェックでクラスタを一貫して読み取れない場合に、警戒すべき状態となります。

通常のクラッシュリカバリとリカバリループを区別する

電源復旧後の最初の起動ログを保存してください。エンジンが一度だけログを再生して準備完了になるのか、それとも繰り返し再起動したり、強制リカバリに入ったり、同じレコードやページで停止したりするのかを記録します。

InnoDBは、書き込みの中断後に半端な状態で書き込まれた可能性のあるページを復元していると報告することがあります。このメッセージは、エンジンが安全なクラッシュリカバリを試みていることを示しますが、失敗が繰り返される場合は、停電後のInnoDBエラーを示している可能性があります。

一度だけリカバリに成功し、その後の通常のチェックも通過したとしても、破損していない証明にはなりません。ループ、致命的なアサーション、同じシグナルの繰り返し、または準備完了状態に到達できない場合は、追加の書き込みが発生する前に、未加工ファイルをコピーし、バックアップをテストするための停止信号です。

チェックサムエラーと無効なページのエラーを確認する

ログで、checksum mismatch、page verification failed、invalid page in block、corrupt page、short read、bad magic number、unexpected end-of-fileを検索してください。名前が示されたリレーション、テーブル、ブロック、またはテーブルスペースを記録します。

pganalyzeは、PostgreSQLの破損が、ページチェックサムエラーとして現れ、破損したブロックが読み取られた際に無効なページエラーが続いて発生することを示しています。

証拠を保存し、バックアップの対象範囲を確認する前に、エラーを無視したり、破損したページをゼロで埋めたりしないでください。再起動後も同じブロックで失敗する場合は、一度だけ発生したアプリケーションのタイムアウトよりも強い証拠になります。

特定の行やテーブルでのみ失敗するクエリに注意する

アプリケーションが通常使用するテーブルとクエリに対して、読み取り専用のチェックを実行してください。破損は、スキャン、バキューム、バックアップ、またはリクエストが破損したページに触れるまで発見されないことがあります。

PostgreSQLに関するある分析では、チェックサム不一致はデータベースより下位の層に問題があることを示す一方、チェックサム警告を伴わない無効なページも、ストレージ、メモリ、ファイルシステム、または誤ったファイル操作による損傷を反映している可能性があると説明されています。実際に現れる症状は、通常のクエリ実行中に発生する再現性のある無効なページの読み取りです。

どのクエリとオブジェクトが失敗したのかを正確に記録してください。データベースの一部しか読み取れない状態でアプリケーションに広範な書き込みを続けさせないでください。新しい状態が復旧やバックアップを複雑にする可能性があります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

インデックス、トランザクション、メタデータの不整合を確認する

警告の兆候には、一意インデックスに違反する重複キー、あるアクセスパスでは見つからないが別のアクセスパスでは到達できる行、無効なトランザクションID、破損したTOASTや大きな値のチャンク、検証に失敗するインデックスなどがあります。

Credativの破損に関するレビューでは、データチェックサムがないクラスタでは、無効なページ、トランザクションIDの問題、TOASTの不整合、バックエンドのクラッシュなど、低レベルのエラーによって損傷が明らかになることが指摘されています。一部のファイルコピー方式のバックアップでは、検出されないまま破損したページが保存される可能性があります。

サポートされている整合性チェックとインデックスチェックを、コピー上または管理されたメンテナンス時間帯に実行してください。再インデックスで破損した派生インデックスを修復できる場合はありますが、破損したテーブルデータや基盤となるストレージが修復されるわけではありません。

データベースエラーとファイルシステムおよびストレージの警告を関連付ける

障害の前後におけるホストカーネル、ファイルシステム、プール、ドライブ、コントローラー、UPS、コンテナランタイムのログを確認してください。I/Oエラー、リセット、チェックサムエラー、読み取り専用での再マウント、プールの劣化、ファイルの消失や切り詰めがないかを確認します。

あるデータベース復旧ガイドでは、特にストレージの動作がデータベースの耐久性に関する前提と一致しない場合、停電や不良メモリによってページ書き込みが破損する可能性があると説明されています。こうしたホストレベルのイベントは、InnoDBページの破損と通常のアプリケーション再起動を区別するのに役立ちます。

クリーンなデータベースを復元する前に、ストレージ経路の問題を修正してください。障害が発生しているメディアへの論理リストアに成功しても、同じ事象が再発したり、置き換えたデータが気付かないうちに破損したりする可能性があります。

書き込みを停止し、クリーンなバックアップからの復旧を確認する

破損の兆候が再現する場合は、依存するアプリケーションを停止し、安全であれば影響を受けたボリュームのスナップショットまたはクローンを作成し、ログと設定を保存してください。元のクラスタを変更する前に、最新のバックアップを別のストレージ上でテストします。

ZimaSpaceのDockerアプリケーション状態のバックアップチェックリストでは、破壊的なデータベース復旧を試みる前に存在していなければならないものを定義しています。

復元したデータベースが正常に起動し、整合性チェックに合格し、代表的なクエリと書き込みが成功し、バックアップが完了し、ホストストレージに新たなエラーが報告されない場合にのみ、システムは信頼できる状態になります。強制リカバリモードは、文書化された復旧計画に基づく救出作業のために使用し、通常の運用には使用しないでください。