要約

This KB article highlights the steps to rebuild the content index in a Confluence Data Center without any downtime, when using Lucene search platform, which is the default search platform.

コンテンツ インデックスの再構築の他のオプションを確認したい場合は「コンテンツ インデックスをゼロから再構築する方法」をご確認ください。

この手順でご質問がある場合、あるいは再インデックスの実行中に問題が発生した場合は、アトラシアン サポートにチケットを起票してください。

環境

This procedure is valid if you are running Confluence Data Center versions 6.x later, using Lucene as the search platform.

ソリューション: Confluence 7.7 以降

Confluence 7.7 以降では、インデックスの再構築と、クラスタ内の全ノードへの新しいインデックスの伝搬は、Confluence の UI から直接行えます。 

この方法ではダウンタイムは不要であるほか、ユーザーへのパフォーマンスの影響をさらに最小化するために、再インデックスを実行しているノードをクラスタから取り除くのを選択することもできます。Confluence は、新しいインデックスが正常に構築されてクラスタ内の各ノードに伝搬されるまでの間、既存のインデックスを引き続き使用します。 

詳細については「コンテンツ インデックスの管理」をご確認ください。

ソリューション: Confluence 6.0 から 7.6

以降のセクションでは、Confluence Data Center でダウンタイムなしでコンテンツ インデックスを再構築するための手順を説明します。
特定のノードで再インデックスを実行する間に Confluence クラスタ内のほかのノードは引き続き起動し、ユーザーのリクエストに対応します。

この例では、2 つのノード node1 と node2 を持つ Data Center デプロイメントを前提とします。
3、4、またはそれ以上のノードを持つデプロイメントで同じ手順を利用できます。この場合、node2 と同じステップを他のすべてのノードで実行します。

Confluence Data Center をシングル ノードで実行している場合、ダウンタイムなしでコンテンツ インデックスをゼロから再構築することはできません。このため、「Confluence Data Center でダウンタイムを許容しながらコンテンツ インデックスをゼロから再構築する方法」をご確認ください。

このドキュメントを通じ、Confluence のコンテンツ インデックスの再構築プロセスを「再インデックス」と参照している箇所があります。

準備段階

1. 再インデックス プロセスを実行するノードを選択します。

   • 再インデックス プロセスは 1 つのノードでのみ実行します。

   • このノードではユーザー リクエストへの対応は行いません。クラスタ内の他のすべてのノードは引き続き実行し、ユーザーに対応します。

   • この例では、再インデックスを実行するノードとして node1 を選びます。これを再インデックス ノードと参照する場合があります。
     
     

2. node1 で、インデックスに関連するログ メッセージを別のファイルに送信するように log4j を構成します。

   • 別のログ ファイルに追加情報を格納すると、インデックス プロセスが実行中か完了済みかを特定するのに役立ちます。また、何か問題が発生してサポート チームに問い合わせる必要がある場合にも便利です。

   • 「特定のエントリを別のログ ファイルに送信するように Confluence の log4j ファイルを構成する」の手順に従い、対象のクラスからのメッセージを atlassian-confluence-indexing.log に送信するようにします。

   • 上の手順の一環として、次のクラスを INFO に追加する必要があります。

     com.atlassian.confluence.search.lucene
     com.atlassian.confluence.internal.index
     com.atlassian.confluence.impl.index
     com.atlassian.bonnie.search.extractor

   • この変更は Confluence が再起動したときにのみ有効になります。以降の手順で再起動を行うため、現時点でこれを行う必要はありません。
     
     

3. node1 で次の JVM システム プロパティを構成し、実行中のノードからインデックス ファイルのリクエストを試行しないようにします。

   -Dconfluence.cluster.index.recovery.num.attempts=0

   
   

   • この変更は Confluence ノードが再起動したときにのみ有効になります。以降の手順で再起動を行うため、現時点でこれを行う必要はありません。
     
     
4. node1 に適用したい一時的な構成があればそれを追加します。
   • ベスト プラクティスや追加パラメーターについては「コンテンツ インデックスをゼロから再構築する方法」をご確認ください。
     
     

5. ロード バランサのターゲット グループから node1 を取り除きます。

   • 再インデックスの実行中は Confluence の速度が低下する可能性があるため、再インデックスを実行しているノードがユーザーに提供された場合、ユーザーが最高のエクスペリエンスを得られない可能性があります。
   • ユーザーからの通常リクエストによって再インデックス プロセスとリソースが競合する可能性があるため、このようなリクエストは他のノードに転送するのが最適です。

現在のインデックスのクリーンアップ

1. 通常の手順に従い、node1 でのみ Confluence を終了します。

2. データベースにアクセスし、次の SQL を実行して journalentry テーブルから古いエントリを削除します。

   DELETE FROM journalentry WHERE creationdate < CURRENT_TIMESTAMP - interval '2 hour';

   • これにより、2 時間よりも古いエントリが削除されます。引き続きオンラインであるノードでは、新しいコンテンツが作成されたタイミングで引き続き再帰的な再インデックスが実行されます。

