要約

この KB 記事では、ある程度のダウンタイムを許容しながら、Confluence Data Center インスタンスでコンテンツ インデックスを再構築する手順について説明します。

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

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

環境

この手順は、Confluence Data Center バージョン 6.x と 7.x を実行しているときに有効です。

ソリューション: 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 と同じ手順を実行します。
単一ノードで実行している場合は node2 に関連する手順を無視します。

準備段階

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

   • 再インデックスを実行するノードは 1 つだけです。この間、クラスタの他のすべてのノードの Confluence は停止されます。

   • この例では、再インデックスを実行するノードとして node1 を選択します。

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

   • The additional messages in a separated log file is helpful to identify if the indexing process is still running or if it completed; it is also helpful in case anything goes wrong and you need to contact the support team.

   • 「特定のエントリを別のログ ファイルに送信するように 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. ロード バランサのターゲット グループからすべてのノードを取り除きます。

   • これは、インデックスの再構築中にユーザーが Confluence にアクセスしないようにしたい場合の任意の手順です。

   • Confluence の速度は再インデックスの実行中に低下する可能性があるため、ユーザーがアプリケーションにアクセスしているときに最高のエクスペリエンスを得られない場合があります。

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

1. 通常の手順に従い、クラスタのすべてのノードで Confluence を停止させます。
2. Synchrony をスタンドアロンで実行している場合、すべてのノードでそのプロセスを停止させます。

3. データベースにアクセスして次の SQL を実行し、journalentry テーブルを切り取ります。

   TRUNCATE TABLE JOURNALENTRY;

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

5. On node1 delete the following folders.

   <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 秒待つ必要がある場合あがあります。
   • This step is important to ensure the new index is healthy and to prevent a bug reported in 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. Synchrony をスタンドアロンで実行している場合、すべての Synchrony ノードでプロセスを開始します。
5. node1 で Confluence を開始し、正常に動作していることを確認します。
6. この時点で node1 をユーザーに提供できます。このため、node1 をロード バランサのターゲット グループに戻します。

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

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

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

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

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

3. 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

4. node2 で Confluence を開始し、正常に動作していることを確認します。
5. この時点で node2 をユーザーに提供できます。このため、node2 をロード バランサのターゲット グループに戻します。

タスクのクリーンアップ

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

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