Zimbraの検索インデックスの破損を修正する方法：メールボックスのインデックスを再構築する方法

2026 年 10 月 6 日レビュー済み。Zimbraの検索で 1 つのメールボックスに対して不完全な結果が返され、メールボックス ログがインデクサーまたは Lucene エラーを示している場合、通常の修復方法は、そのメールボックスの検索インデックスを再構築することですzmprov rim account@example.com start。このコマンドは、メールボックスの内容から検索可能なインデックス データを再作成します。これは、メッセージ ファイルの欠落、データベースの破損、ストレージ ボリュームの満杯、またはサーバー全体の検索の失敗を修復するものではありません。

成功の判断は実際の成果に基づいて行ってください。つまり、インデックス再構築ジョブが完了し、以前は表示されなかったメッセージが検索で返され、新しいメールが検索結果に引き続き表示されることを確認してください。コマンドを開始しただけでは、インデックスが再構築されたとはみなされません。作業は比較的負荷の少ない時間帯に計画し、まずインデックスのボリュームを確認し、対象範囲を拡大する前に、影響を受けるアカウント1つに対して実行してください。

メールボックスのインデックス再構築は、どのような場合に適切な解決策となるのでしょうか？

通常のメールボックスへのアクセスはできるものの、検索で既知のメッセージが見つからない場合、影響を受けたユーザーが一貫性のない検索結果を目にする場合、または/opt/zimbra/log/mailbox.log「インデクサーを開けませんでした」などのメッセージや、そのアカウントに関する Lucene 例外が報告される場合、インデックスの破損または不完全さが原因である可能性が高いと考えられます。Zimbra のトラブルシューティング資料にzmprov verifyIndexは、欠落している、または開けないインデックスの診断方法と、zmprov rim ... startその再作成方法が記載されています。

まず、対象範囲を明確にしてください。影響を受けているユーザーが1人だけの場合は、そのメールボックスを調査してください。同じメールストアの多くのユーザーに同じ症状が見られる場合は、多数の再構築を実行する前に、サーバーの状態、ストレージ容量、最近のアップグレード、およびログを確認してください。大量の再インデックス処理は、ディスクI/OとCPUを大量に消費し、他のユーザーの検索速度を低下させる可能性があります。

ユーザーがログインできない、フォルダが見つからない、メッセージ本文や添付ファイルが開けない、メールストアデータベースにエラーが報告される、または複数のアカウントで検索サービスが利用できないといった状況が発生した場合、インデックスの再構築は適切な最初の対処方法ではありません。これらの兆候は、データベース、ブロブストア、サービス、またはインフラストラクチャの問題を示している可能性があります。すべての「検索」に関する苦情をインデックスの破損として扱うのではなく、ログを保存し、対応するZimbraの復旧手順またはサポートチャネルを利用してください。

コマンドを実行する前に

• 対象のメールボックスを確認してください。エイリアスではなく、プライマリアカウントのアドレスをコピーしてください。複数のメールストアを使用している場合は、アカウントを所有するメールボックスサーバーを確認し、トポロジーとインストールされているZimbraのバージョンに応じてコマンドを実行してください。
• 空き容量を確認してください。実際のインデックスボリューム上の空き容量とinodeを調べてください。インストールによっては、インデックスデータが別のマウント先に配置される場合があります。デフォルトのパスがアクティブな場所であると想定しないでください。インデックスボリュームがいっぱいになると、インデックス作成が失敗する可能性があります。
• システム負荷を確認してください。現在のメールストアのレイテンシ、CPU使用率、ディスクアクティビティを記録してください。インデックスの再構築は、特に大容量メールボックスの場合、多くのリソースを消費するため、トラフィックのピーク時を避けてスケジュールしてください。
• 復旧性を確保するため、メンテナンス前に通常のバックアッププロセスが正常に機能し、最新の状態であることを確認してください。インデックスの再構築は派生検索データの再構築を目的としていますが、本番環境のメールに対する修復作業を行う前にバックアップを取っておくことは依然として重要です。
• コマンドのサポート状況を確認してください。ZimbraのCLI構文と利用可能なオプションは、リリースによって異なる場合があります。特に古いリリースやカスタマイズされたデプロイメントを使用している場合は、インストールされているビルドに合わせて、コマンドのヘルプとドキュメントを確認してください。

メールボックスを検証して再構築する方法

1. 診断チェックを実行してください（利用可能な場合）。

Zimbraのオペレーティングシステムアカウントとして、Zimbraのトラブルシューティングガイドに示されている診断ツールを使用して、問題が疑われるメールボックスをテストしてください。

zmprov verifyIndex user@example.com

インデックスが存在しない、またはセグメントファイルが見つからないという応答は、インデックス破損の診断を裏付けるものです。インストールされているバージョンがインデックスを認識しない場合はverifyIndex、スクリプトをインストールしたり、別のサーバーからインデックスファイルをコピーして回避策を講じたりしないでください。バージョン固有の Zimbra ドキュメントを参照し、メールボックスログと影響を受けるアカウントを関連付けてください。

2. メールボックスのインデックス再構築を開始します

該当するZimbraサーバー上で、Zimbraオペレーティングシステムのアカウントに切り替え、影響を受ける単一のメールボックスの再構築を開始します。