3. 安全のため、index/ のバックアップを取得します。

4. node1 で、次のフォルダからすべてのファイルを削除します。

   <Confluence-home>/index/
   <Confluence-home>/journal/
   <Confluence-shared-home>/index-snapshots/

インデックスの再構築

1. node1 で Confluence を開始します。
   • これにより、スタートアップ プロセス中にこのノードでの再インデックスが自動的にトリガーされます。
2. atlassian-confluence-indexing.log ファイルで再インデックスのプロセスを追跡します。

   • 次のエントリは、再インデックス プロセスが開始されたことを示します。

     2020-06-09 17:32:05,553 WARN [Catalina-utility-1] [confluence.impl.index.DefaultIndexRecoveryService] triggerIndexRecovererModuleDescriptors Index recovery is required for main index, starting now
     2020-06-09 17:32:05,557 DEBUG [Catalina-utility-1] [confluence.impl.index.DefaultIndexRecoveryService] recoverIndex Cannot recover index because this is the only node in the cluster
     2020-06-09 17:32:05,558 WARN [Catalina-utility-1] [confluence.impl.index.DefaultIndexRecoveryService] triggerIndexRecovererModuleDescriptors Could not recover main index, the system will attempt to do a full re-index
     2020-06-09 17:32:05,724 DEBUG [lucene-interactive-reindexing-thread] [confluence.internal.index.AbstractReIndexer] reIndex Index for ReIndexOption CONTENT_ONLY

   • 再インデックスの実行中は次のようなエントリが確認できる場合があります。

     2020-06-09 17:32:14,911 DEBUG [Indexer: 4] [internal.index.lucene.LuceneContentExtractor] lambda$extract$0 Adding fields to document for Space{key='SPC550'} using BackwardsCompatibleExtractor wrapping com.atlassian.confluence.search.lucene.extractor.AttachmentOwnerContentTypeExtractor@7103c5b0 (confluence.extractors.core:attachmentOwnerContentTypeExtractor)
     2020-06-09 17:32:14,911 DEBUG [Indexer: 8] [internal.index.lucene.LuceneBatchIndexer] doIndex Index Space{key='SPC632'} [com.atlassian.confluence.spaces.Space]
     2020-06-09 17:32:14,910 DEBUG [Indexer: 6] [internal.index.lucene.LuceneBatchIndexer] doIndex Index Space{key='SPC530'} [com.atlassian.confluence.spaces.Space]
     2020-06-09 17:32:14,909 DEBUG [Indexer: 7] [internal.index.attachment.DefaultAttachmentExtractedTextManager] isAdapted Adapt attachment content extractor com.atlassian.confluence.extra.officeconnector.index.excel.ExcelXMLTextExtractor@6aa2ced for reuse extracted text

   • 次のエントリは、再インデックス プロセスが正常に完了したことを示します。

     2020-06-09 17:32:31,387 DEBUG [Indexer: 1] [internal.index.lucene.LuceneContentExtractor] lambda$extract$0 Adding fields to document for userinfo: user001 v.1 (1572865) using BackwardsCompatibleExtractor wrapping com.atlassian.confluence.search.lucene.extractor.HtmlEntityFilterExtractor@4033e565 (confluence.extractors.core:htmlEntitiesFilterExtractor)
     2020-06-09 17:32:31,387 DEBUG [Indexer: 1] [internal.index.lucene.LuceneContentExtractor] lambda$extract$0 Adding fields to document for userinfo: user001 v.1 (1572865) using BackwardsCompatibleExtractor wrapping com.atlassian.confluence.search.lucene.extractor.TitleExtractor@48deb96f (confluence.extractors.core:titleExtractor)
     2020-06-09 17:32:31,388 DEBUG [Indexer: 1] [confluence.internal.index.AbstractBatchIndexer] lambda$accept$0 Re-index progress: 100% complete. 3276 items have been reindexed
     2020-06-09 17:32:31,432 DEBUG [Indexer: 1] [confluence.internal.index.AbstractBatchIndexer] accept BatchIndexer batch complete
     2020-06-09 17:32:31,491 DEBUG [lucene-interactive-reindexing-thread] [confluence.search.lucene.PluggableSearcherInitialisation] initialise Warming up searcher..
     2020-06-09 17:32:31,491 DEBUG [lucene-interactive-reindexing-thread] [confluence.search.lucene.DefaultSearcherInitialisation] initialise Warming up searcher..

   • 再インデックスが完了した旨をログで確認できるまでは、次のステップに進まないでください。
     
     
3. サンプル ページを作成し、新しい項目がコンテンツ インデックスに追加されていることを確認します。
   • 一意のコンテンツを持つサンプル ページを作成し、それを検索できることを確認します。
   • 新しいページがインデックスされるのに最大 30 秒待つ必要がある場合あがあります。
   • この手順は、新しいインデックスが健康であることを確認し、 CONFSERVER-57681 - Getting issue details... STATUS で報告されているバグを防止するために重要です。
     
     
