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

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問


プラットフォームについて: Data Center のみ - この記事は、Data Center プラットフォームのアトラシアン製品にのみ適用されます。

この KB は Data Center バージョンの製品用に作成されています。Data Center 固有ではない機能の Data Center KB は、製品のサーバー バージョンでも動作する可能性はありますが、テストは行われていません。サーバー*製品のサポートは 2024 年 2 月 15 日に終了しました。サーバー製品を利用している場合は、アトラシアンのサーバー製品のサポート終了のお知らせページにて移行オプションをご確認ください。

*Fisheye および Crucible は除く

要約

この 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 個のノード node1node2 を持つ 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 秒待つ必要がある場合あがあります。
    • この手順は、新しいインデックスが健康であることを確認し、 CONFSERVER-57681 - Getting issue details... STATUS で報告されているバグを防止するために重要です。

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


Questions for Confluence がインストールされている場合に必要となる可能性がある追加の手順

このセクションの手順は、Questions for Confluence (QfC) がインストールされていて、質問やトピックを検索できない場合にのみ実行します。
これらに該当しない場合は次のセクションに進みます。

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

Data Center プラットフォームのインデックス プロセスのバグのため、Questions for Confluence のデータが Confluence のスタートアップ中にインデックスされません。詳細については CONFSERVER-58653 - Getting issue details... STATUS をご確認ください。

このため、次の手順に進む前に 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

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


最終更新日 2023 年 9 月 1 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.