通常の運用では、サービスのインデックス構成に加えられた変更は、コレクションに入力される新しいデータにのみ適用されます。コレクション内のすべてのデータに対するインデックスの再構築は、すべてのメタ データベース ストレージをディスクから読み取る必要があるため、時間のかかるプロセスです。
バージョン11.0以降では、サービスがオンラインのときにインデックスを再構築することができます。バージョン11.0サービスは、セッションとメタ データベースの一部がインデックス付きではないことを検出するたびに、バックグラウンドでインデックスを再構築します。
バックグラウンド再インデクサを有効にする
バックグラウンド再インデクサは、サービスが開始されるたびに有効になります。起動時、インデクサは、インデックスが作成されているセッションと、セッションおよびメタ データベース内に存在するセッションの間のギャップをチェックします。ギャップがある場合、バックグラウンド再インデクサはサービス上のセッションおよびメタ データベースの再インデックス作成を開始します。
バックグラウンド再インデクサが有効になるイベントの例：
- 電源障害またはクラッシュが発生すると、破損したインデックスの最後のスライスがレンダリングされます。破損データは起動時に削除され、インデックスにギャップが残ります。
- インデックスのリセットを実行するか、ファイル システムからファイルを削除すると、インデックス データは強制的に削除されます。
バックグラウンド再インデクサを制御する
バックグラウンド インデクサの動作は構成ノード /index/config/reindex.enable によって制御されます。 reindex.enable がtrueに設定される場合、次回サービスの開始時に再インデクサが動作します。 reindex.enable がfalseに設定される場合、次回サービスの開始時に再インデクサは開始されませんが、サービスが再起動されるまでは動作を続けます。
バックグラウンド インデックス再作成のアルゴリズム
バックグラウンド インデクサの動作は次のとおりです。
- インデックスは、インデックス内に存在するセッションの範囲を調査し、有効なメタ データのあるセッションの範囲と比較します。2つの不一致がギャップと見なされます。
- インデックスのギャップは
/index/config/save.session.countの現在の値に基づいてスライスに分割されます。 /index/config/index.dirで指定されたディレクトリのいずれかに、不足しているスライスごとに一時インデックスが作成されます。番号とは逆の順序でスライスがインデックス再作成されます。このため、最後に収集されたセッションが最初にインデックス作成されます。- スライスが完全にインデックス再作成されると、オンライン インデックスの有効な場所に移動されます。再インデックス再作成されたスライスがウォーム階層に属する場合、ウォーム階層に移動されます。
- 新しくインデックス作成されたデータはコレクションの一部として表示されます。
バックグラウンド インデクサ ステータス
statノード /index/stats/updater.state はバックグラウンド再インデクサの現在の状態を示します。このノードは running 、 not running 、 failed のいずれかになります。ステータスが failed の場合、診断診断情報の詳細をサービス ログで確認します。
集計への影響
集計を実行するサービスは、インデックスを活用してすでに集計されているセッションを追跡します。インデックスが集計を開始するのに十分な情報を持たない場合は、十分なスライスがインデックス再作成されるまで集計はオフラインになります。この間、上位デバイスの集計ステータスでは、集計を待機していることを示します。
再インデックスを強制する
サービスのインデックスの再構築を強制するには、次の手順に従います。
/index/config/reindex.enableがtrueになっていることを確認します。- サービスで
resetメッセージを使用して、インデックスをリセットします。例：/concentrator/reset index=1によってサービスを再起動し、すべてのインデックス ファイルを削除します。 - サービスが再起動するまで待ちます。バックグラウンド インデックス再作成が開始されます。
- 最後に収集されたデータは、それらのセッションを表すインデックス スライスのインデックスが再作成されるとすぐに、クエリに使用可能になります。