4. Confluence の UI にアクセスし、歯車アイコン > [全般設定] > [コンテンツ インデックス] > [キュー コンテンツ] にアクセスし、処理待ちの項目がないことを確認します。
   • インデックス キューに項目がある場合、完了するまで数分間待ちます。
     

Questions for Confluence がインストールされている場合の追加ステップ

このセクションのステップは、Questions for Confluence (QfC) がインストールされている場合にのみ利用します。これらに該当しない場合は次のセクションに進みます。

インデックス ファイルを共有の場所にコピー

1. node1 で Confluence を停止させます。

2. node1 で、index および journal フォルダを圧縮し、shared-home に保存します。
   これらのファイルを共有ホームに保存することで、クラスタ内の他のノードからそれらを利用できるようになります。

   cd <Confluence Home Dir>
   tar -cvf <Confluence-shared-home>/node1-index.tar ./index
   tar -cvf <Confluence-shared-home>/node1-journal.tar ./journal

3. node1 で、log4j.properties で行った追加のログ構成を取り除きます。
   • これらは準備段階の一環として追加されています。
   • 不要なデバッグはアプリケーションに悪い影響を与える可能性があるため、Confluence の通常のオペレーション中はこの構成を保持しないことが強く推奨されます。
4. 準備フェーズの一環として追加したシステム プロパティがあれば、それを取り除きます。
5. node1 で Confluence を開始し、正常に動作していることを確認します。
6. この時点で node1 をユーザーに提供できます。このため、node1 をロード バランサのターゲット グループに戻します。

共有ホームのインデックス ファイルをクラスタの残りのノードにコピー

1. 通常の手順に従い、node2 で Confluence を停止します。

2. node2 で、ローカル ホームの index および journal フォルダを削除します。

   cd <Confluence-home>
   rm -rf index/
   rm -rf journal/

3. node2 で、共有ホームから取得した index および journal フォルダをローカル ホームに展開します。

   cd <Confluence-home>
   tar -xvf <Confluence-shared-home>/node1-index.tar
   tar -xvf <Confluence-shared-home>/node1-journal.tar

4. node2 のローカル ホームにインデックス ファイルが適切に配置されていることを確認します。
   次のような構造になります。

   $ ls -R atlassian-confluence-local-home/index atlassian-confluence-local-home/journal
   atlassian-confluence-local-home/index:
   _9.cfe       _a.cfe       _b.cfe       _c.cfe       _d.cfe       _e.cfe       _f.cfe       _g.cfe       _h.cfe       _j.cfe       _j_1.del     segments_9
   _9.cfs       _a.cfs       _b.cfs       _c.cfs       _d.cfs       _e.cfs       _f.cfs       _g.cfs       _h.cfs       _j.cfs       edge
   _9.si        _a.si        _b.si        _c.si        _d.si        _e.si        _f.si        _g.si        _h.si        _j.si        segments.gen
   
   atlassian-confluence-local-home/index/edge:
   _0.cfe       _0.cfs       _0.si        _1.cfe       _1.cfs       _1.si        segments.gen segments_4
   
   atlassian-confluence-local-home/journal:
   edge_index main_index

5. node2 で Confluence を開始し、正常に動作していることを確認します。

タスクのクリーンアップ

1. 共有ホーム フォルダから、圧縮した index および journal ファイルを削除します。

   rm -f <Confluence-shared-home>/node1-index.tar
   rm -f <Confluence-shared-home>/node1-journal.tar

人気のコンテンツの復元

(任意): 必要に応じ、ステップ 2 のバックアップから次のディレクトリを復元します。手順については「ゼロから再インデックスしたときに人気のコンテンツが不足している」をご確認ください。

すべてのノードでコンテンツ インデックスが動作していることを確認

これらの手順は、新しいコンテンツがすべての Confluence ノードで適切にインデックスされているのを確認するために役立ちます。

1. node1 で Confluence の UI にアクセスし、新しいサンプル ページを作成します。
2. 歯車アイコン > [全般設定] > [コンテンツ インデックス] > [キュー コンテンツ] に移動し、すべてのオブジェクトがインデックス キューで処理されていることを確認します。
   • まだ処理中の場合は完了まで 1 分程度待ちます。
3. 新しく作成されたドキュメントを node1 で検索し、インデックスされていることを確認します。
4. node2 に移動し、歯車アイコン > [全般設定] > [コンテンツ インデックス] > [キュー コンテンツ] に移動して、インデックス キューにオブジェクトがないことを確認します。
5. 新しく作成されたドキュメントを node2 で検索し、インデックスされていることを確認します。
6. Connfluence クラスタの残りのノードで同じ検証を行います。

参考資料

コンテンツ インデックスをゼロから再構築する方法

Confluence Data Center

コンテンツ インデックス管理