Confluence Data Center でダウンタイムなしでコンテンツ インデックスをゼロから再構築する方法

要約

この KB 記事では、既定の検索プラットフォームである Lucene 検索プラットフォームを使用している場合に、 コンテンツのインデックス化 を再構築する手順を Confluence Data Center で ダウンタイムなしで ハイライトします。

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

適切な方法を選択する

環境

検索プラットフォームとして Lucene を使用して Confluence Data Center バージョン 6.x 以降を実行している場合、この手順が有効です。

ソリューション

Confluence 7.4 以降

Confluence 7.7 から、インデックス化の再構築とクラスター内のすべてのノードへの新しいインデックス化の伝播を、Confluence UI から直接実行できます。 

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

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

Confluence 6.0 to 7.6

以降のセクションでは、Confluence Data Center でダウンタイムなしでコンテンツ インデックスを再構築するための手順を説明します。

特定のノードで再インデックスを実行する間に Confluence クラスタ内のほかのノードは引き続き起動し、ユーザーのリクエストに対応します。

この例では、node1 と node2 の 2 つのノードを持つ Data Center デプロイについて検討します。

3 つ、 4 つ、またはそれ以上のノードのデプロイにも同じ手順が適用されます。この場合、他の任意のノードで node2 から同じ手順を実行します。

単一ノードで Confluence Data Center を実行している場合、ダウンタイムなしでコンテンツ インデックスをゼロから再構築することはできません。したがって、ダウンタイムを伴う Confluence Data Center でコンテンツのインデックス化を最初から手動で再構築する方法を参照してください。

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

準備段階

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

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

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

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

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

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

   • ターゲット クラスからのメッセージを atlassian-confluence-indexing.log に送信するには、Confluence で特定のログ エントリを別のログ ファイルに送信するように log4j を設定する の指示に従ってください。

   • 上の手順の一環として、次のクラスを 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. サンプル ページを作成し、新しい項目がコンテンツ インデックスに追加されていることを確認します。

   • 一意のコンテンツを持つサンプル ページを作成し、それを検索できることを確認します。

   • You may need to wait up to 30 seconds so the new page is indexed.

   • この手順は、新しいインデックス化が正常であることを確認し、CONFSERVER-57681 - ジャーナル エントリ キューが空の場合に再起動のたびにインデックス再作成が実行されるのを防ぐため、サイトのインデックス再作成が正常に完了した際にジャーナル エントリ ポインターをリセットする必要がある で報告されているバグを防ぐために重要です。

4. Confluence の UI にアクセスし、歯車アイコン > [全般設定] > [コンテンツ インデックス] > [キュー コンテンツ] にアクセスし、処理待ちの項目がないことを確認します。

   • インデックス キューに項目がある場合、完了するまで数分間待ちます。

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

Questions for Confluence (QfC) がインストールされている 場合のみ 、このセクションの手順に従ってください。そうでない場合は、次のセクションに進んでください。

Data Center プラットフォームのインデックス プロセスのバグのため、Questions for Confluence のデータが Confluence のスタートアップ中にインデックスされません。詳細については、CONFSERVER-58653 - Confluence Data Center でコンテンツ インデックスを最初から再構築すると一部のアプリ (プラグイン) のデータが再インデックス化されない を参照してください。

このため、次の手順に進む前に Confluence の UI からインデックスの再構築を再実行する必要があります。この手順は、上のバグがご利用の Confluence バージョンで修正されていない場合に必要です。

1. Confluence の UI にアクセスし、歯車アイコン > [全般設定] > [コンテンツ インデックス] に移動します。

2. [再構築] ボタンをクリックします。

3. atlassian-confluence-indexing.log ファイルで再インデックスのプロセスを追跡します。

   再インデックスのプロセスを UI から追跡することもできますが、完了の確認はログの次のエントリで行う必要があります。

   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

4. 歯車アイコン > [全般設定] > [コンテンツ インデックス] > [キュー コンテンツ] に移動し、インデックス キューでの処理待ちの項目がないことを確認します。

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

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

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

• 添付ファイルのインデックス作成を無効化する方法 | Confluence | アトラシアン製品ドキュメント