Zimbraのメールボックスログに発生する「DBエラー：DB障害/破損」を修正する：安全な診断と復旧

Zimbraメールボックスログに「DBエラー：DB障害」と表示されても、それは症状であって診断ではありません。データベースの停止、接続の失敗、ディスク容量の不足、接続数の過多、あるいは実際のテーブルまたはInnoDBの破損などが原因である可能性があります。安全な修復方法は、ログの該当箇所と影響を受けているサーバーによって異なります。まずは読み取り専用のチェックから始め、データを保護し、「破損」という単語が表示されたからといって、安易に一般的な修復コマンドを実行しないでください。

このガイドでは、Zimbra のテクニカルセンターに記載されている一般的な Zimbra のパスとコマンドを使用します。関連する Wiki ページの中には、アーカイブ済みまたは未完成とマークされているものがあるため、公式の Zimbra ドキュメント インデックスを使用して、ご使用の Zimbra のエディションとリリースに合わせて、すべてのコマンドと復旧手順を確認してください。以下の例は、特定のリリースを前提としていません。

mailbox.logに記録されたDBエラーは、実際には何を意味するのでしょうか？

Zimbraのメールボックスデータベースには、フォルダ、タグ、メッセージの状態、メッセージファイルへのポインタなど、メールボックスのメタデータが格納されます。検索インデックスは別に保存され、メッセージの内容はメッセージストアに保存されます。したがって、データベースエラーが発生したからといって、すべてのメールファイルが破損しているとは限りません。また、インデックスエラー自体がデータベースの損傷の証拠となるわけでもありません。Zimbraは、これらの別々のストアについて、サーバーアーキテクチャリファレンスで説明しています。

決定的な手がかりは通常、メールボックス例外の近く、特に に表示される根本的なデータベースエラーです/opt/zimbra/log/mysql_error.log。Zimbra のトラブルシューティング ノートではmailbox.log、 と がmysql_error.log有用な出発点として挙げられており、 はzmmailboxd.outメールボックス サービスの起動の詳細を提供します。Zimbraのログ トラブルシューティング リファレンスを参照してください。

修正を試みる前に、何をすべきでしょうか？

• ログには、発生時刻、タイムゾーン、サーバーのホスト名、影響を受けたアカウント、例外メッセージ全文、およびその周辺行を記録してください。ログを共有する前に、パスワード、メッセージの内容、個人データは削除してください。
• 対象範囲を明確にしましょう。メールボックスが1つだけなのか、1つのストア上の複数のメールボックスなのか、それとも複数のストアにまたがるユーザーなのかを判断してください。単一アカウントの症状だけでは、クラスタ全体のデータベースを再起動する正当な理由にはなりません。
• 最新の有効なバックアップが存在することを確認し、リリース固有の復元手順を特定してください。エラーが繰り返し発生する場合、またはユーザーに影響が出ている場合は、データベースの状態が把握できるまで、再起動や書き込みの繰り返しを避けてください。
• データベーステーブルをスキャンするチェックには、メンテナンスウィンドウを使用してください。整合性チェックでさえ、I/O負荷が増加し、メールボックスサービスが遅くなる可能性があります。

安全に診断するにはどうすれば良いですか？

1. サービスの状態を確認する

メールボックスサーバー上で、Zimbraアカウントに切り替えてサービスの状態を確認します。各プロンプトに表示されているアカウントでコマンドを実行してください。$コマンドの一部として、プロンプト記号（例：）を貼り付けないでください。

su - zimbra
zmcontrol status

メールボックスが稼働しているかどうか、また報告された問題が特定のメールボックスサーバーに限定されているかどうかを確認してください。メールボックスプロセスが停止しているだけでは、データベースが破損していると断定することはできません。Zimbraのメールボックストラブルシューティングページには、サービスステータスとデータベースのログイン/構成も個別のチェック項目として記載されています。このページはアーカイブとして扱われているため、参考情報として利用し、ご使用のリリースに関するドキュメントを参照してください。

2. メールボックスとデータベースのログを同時に比較する

両方のログで同じ時間帯のエラーを読み取ります。多くの場合、一連のエラーの中で最初のエラーの方が、最後の「システム障害」の行よりも有用な情報を提供します。

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

基となるデータベースメッセージ、データベース名またはメールボックスグループ名、繰り返されるタイムスタンプ、起動失敗、または一致するOSエラーを探してください。これらのフレーズは手がかりとして扱い、自動的な解決策として捉えないでください。

3. ディスク容量とオペレーティングシステムのエラーを確認する

データボリュームやログボリュームがいっぱいになったり、inodeが枯渇したり、ストレージに障害が発生したりすると、データベース障害のように見えることがあります。ストアホストで非破壊的なチェックを実行してください。

df -h /opt/zimbra
df -i /opt/zimbra

