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

要約

適切な方法を選択する

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

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

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

ソリューション

環境

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

Solution: Confluence 7.7 and later

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

この方法ではダウンタイムは必要ありません。ユーザーへのパフォーマンスの影響をさらに最小限に抑えるために、インデックス再作成を実行しているノードをロード バランサーから除外することもできます。Confluence は、新しいインデックスが正常に構築されてクラスタ内の各ノードに伝搬されるまでの間、既存のインデックスを引き続き使用します。 

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

解決策: Confluence 6.0 から 7.6

以降のセクションでは、Confluence Data Center でコンテンツ インデックスを再構築する手順について説明しています。

この手順を実行する間、Confluence クラスタのすべてのノードが一定期間ダウンします。つまり、この手順ではダウンタイムが必要です。ユーザーへの影響を最小限に抑えるため、利用の少ない時間帯にダウンタイムを計画してください。本番環境の場合は、まずステージング環境で手順をテストすることを検討してください。さらに、作業中のパフォーマンスのリスクを軽減するために、ロード バランサーからノードを除外したり、再インデックス作成ノードを分離したりすることもできます。

この手順は単一または複数のノードを持つインスタンスで機能しますが、この例では、node1 および node2 という 2 つのノードを持つ Data Center デプロイを想定します。3 つ、 4 つ、またはそれ以上のノードを持つデプロイの場合は、追加のノードで node2 から同じ手順を実行します。単一のノードで実行している場合は、 node2 に関連する手順を無視してください。

準備段階

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

   • インデックス再作成を実行するのは 1 つのノードのみにする必要があり、クラスター内の他のすべてのノードの Confluence は停止されます。ノードのクラスターに関する問題 (例: ノードがクラスターから切断されるなど) が発生した場合は、クラスターノード検出問題のトラブルシューティングに関する ドキュメント に記載されているとおり、クラスター化メソッドを Multicast から TCP/IP に切り替えることを検討してください。

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

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

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

   • ターゲット クラスからのメッセージを atlassian-confluence-indexing.log に送信するには、Confluence で特定のログ エントリを別のログ ファイルに送信するように log4j を設定する の指示に従ってください。クラスターの問題やマルチキャストの障害が発生した場合にさらに詳しく調べるには、ネットワーク通信やクラスター検出方法を診断するために、Hazelcast 関連のデバッグログを有効にすることを検討してください。

   • 上の手順の一環として、次のクラスを 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. 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..

   • 再インデックスが完了した旨をログで確認できるまでは、次のステップに進まないでください。インデックス化が部分的に完了した場合 (例: CONTENT はインデックス化されたが、USERS や ATTACHMENTS はインデックス化されていないなど)、プロセスを再試行するか、インデックス化の破損、アプリ コンテナーの再起動、ノードが時期尚早にオンラインになったなどの潜在的な問題がないか確認する必要がある場合があります。続行する前に、すべてのインデックス作成フェーズ (CONTENT、USERS、ATTACHMENTS など) が正常に完了していることを確認してください。

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) がインストールされており、質問やトピックが検索できない 場合にのみ 、このセクションの手順に従ってください。そうでない場合は、次のセクションに進んでください。

Questions for Confluence を使用している場合の追加の手順...

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

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