su - zimbra
zmprov rim user@example.com start

通常、このコマンドはタスクが開始されたことを報告します。これはジョブの送信を確認するものであり、完了を確認するものではありません。検索が直後に完了しないからといって、繰り返しジョブを開始しないでください。まず、ジョブの状態とメールストアのログを確認してください。

3. 進捗状況を確認する

同じアカウントとサーバーコンテキストを使用して、再インデックスタスクを照会します。

zmprov rim user@example.com status

継続的にポーリングするのではなく、適切な間隔で繰り返してください。Zimbra のリリースに応じて応答を確認してください。CLI はジョブの状態を報告し、mailbox.logアカウント固有の進捗状況やエラーも表示できます。コマンドがエラーを報告した場合、タスクが完了しない場合、またはログにディスク容量不足やインデックスライターのエラーが表示された場合は、一時停止して根本的な問題を解決してから再度試してください。

Zimbraのコマンドリファレンスには、、、およびアクションが記載されています。リリースreIndexMailboxでキャンセルがサポートされており、ジョブがサービスに悪影響を与えている場合は、使用する前にローカル構文を確認してください。サポートされているキャンセル手順の代わりに、Javaプロセスを強制終了したり、インデックスファイルを削除したりしないでください。startstatuscancel

修理がうまくいったことを確認する方法

タスクが完了したら、影響を受けたユーザーのWebクライアントから、既知のメッセージをいくつか使用してテストしてください。特徴的な送信者、件名、日付範囲で検索し、古いメッセージと最近のメールの両方を確認します。メッセージが表示されるはずのフォルダを確認し、ユーザーが直接開くことができる既知のメッセージと比較します。次に、テストメッセージを送受信し、通常のインデックス作成遅延後に検索可能になることを確認します。

単発のクエリ成功ではなく、持続的な改善を目指してください。実質的な成功基準は以下のとおりです。

• メールボックスのインデックス再構築のステータスが、エラーの再発なく完了状態に達しました。
• これまで見つからなかった既知のメッセージが、想定される検索結果に表示されるようになりました。
• 新しいメールが引き続き検索インデックスに追加されています。
• インデックスボリュームには十分な空き容量が確保されており、他のメールボックスも正常に動作しています。

コマンドの完了が報告されたにもかかわらず、特定のメッセージが見つからない場合は、メッセージが存在し、開くことができることを確認してください。ユーザーの検索語、日付フィルター、フォルダーの範囲、またはクライアント側のキャッシュが、その違いの原因となっているかどうかを確認してください。インデックスを再構築しても、削除されたメッセージ、配信されなかったメッセージ、または基となるストアから失われたメッセージは復元できません。

トラブルシューティングの手順を変更するタイミング

再構築が繰り返し失敗する場合は、まずログに記録されているエラーに対処してください。ディスクの空き容量とinodeを確認し、メールストアまたはデータベースの広範なエラーがないか確認し、メールボックスが正しいサーバーで処理されていることを確認してください。アカウントがメッセージコンテンツにアクセスできない場合、または他のメールボックスでも同じ問題が発生する場合は、インデックスの再構築を中止し、ストア、データベース、またはサーバーレベルの原因を調査してください。

データの手動削除を/opt/zimbra/index日常的な手順として行うことは避けてください。Zimbraの公開Wikiにはインデックスファイルの手動削除手順が記載されていますが、そのページは開発中であり、古いリリースに関するものです。手動削除は、サポートされているアカウントレベルの再インデックスコマンドよりもエラーが発生しやすく、正確なメールボックスパス、検証済みのバックアップ、およびメンテナンスプランが確立されている、最新のリリース固有のベンダーガイダンスに基づいてのみ検討してください。

メールボックスの再インデックス作成の制限

インデックスの再構築は検索メタデータを再構築するものであり、MySQLやMariaDBのテーブルを修復したり、欠落したBLOBを復元したり、破損したファイルシステムを修復したり、ディスクの空き容量を増やしたり、サーバー全体の検索停止を解消したりするものではありません。また、メールボックスのサイズやサーバー負荷が増加するにつれて、インデックス作成にかかる時間も長くなります。インデックス作成中は検索が一時的に不完全になる場合があり、処理中は全体的なパフォーマンスが低下する可能性があります。

証拠が特定のアカウントの検索インデックスを示している場合は、まず組み込みのメールボックスレベルの再インデックス機能を使用してください。既知のメッセージとフォローアップメールを使用して結果を測定します。再インデックスが完了できない場合、またはデータ自体が破損している場合は、広範囲のインデックス削除にエスカレートするのではなく、関連するストレージまたはデータベースの復旧手順に移行してください。

公式資料

• Zimbra zmprov コマンドリファレンス—reIndexMailboxコマンドとそのアクション構文を一覧表示します。また、リリース固有の詳細については、管理者ガイドを参照するように案内しています。
• Zimbraのメールボックスインデックス破損に関するトラブルシューティング例ですverifyIndex。アカウントレベルの再インデックスコマンドを示しています。このページは現在作成中のため、お使いのインストール済みバージョンとの互換性を確認してください。
• Zimbra wiki のインデックスデータ削除とステータスチェックに関する手順は、古い開発中の資料です。参考情報としてのみ使用し、現在の運用システム上のファイルを削除する理由として使用しないでください。