同じ時間帯に発生したディスクI/O、ファイルシステム、またはメモリ不足エラーについて、オペレーティングシステムのジャーナルまたはシステムログを確認してください。ボリュームがいっぱいの場合は、通常のストレージ手順に従って空き容量を確保するか、追加してください。空き容量を確保するために、データベースファイル、InnoDBログ、またはアクティブなZimbraログを削除しないでください。削除すると、復旧が困難になったり、証拠が失われたりする恐れがあります。

4. 影響を検討した後にのみ、整合性チェックを実行する

Zimbraのデータベースサービスにアクセス可能で、ログに明確な接続またはストレージの問題が示されていない場合、管理者はトラフィックの少ないメンテナンス期間中に標準の整合性レポートを検討することができます。

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

Zimbraの整合性レポートのリファレンスでは、これはデータベースチェックであると説明されており、I/Oが増加し、メールボックスのレイテンシが増加する可能性があると警告しています。また、-r自動テーブル修復を試みるオプションについても記載されています。ルーチンの次のステップとして追加しないでください。-rこのページは作業中であり、適切なアクションはデータベースエンジン、テーブルタイプ、製品リリース、およびバックアップステータスによって異なります。既知の無害なログテーブルロックメッセージのみを記載したレポートは、そのページの注記に従って解釈する必要があります。「データベースエラーが見つかりました」というヘッダーをすべて同じように扱わないでください。

どの修正案が証拠と一致するか？

• データベースサービスが停止していますが、破損の兆候は見られません。まず、起動、構成、認証情報、またはリソースに関する特定のエラーに対処してください。修正後、リリースおよびデプロイメントトポロジーに応じたサービス復旧手順を実行してください。無作為に何度も再起動することは避けてください。
• 接続数が多すぎる場合：負荷、フリーズしているクライアント、およびサービス容量を調査してください。データベースの破損と決めつけたり、現在のサイジングおよびリリースに関するガイダンスを確認せずに、古い推奨事項をそのままコピーして制限を引き上げたりしないでください。
• ディスクまたはファイルシステムの問題：ストレージを安定させ、ファイルシステムが正常であることを確認してください。データベースに書き込み失敗またはInnoDBエラーが記録されている場合は、たとえ空き容量が回復した後でも、整合性の問題が発生した可能性があるとみなしてください。
• 整合性レポートでテーブルがフラグ付けされた場合は、正確な出力、テーブル/データベース名、タイムスタンプ、および関連ログを保存してください。書き込み操作を行う前に、サポートされている方法を使用してデータベースボリュームをバックアップまたはスナップショットしてください。管理者に、インストールされている Zimbra のバージョンに対応したベンダー提供の修復または復元手順に従ってもらってください。
• DBエンジンは正常だが、影響を受けているアカウントが1つ残っている場合、そのアカウントのメールボックスメタデータ、メッセージストア、またはインデックスを個別に調査してください。アカウントを「再構築」するために、SQL行を手動で編集したり、ファイルを削除したりすることは避けてください。

InnoDBの破損が疑われる場合、最も安全な修復方法は、検証済みのバックアップからのリリース固有のリカバリ、またはサポート担当者の指導によるリカバリであり、一般的なREPAIR TABLEデータベースの再初期化やコピーしたコマンドシーケンスではありません。Zimbra wikiの古いリカバリ記事には、破壊的な手順が含まれているものがあり、明示的にアーカイブされています。Zimbraサポートからの直接の確認とテスト済みのバックアップがない限り、現在のシステムには適用しないでください。

問題が解決したことをどのように確認できますか？

承認された是正措置の後、データベースおよびメールボックスサービスが引き続き稼働していること、新しいエントリに同じ基盤となるデータベースエラーが表示されなくなったこと、および影響を受けたアカウントが通常のメール操作を実行できることを確認してください。ロードウィンドウとバージョンに適切な場合にのみ、標準の整合性レポートを再実行してください。バックアップジョブが完了し、ログと修復レコードが保存されていることを確認してください。問題が再発した場合は、Zimbraの正確なバージョン/ビルド、シングルサーバー構成またはマルチサーバー構成、メールボックスの範囲、最初の障害発生時刻、関連するログ抜粋、ディスクの状態、整合性レポートの出力、およびバックアップのタイムスタンプを管理者またはZimbraサポートチャネルに報告してください。

重要なポイント：データを変更する前に、メールボックス例外の原因となっているデータベースエラーを診断してください。「DB障害」というメッセージだけでは、修正方法が認証情報の修正、容量の変更、ストレージの修復、データベースの復旧のいずれであるかを判断できません。

主な参考資料：Zimbraドキュメントインデックス、Zimbraサーバーアーキテクチャ、Zimbraログのトラブルシューティング、Zimbraデータベース整合性レポートリファレンス、Zimbra MySQLエラー1040リファレンス、Zimbraメールボックスのトラブルシューティングリファレンス。記事に記載されているように、テクニカルセンターの一部のページはアーカイブされているか、作業中となっています。