Elasticsearch

このページでは、高度な検索を有効にする方法について説明します。有効にすると、高度な検索によって検索応答時間が短縮され、検索機能が向上します。

高度な検索を有効にするには、次の手順を実行する必要があります:

1. ElasticsearchまたはAWS OpenSearchクラスターをインストールします。
2. 高度な検索を有効にします。

Elasticsearch用語集

この用語集では、Elasticsearchに関連する用語の定義を提供します。

• Lucene: Javaで記述されたフルテキスト検索ライブラリ。
• Near real time (NRT)（ほぼリアルタイム（NRT））: ドキュメントにインデックスを作成してから検索可能になるまでのわずかなレイテンシーを指します。
• クラスター: すべてのデータを保持するために連携して動作する1つ以上のノードのコレクションであり、インデックス作成機能と検索機能を提供します。
• Node（ノード）: クラスターの一部として機能する単一のサーバー。
• インデックス: ある程度類似した特性を持つドキュメントのコレクション。
• Document（ドキュメント）: インデックスを作成できる情報の基本単位。
• Shards（シャード）: インデックスの完全に機能する独立したサブディビジョン。各シャードは実際にはLuceneインデックスです。
• Replicas（レプリカ）: インデックスを複製するフェイルオーバーメカニズム。

ElasticsearchまたはAWS OpenSearchクラスターをインストールする

ElasticsearchとAWS OpenSearchはLinuxパッケージにnot（含まれていません）。検索クラスターを自分でインストールするか、次のようなクラウドホスト型サービスを使用できます:

• Elasticsearch Service（Amazon Web Services、Google Cloud Platform、Microsoft Azureで利用可能）
• Amazon OpenSearch Service

検索クラスターは別のサーバーにインストールする必要があります。GitLabと同じサーバーで検索クラスターを実行すると、パフォーマンスのイシューが発生する可能性があります。

単一ノードの検索クラスターの場合、プライマリシャードが割り当てられているため、クラスターのステータスは常に黄色です。クラスターは、レプリカシャードをプライマリシャードと同じノードに割り当てることはできません。

バージョンの要件

Elasticsearch

高度な検索は、次のバージョンのElasticsearchで動作します。

高度な検索は、Elasticsearchのサポート終了ポリシーに従います。

OpenSearch

OpenSearch 3.xは、GitLab 18.1以降でサポートされています。詳細については、マージリクエスト192197を参照してください。

ElasticsearchまたはOpenSearchのバージョンに互換性がない場合、データ損失を防ぐために、インデックス作成は一時停止され、メッセージがelasticsearch.logファイルに記録されます。

互換性のあるバージョンを使用している場合、OpenSearchに接続した後、Elasticsearch version not compatibleというメッセージが表示されたら、インデックス作成を再開してください。

システム要件

ElasticsearchとAWS OpenSearchでは、GitLabのインストール要件よりも多くのリソースが必要です。

メモリ、CPU、ストレージの要件は、クラスターにインデックスを作成するデータの量によって異なります。頻繁に使用されるElasticsearchクラスターでは、より多くのリソースが必要になる場合があります。estimate_cluster_size Rakeタスクは、リポジトリの合計サイズを使用して、高度な検索のストレージ要件を見積もります。

アクセス要件

GitLabは、要件と使用するバックエンドサービスに応じて、HTTPベースの認証方法とロールベースの認証方法の両方をサポートしています。

Elasticsearchのロールベースのアクセス制御

Elasticsearchは、ロールベースのアクセス制御を提供して、クラスターをさらに安全にすることができます。Elasticsearchクラスターにアクセスしてオペレーションを実行するには、管理者エリアで設定されたUsernameに、次の権限を付与するロールが必要です。Usernameは、GitLabから検索クラスターにリクエストを送信します。

詳細については、Elasticsearchのロールベースのアクセス制御とElasticsearchのセキュリティ権限を参照してください。

{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["gitlab-*"],
      "privileges": [
        "create_index",
        "delete_index",
        "view_index_metadata",
        "read",
        "manage",
        "write"
      ]
    }
  ]
}

AWS OpenSearch Serviceのアクセス制御

前提要件:

• OpenSearchドメインを作成するときに、AWSServiceRoleForAmazonOpenSearchServiceという名前のAWSアカウントにサービスにリンクされたロールが必要です。
• AWS OpenSearchのドメインアクセスポリシーでは、es:ESHttp*アクションを許可する必要があります。

AWSServiceRoleForAmazonOpenSearchServiceは、すべてのOpenSearchドメインで使用されます。ほとんどの場合、AWSマネジメントコンソールを使用して最初のOpenSearchドメインを作成するときに、このロールは自動的に作成されます。サービスにリンクされたロールを手動で作成するには、AWSドキュメントを参照してください。

AWS OpenSearch Serviceには、次の3つの主要なセキュリティレイヤーがあります:

• ネットワーク
• ドメインアクセスポリシー
• きめ細かいアクセス制御

ネットワーク

このセキュリティレイヤを使用すると、ドメインを作成するときにPublic access（パブリックアクセス）を選択して、任意のクライアントからのリクエストがドメインエンドポイントに到達できるようにすることができます。VPC access（VPCアクセス）を選択した場合、リクエストがエンドポイントに到達するには、クライアントがVPCに接続している必要があります。

詳細については、AWSドキュメントを参照してください。

ドメインアクセスポリシー

GitLabは、AWS OpenSearchのドメインアクセス制御について、次の方法をサポートしています:

• Resource-based (domain) access policy（リソースベース（ドメイン）アクセスポリシー）: AWS OpenSearchドメインがIAMポリシーで設定されている場合
• Identity-based policy（IDベースのポリシー）: クライアントがIAMプリンシパルとポリシーを使用してアクセスを設定する場合

リソースベースのポリシーの例

es:ESHttp*アクションが許可されているリソースベース（ドメイン）のアクセスポリシーの例は次のとおりです:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

特定のIAMプリンシパルに対してのみes:ESHttp*アクションが許可されているリソースベース（ドメイン）のアクセスポリシーの例は次のとおりです:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

IDベースのポリシーの例

es:ESHttp*アクションが許可されているIAMプリンシパルにアタッチされたIDベースのアクセスポリシーの例は次のとおりです:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "es:ESHttp*",
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

きめ細かいアクセス制御

きめ細かいアクセス制御を有効にする場合は、次のいずれかの方法でマスターユーザーを設定する必要があります:

• IAM ARNをマスターユーザーとして設定します。
• マスターユーザーを作成します。

IAM ARNをマスターユーザーとして設定する

IAMプリンシパルをマスターユーザーとして使用する場合、クラスターへのすべてのリクエストは、AWS Signature Version 4で署名する必要があります。EC2インスタンスに割り当てたIAMロールであるIAM ARNを指定することもできます。詳細については、AWSドキュメントを参照してください。

IAM ARNをマスターユーザーとして設定するには、GitLabインスタンスでIAM認証情報を使ってAWS OpenSearch Serviceを使用する必要があります:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。

2. 設定 > 検索を選択します。

3. 高度な検索を展開します。

4. AWS OpenSearch IAMの認証情報セクションで、次の手順を実行します:

   1. IAM認証情報でAWS OpenSearchを使用しますチェックボックスをオンにします。

   2. AWSリージョンに、OpenSearchドメインがあるAWSリージョンを入力します（例: us-east-1）。

   3. AWS access key（AWSアクセスキー）とAWS secret access key（AWSシークレットアクセスキー）に、認証用のアクセスキーを入力します。

      EC2インスタンス（コンテナではなく）で直接実行されるGitLabデプロイでは、アクセスキーを入力する必要はありません。GitLabインスタンスは、AWSインスタンスメタデータサービス（IMDS）からこれらのキーを自動的に取得します。

5. 変更を保存を選択します。

マスターユーザーを作成する

内部ユーザーデータベースにマスターユーザーを作成する場合は、HTTP基本認証を使用してクラスターにリクエストを行うことができます。詳細については、AWSドキュメントを参照してください。

マスターユーザーを作成するには、GitLabインスタンスでOpenSearchドメインURLとマスターユーザー名およびパスワードを設定する必要があります:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索を展開します。
4. OpenSearch domain URL（OpenSearchドメインURL）に、OpenSearchドメインエンドポイントへのURLを入力します。
5. ユーザー名に、マスターユーザー名を入力します。
6. パスワードに、マスターパスワードを入力します。
7. 変更を保存を選択します。

新しいElasticsearchのバージョンにアップグレードする

前提要件:

• 検索がHTTP 500エラーで失敗しないように、高度な検索を無効にします。
• 変更が引き続き追跡できるように、インデックス作成を一時停止します。

Elasticsearchを新しいマイナーまたはメジャーバージョンにアップグレードする場合、GitLabの設定を変更する必要はありません。Elasticsearchクラスターが完全にアップグレードされ、アクティブになった場合:

1. クラスター接続、インデックス、検索オペレーションを検証します:

   sudo gitlab-rake gitlab:elastic:index_and_search_validation

2. インデックス作成を再開します。

3. オプション。インデックス作成状態を確認します。正しい検索結果を得るためには、インデックス作成が完了していることを確認してください。特に、Elasticsearchインスタンスがしばらくオフラインになっていた場合は注意してください。

4. 高度な検索で検索を有効にする。

Elasticsearchリポジトリインデクサー

Gitリポジトリデータにインデックスを作成するために、GitLabはgitlab-elasticsearch-indexerを使用します。自己コンパイルインストールの場合、インデクサーをインストールするを参照してください。

インデクサーをインストールする

最初にいくつかの依存関係をインストールしてから、インデクサー自体をビルドしてインストールします。

依存関係をインストールする

このプロジェクトはテキストエンコードにInternational Components for Unicode（ICU）を使用しているため、makeを実行する前に、プラットフォームの開発パッケージがインストールされていることを確認する必要があります。

Debian / Ubuntu

DebianまたはUbuntuにインストールするには、次のコマンドを実行します:

sudo apt install libicu-dev

CentOS / RHEL

CentOSまたはRHELにインストールするには、次のコマンドを実行します:

sudo yum install libicu-devel

macOS

macOSにインストールするには、次のコマンドを実行します:

brew install icu4c
export PKG_CONFIG_PATH="/usr/local/opt/icu4c/lib/pkgconfig:$PKG_CONFIG_PATH"

ビルドとインストール

インデクサーをビルドしてインストールするには、次のコマンドを実行します:

indexer_path=/home/git/gitlab-elasticsearch-indexer

# Run the installation task for gitlab-elasticsearch-indexer:
sudo -u git -H bundle exec rake gitlab:indexer:install[$indexer_path] RAILS_ENV=production
cd $indexer_path && sudo make install

gitlab-elasticsearch-indexerは/usr/local/binにインストールされます。

PREFIX環境変数を使用して、インストールパスを変更できます。その場合は、-Eフラグをsudoに渡すことを忘れないでください。

例:

PREFIX=/usr sudo -E make install

インストール後、必ずElasticsearchを有効にしてください。

インデックス作成エラーを表示する

GitLab Elasticsearchインデクサーからのエラーは、elasticsearch.logファイルとsidekiq.logファイルに記録され、その際json.exception.classの値としてGitlab::Elastic::Indexer::Errorが設定されています。これらのエラーは、Gitリポジトリデータのインデックス作成時に発生する可能性があります。

高度な検索を有効にする

前提要件:

• インスタンスへの管理者アクセス権が必要です。
• インデックスあたりのシャード数を設定します。
• インデックスあたりのレプリカ数を設定します。
• オプション。大規模インスタンスのインデックス作成の準備をします。

高度な検索を有効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. Elasticsearchクラスターの高度な検索設定を構成します。まだ高度な検索で検索チェックボックスを選択しないでください。
4. インスタンスにインデックスを作成します。
5. オプション。インデックス作成状態を確認します。
6. インデックス作成が完了したら、高度な検索で検索チェックボックスをオンにして、変更を保存を選択します。

リポジトリデータが50 GBを超えるGitLabインスタンスの場合は、大規模インスタンスにインデックスを効率的に作成するを参照してください。

インスタンスにインデックスを作成する

ユーザーインターフェースから

前提要件:

• インスタンスへの管理者アクセス権が必要です。

ユーザーインターフェースから初期インデックス作成を実行したり、インデックスを再作成したりできます。

高度な検索を有効にして、ユーザーインターフェースからインスタンスにインデックスを作成するは、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索のためのインデックス作成を有効にするチェックボックスを選択し、変更を保存を選択します。
4. インスタンスにインデックスを作成を選択します。

Rakeタスクを使用する場合

前提要件:

• インスタンスへの管理者アクセス権が必要です。

インスタンス全体にインデックスを作成するには、次のRakeタスクを使用します:

# WARNING: This task deletes all existing indices
# For installations that use the Linux package
sudo gitlab-rake gitlab:elastic:index

# WARNING: This task deletes all existing indices
# For self-compiled installations
bundle exec rake gitlab:elastic:index RAILS_ENV=production

特定のデータにインデックスを作成するには、次のRakeタスクを使用します:

# For installations that use the Linux package
sudo gitlab-rake gitlab:elastic:index_work_items
sudo gitlab-rake gitlab:elastic:index_group_wikis
sudo gitlab-rake gitlab:elastic:index_namespaces
sudo gitlab-rake gitlab:elastic:index_projects
sudo gitlab-rake gitlab:elastic:index_snippets
sudo gitlab-rake gitlab:elastic:index_users

# For self-compiled installations
bundle exec rake gitlab:elastic:index_work_items RAILS_ENV=production
bundle exec rake gitlab:elastic:index_group_wikis RAILS_ENV=production
bundle exec rake gitlab:elastic:index_namespaces RAILS_ENV=production
bundle exec rake gitlab:elastic:index_projects RAILS_ENV=production
bundle exec rake gitlab:elastic:index_snippets RAILS_ENV=production
bundle exec rake gitlab:elastic:index_users RAILS_ENV=production

インデックス作成状態を確認する

前提要件:

• インスタンスへの管理者アクセス権が必要です。

インデックス作成状態を確認するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索のインデックス作成のステータスを展開します。

バックグラウンドジョブの状態をモニタリングする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

インデックス作成の進捗状況を監視するには、バックグラウンドジョブのステータスを確認することもできます:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. モニタリング > バックグラウンドジョブを選択します。
3. Sidekiqダッシュボードでビジーを選択し、次のインデックス作成ジョブを監視します:
   • コードとコミットの場合はSearch::Elastic::CommitIndexerWorker。
   • Wikiデータの場合はElasticWikiIndexerWorker。

Elasticsearch検索を有効にする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

GitLabで高度な検索による検索を有効にするには:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索で検索チェックボックスを選択します。
4. 変更を保存を選択します。

高度な検索の設定

次のElasticsearch設定を使用できます:

インデックスを作成するネームスペースとプロジェクトデータの量を制限する

インデックスを作成するネームスペースとプロジェクトデータの量を制限するチェックボックスをオンにすると、インデックスを作成するネームスペースとプロジェクトを指定できます。ネームスペースがグループの場合、それらのサブグループ内のサブグループとプロジェクトにもインデックスが作成されます。

この設定を有効にすると、次のようになります:

• 完全なインデックス作成を行うには、ネームスペースまたはプロジェクトを指定する必要があります。
• プロジェクトレコード（プロジェクト名や説明などのメタデータ）は、常にすべてのプロジェクトに対してインデックスが作成されます。
• 脆弱性レコードは、セキュリティレポートでのフィルタリングをサポートするために、常にすべてのプロジェクトとネームスペースに対してインデックスが作成されます。
• 関連データは、指定したネームスペースとプロジェクトに対してのみインデックスが作成されます。

インデックスが作成されたネームスペース

すべてのネームスペースにインデックスを作成すると、グローバルコードおよびコミット検索で高度な検索を使用できます。一部のネームスペースのみにインデックスを作成する場合:

• グローバル検索には、コードまたはコミット検索のスコープは含まれません。
• コードおよびコミット検索は、インデックスが作成された単一のネームスペースでのみ使用できます。
• インデックスが作成された複数のネームスペース間で、単一のコードまたはコミット検索を行うことはできません。
• クロスプロジェクト検索は、インデックスが作成されたネームスペースで使用できます。

たとえば、2つの異なるグループにインデックスを作成する場合は、グループごとに個別のコード検索を実行する必要があります。

制限付きのインデックス作成でグローバル検索を有効にするには:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索を展開します。
4. Enable global search for limited indexing（制限付きのインデックス作成でグローバル検索を有効にする）を選択します。
5. 変更を保存を選択します。
6. すでにインスタンスにインデックスを作成している場合は、再度インスタンスにインデックスを作成する必要があります。これにより、既存の検索データが削除され、フィルタリングが正しく機能するようになります。

カスタム言語アナライザーを有効にする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

Elasticのsmartcnおよびkuromoji分析プラグインを使用すると、中国語と日本語の言語サポートを改善できます。

カスタム言語アナライザーを有効にするには、次の手順に従います:

1. 必要なプラグインをインストールします。プラグインのインストール手順については、Elasticsearchドキュメントを参照してください。プラグインはクラスター内のすべてのノードにインストールする必要があり、インストール後に各ノードを再起動する必要があります。プラグインのリストについては、このセクションの以下のテーブルを参照してください。
2. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
3. 設定 > 検索を選択します。
4. カスタムアナライザ: 言語サポートを見つけます。
5. Indexing（インデックス作成）のプラグインサポートを有効にします。
6. 変更を保存を選択して、変更を反映させます。
7. ゼロダウンタイムインデックス再作成をトリガーするか、最初からすべてにインデックスを再作成して、更新されたマッピングで新しいインデックスを作成します。
8. 前のステップが完了したら、検索中のプラグインサポートを有効にします。

何をインストールするかに関するガイダンスについては、次のElasticsearch言語プラグインオプションを参照してください:

高度な検索を無効にする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

GitLabで高度な検索を無効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。

2. 設定 > 検索を選択します。

3. 高度な検索のためのインデックス作成を有効にするチェックボックスと高度な検索で検索チェックボックスをオフにします。

4. 変更を保存を選択します。

5. オプション。引き続きオンラインになっているElasticsearchインスタンスの場合は、既存のインデックスを削除します:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:delete_index
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:delete_index RAILS_ENV=production

高度な検索による検索を無効にする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

GitLabで高度な検索による検索を無効にするには:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索で検索チェックボックスをオフにします。
4. 変更を保存を選択します。

インデックス作成の一時停止

前提要件:

• インスタンスへの管理者アクセス権が必要です。

インデックス作成を一時停止するには:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索を展開します。
4. 高度な検索のためのインデックス作成を一時停止チェックボックスを選択します。
5. 変更を保存を選択します。

インデックス作成を再開する

前提要件:

• インスタンスへの管理者アクセス権が必要です。

インデックス作成を再開するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索を展開します。
4. 高度な検索のためのインデックス作成を一時停止チェックボックスをオフにします。
5. 変更を保存を選択します。

ゼロダウンタイムインデックス再作成

このインデックス再作成方法の背後にある考え方は、Elasticsearch再インデックスAPIとElasticsearchインデックスエイリアス機能を活用して操作を実行することです。インデックスエイリアスは、GitLabが読み取りと書き込みに使用するprimaryインデックスに接続します。インデックス作成プロセスが開始されると、primaryインデックスへの書き込みが一時停止されます。次に、別のインデックスが作成され、Reindex APIが実行されて、インデックスデータが新しいインデックスに移行されます。インデックス作成ジョブが完了すると、インデックスエイリアスが新しいインデックスに切り替わり、新しいprimaryインデックスになります。最後に、書き込みが再開され、通常の操作が継続されます。

ゼロダウンタイムインデックス再作成を使用する

ゼロダウンタイムインデックス再作成を使用して、新しいインデックスを作成して既存のデータをコピーしないと変更できないインデックス設定またはマッピングを設定できます。欠損データを修正するために、ゼロダウンタイムインデックス再作成を使用しないでください。データにまだインデックスが作成されていない場合、ゼロダウンタイムインデックス再作成では、検索クラスタにデータは追加されません。インデックス再作成を開始する前に、すべての高度な検索の移行を完了する必要があります。

インデックス再作成をトリガーする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

インデックス再作成をトリガーするには、次の手順に従います:

1. 管理者としてGitLabインスタンスにサインインします。
2. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
3. 設定 > 検索を選択します。
4. 高度検索のゼロダウンタイムインデックス再作成を展開します。
5. クラスターのインデックス再作成をトリガーを選択します。

インデックス再作成は、Elasticsearchクラスターのサイズによっては、時間がかかるプロセスになる可能性があります。

このプロセスが完了すると、元のインデックスは14日後に削除されるようにスケジュールされます。インデックス再作成プロセスをトリガーしたページと同じページでキャンセルボタンを押すと、このアクションをキャンセルできます。

インデックス再作成の実行中に、その同じセクションで進捗を確認できます。

ゼロダウンタイムインデックス再作成をトリガーする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

ゼロダウンタイムインデックス再作成をトリガーするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。

2. 設定 > 検索を選択します。

3. 高度検索のゼロダウンタイムインデックス再作成を展開します。次の設定を使用できます:

   • スライス乗算
   • 最大実行スライス数

スライス乗算

スライス乗算は、インデックス再作成中のスライス数を計算します。

GitLabでは、手動スライスを使用して、インデックス再作成を効率的かつ安全に制御します。そのため、ユーザーは失敗したスライスのみを再試行できます。

乗算のデフォルトは2で、インデックスあたりのシャード数に適用されます。たとえば、この値が2で、インデックスに20個のシャードがある場合、インデックス再作成タスクは40個のスライスに分割されます。

最大実行スライス数

最大実行スライス数のパラメータのデフォルトは60で、Elasticsearchのインデックス再作成中に同時に実行できるスライスの最大数に相当します。

この値の設定を高くしすぎると、クラスターが検索と書き込みで過度に飽和状態になる場合があるため、パフォーマンスに悪影響を及ぼす可能性があります。この値を低く設定しすぎると、インデックス再作成プロセスの完了に非常に長い時間がかかる可能性があります。

これに最適な値は、クラスターのサイズに加えて、インデックス再作成中に検索パフォーマンスが多少低下してもよいかどうか、そしてインデックス再作成を迅速に完了してインデックス作成を再開することがどれほど重要かによって異なります。

最新のインデックス再作成ジョブを失敗としてマークし、インデックス作成を再開する

前提要件:

• インスタンスへの管理者アクセス権が必要です。

未完了のインデックス再作成ジョブを破棄し、インデックス作成を再開するには、次の手順に従います:

1. 最新のインデックス再作成ジョブを失敗としてマークします:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:mark_reindex_failed
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:mark_reindex_failed RAILS_ENV=production

2. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。

3. 設定 > 検索を選択します。

4. 高度な検索を展開します。

5. 高度な検索のためのインデックス作成を一時停止チェックボックスをオフにします。

インデックスの整合性

インデックスの整合性は、欠落しているリポジトリデータを検出して修正します。この機能は、グループまたはプロジェクトにスコープされたコード検索で結果が返されない場合に自動的に使用されます。

高度な検索の移行

移行のインデックス再作成はバックグラウンドで実行されるため、再度インスタンスに手動でインデックスを作成する必要はありません。

GitLab 18.0以降では、elastic_migration_worker_enabledアプリケーションを使用して、移行ワーカーを有効または無効にできます。デフォルトでは、移行ワーカーが有効になっています。

移行ディクショナリファイル

すべての移行では、ee/elastic/docs/フォルダーに対応するディクショナリファイルがあり、次の情報が含まれています:

name:
version:
description:
group:
milestone:
introduced_by_url:
obsolete:
marked_obsolete_by_url:
marked_obsolete_in_milestone:

たとえば、この情報を使用して、移行がいつ導入されたか、または廃止とマークされたかを特定することができます。

保留中の移行を確認する

高度な検索の保留中の移行を確認するには、次のコマンドを実行します:

curl "$CLUSTER_URL/gitlab-production-migrations/_search?size=100&q=*" | jq .

このコマンドは、次のような結果を返すはずです:

{
  "took": 14,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "gitlab-production-migrations",
        "_type": "_doc",
        "_id": "20230209195404",
        "_score": 1,
        "_source": {
          "completed": true
        }
      }
    ]
  }
}

移行のイシューをデバッグするには、elasticsearch.logファイルを確認してください。

停止した移行を再試行する

一部の移行は、再試行制限付きで作成されています。移行が再試行制限内に完了できない場合、移行は停止され、高度な検索インテグレーション設定に通知が表示されます。

移行を再試行する前に、elasticsearch.logファイルを確認して、移行が停止した理由をデバッグし、変更を加えることをお勧めします。

失敗の原因を修正できたと考えられる場合は、次の手順を実行してください:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 検索を選択します。
3. 高度な検索を展開します。
4. Elasticsearch migration halted（Elasticsearchの移行が停止しました）アラートボックス内で、移行を再試行しますを選択します。移行は、バックグラウンドで再試行されるようにスケジュールされます。

移行が成功しない場合は、インデックスをゼロから再作成するという最後の手段を検討してください。この手段では、新しく作成されたインデックスがすべての移行をスキップするため、問題をスキップできる場合があります。その理由は、正しい最新のスキーマでインデックスが再作成されたからです。

メジャーアップグレードを実行する前にすべての移行を完了する必要がある

GitLabのメジャーバージョンにアップグレードする前に、そのメジャーバージョンの前の最新マイナーバージョンまでのすべての移行を完了する必要があります。メジャーバージョンのアップグレードに進む前に、停止した移行を解決して再試行する必要もあります。詳細については、アップグレードの移行を参照してください。

削除された移行は、廃止としてマークされています。高度な検索の保留中の移行がすべて完了する前にGitLabをアップグレードすると、新しいバージョンで削除された保留中の移行は、実行または再試行されません。この場合、インデックスをゼロから再作成する必要があります。

スキップ可能な移行

スキップ可能な移行は、条件が満たされた場合にのみ実行されます。たとえば、移行が特定のElasticsearchのバージョンに依存している場合、そのバージョンに達するまでスキップされる可能性があります。

移行が廃止としてマークされるまで、スキップ可能な移行が実行されない場合、変更を適用するには、インデックスを再作成する必要があります。

GitLabの高度な検索のRakeタスク

Rakeタスクは、次の操作を行うために使用できます:

• インデクサーをビルドしてインストールする。
• Elasticsearchを無効にするときにインデックスを削除する。
• GitLabデータをインデックスに追加する。

使用可能なRakeタスクを次に示します:

環境変数

Rakeタスクに加えて、プロセスを変更するために使用できるいくつかの環境変数があります:

プロジェクトの範囲または特定のプロジェクトにインデックスを作成する

ID_FROM環境変数とID_TO環境変数を使用して、限られた数のプロジェクトにインデックスを作成することができます。これは、ステージングのインデックス作成に役立ちます。

root@git:~# sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=1 ID_TO=100

ID_FROMとID_TOはor equal to比較を使用するため、両方を同じプロジェクトIDに設定することで、これらの環境変数を使用して、1つのプロジェクトのみにインデックスを作成することができます:

root@git:~# sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=5 ID_TO=5
Indexing project repositories...I, [2019-03-04T21:27:03.083410 #3384]  INFO -- : Indexing GitLab User / test (ID=33)...
I, [2019-03-04T21:27:05.215266 #3384]  INFO -- : Indexing GitLab User / test (ID=33) is done!

高度な検索のインデックススコープ

検索を実行するときに、GitLabインデックスは次のスコープを使用します:

GitLab.comとGitLab Dedicatedでは、検索以外の機能をサポートするために、脆弱性レコードは常にすべてのプロジェクトとネームスペースに対してインデックスが作成されます。GitLab Self-Managedでの脆弱性レコードのインデックス作成は、イシュー525484で提案されています。

チューニング

最適なクラスター設定を選択するためのガイダンス

クラスター設定の選択に関する基本的なガイダンスについては、Elastic Cloud Calculatorも参照してください。

• 通常、1つのレプリカを持つ少なくとも2ノードのクラスター設定を使用してください。これにより、回復性を確保できます。ストレージの使用量が急速に増加している場合は、事前に水平スケーリング（ノードの追加）を計画してください。
• パフォーマンスに影響するため、検索クラスターでHDDストレージを使用することはお勧めしません。SSDストレージ（たとえば、NVMeまたはSATA SSDドライブ）を使用することをお勧めします。
• 大規模なインスタンスでは、調整専用ノードを使用しないでください。調整専用ノードはデータノードよりも小さいため、パフォーマンスと高度な検索の移行に影響を与える可能性があります。
• GitLab Performance Toolを使用して、検索クラスターのさまざまなサイズと設定で検索パフォーマンスのベンチマーク評価を行うことができます。
• Heap sizeは、物理RAMの50%以下に設定する必要があります。また、ゼロベース圧縮oopsのしきい値よりも大きく設定しないでください。厳密なしきい値は変化しますが、ほとんどのシステムでは26 GBが安全であり、一部のシステムでは30 GBになる可能性があります。詳細については、ヒープサイズの設定とJVMオプションの設定を参照してください。
• refresh_intervalはインデックスごとの設定です。リアルタイムでデータが必要ない場合は、デフォルトの1sからより大きな値に調整することをお勧めします。これにより、最新の結果がどれくらい速く表示されるかが変わります。リアルタイムであることが重要な場合は、できるだけデフォルト値に近い値のままにする必要があります。
• ワークロードの高いインデックス作成オペレーションが多い場合は、indices.memory.index_buffer_sizeを30%または40%に増やすことをお勧めします。

高度な検索の設定

Elasticsearchシャード数

単一ノードクラスターの場合は、インデックスあたりのElasticsearchシャード数をElasticsearchデータノード上のCPUコア数に設定します。

マルチノードクラスタリングの場合、Rakeタスクgitlab:elastic:estimate_shard_sizesを実行して、各インデックスのシャード数を決定します。このタスクは、シャードとレプリカのサイズ、およびデータベースデータを含むインデックスのおおよそのドキュメント数を推奨事項として返します。

平均シャードサイズを数GBから30 GBの間に保ちます。平均シャードサイズが30 GBを超える場合は、インデックスのシャードサイズを増やし、ゼロダウンタイムインデックス再作成をトリガーします。クラスターの健全性を確保するには、ノードあたりのシャード数が、設定されたヒープサイズの20倍を超えないようにする必要があります。たとえば、30 GBのヒープを持つノードには、最大600個のシャードが必要です。

インデックスのシャード数を更新するには、設定を変更し、ゼロダウンタイムインデックス再作成をトリガーします。

Elasticsearchレプリカ数

単一ノードクラスターの場合は、インデックスあたりのElasticsearchレプリカ数を0に設定します。

マルチノードクラスターの場合は、インデックスあたりのElasticsearchレプリカ数を1に設定します（各シャードには1つのレプリカがあります）。1つのノードを失うとインデックスが破損するため、この数は0にしないでください。

シャード割り当て認識が有効になっている場合、シャードあたりのコピーの合計数は、認識属性（通常はノードまたはゾーン）の数で均等に割り切れる必要があります。すべての認識属性にわたるシャードコピーの均等な分散により、最適な耐障害性と負荷分散が保証されます。

(1 + `number_of_replicas`) / `number_of_awareness_attributes` = whole number

インデックスのレプリカ数を更新するには、設定を変更し、ゼロダウンタイムインデックス再作成をトリガーします。

大規模なインスタンスにインデックスを効率的に作成する

前提要件:

• インスタンスへの管理者アクセス権が必要です。

高度な検索を有効にしたときに、インデックスが作成される大量のデータが原因で問題が発生する場合:

1. Elasticsearchホストおよびポートを設定します。

2. 空のインデックスを作成します:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:create_empty_index
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:create_empty_index RAILS_ENV=production

3. これがGitLabインスタンスのインデックス再作成である場合は、インデックスの状態をクリアします:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:clear_index_status
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:clear_index_status RAILS_ENV=production

4. 高度な検索のインデックス作成をオンにするチェックボックスを高度な検索のためのインデックス作成を有効にする。

5. 大規模なGitリポジトリにインデックスを作成するには、しばらく時間がかかることがあります。プロセスを高速化するために、インデックス作成速度をチューニングできます:

   • 一時的にrefresh_intervalを増やすことができます。

   • レプリカの数を0に設定できます。この設定は、インデックスの各プライマリシャードが持つコピーの数を制御します。したがって、レプリカを0にすると、ノード間のシャードのレプリケーションが効果的に無効になり、インデックス作成のパフォーマンスが向上します。これは、信頼性とクエリのパフォーマンスの点で重要なトレードオフになります。最初のインデックス作成が完了したら、レプリカを、考慮された値に設定することが重要です。

   インデックス作成時間が20%短縮されることが予想されます。インデックス作成が完了したら、refresh_intervalとnumber_of_replicasを目的の値に戻すことができます。

   このステップは省略可能ですが、大規模なインデックス作成オペレーションを大幅に高速化するのに役立ちます。

   curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
        --data '{
          "index" : {
              "refresh_interval" : "30s",
              "number_of_replicas" : 0
          } }'

6. プロジェクトとそれに関連付けられたデータにインデックスを作成します:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:index_projects
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:index_projects RAILS_ENV=production

   これにより、インデックスを作成する必要がある各プロジェクトに対してSidekiqジョブがエンキューされます。Rakeタスクでインデックス作成のステータスをクエリできます:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:index_projects_status
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:index_projects_status RAILS_ENV=production
   
   Indexing is 65.55% complete (6555/10000 projects)

   インデックスをプロジェクトの範囲に制限する場合は、ID_FROMパラメータとID_TOパラメータを指定できます:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=1001 ID_TO=2000
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:index_projects ID_FROM=1001 ID_TO=2000 RAILS_ENV=production

   ここで、ID_FROMとID_TOはプロジェクトIDです。両方のパラメータはオプションです。先程の例では、ID 1001からID 2000までのすべてのプロジェクトにインデックスを作成します。

   gitlab:elastic:index_projectsによってキューに入れられたプロジェクトインデックス作成ジョブが中断されることがあります。これには多くの理由が考えられますが、インデックス作成タスクを再度実行することは常に安全です。

   また、gitlab:elastic:clear_index_status Rakeタスクを使用して、インデクサーにすべての進捗を「忘れ」させ、インデックス作成プロセスを最初から再試行させることもできます。

7. 作業アイテム、グループウィキ、パーソナルスニペット、およびユーザーはプロジェクトに関連付けられていないため、個別にインデックス作成する必要があります:

   # For installations that use the Linux package
   sudo gitlab-rake gitlab:elastic:index_work_items
   sudo gitlab-rake gitlab:elastic:index_group_wikis
   sudo gitlab-rake gitlab:elastic:index_snippets
   sudo gitlab-rake gitlab:elastic:index_users
   
   # For self-compiled installations
   bundle exec rake gitlab:elastic:index_work_items RAILS_ENV=production
   bundle exec rake gitlab:elastic:index_group_wikis RAILS_ENV=production
   bundle exec rake gitlab:elastic:index_snippets RAILS_ENV=production
   bundle exec rake gitlab:elastic:index_users RAILS_ENV=production

8. インデックス作成後にレプリケーションと更新を再度有効にします（以前にrefresh_intervalを増やした場合のみ）:

   curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
        --data '{
          "index" : {
              "number_of_replicas" : 1,
              "refresh_interval" : "1s"
          } }'

   更新を有効にした後、強制マージを呼び出す必要があります。

   Elasticsearch 6.x以降では、強制マージを始める前に、インデックスが読み取り専用モードになっていることを確認してください:

   curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
        --data '{
          "settings": {
            "index.blocks.write": true
          } }'

   その後、強制マージを開始します:

   curl --request POST 'localhost:9200/gitlab-production/_forcemerge?max_num_segments=5'

   次に、インデックスを読み取り/書き込みモードに戻します:

   curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
        --data '{
          "settings": {
            "index.blocks.write": false
          } }'

9. インデックス作成が完了したら、高度な検索で検索チェックボックスを切り替えます。

削除されたドキュメント

インデックスが作成されたGitLabオブジェクトに変更や削除が加えられるたびに（マージリクエストの説明が変更された、ファイルがリポジトリのデフォルトブランチから削除された、プロジェクトが削除されたなど）、インデックス内のドキュメントが削除されます。ただし、これらは「ソフト」削除であるため、「削除されたドキュメント」の全体的な数、つまり無駄なスペースが増加します。

Elasticsearchは、セグメントのインテリジェントなマージを実行して、これらの削除されたドキュメントを取り除きます。ただし、GitLabインストールのアクティビティーの量と種類によっては、インデックスで最大50%の無駄なスペースが発生する可能性があります。

通常、Elasticsearchに、デフォルトの設定でスペースを自動的にマージして再利用させる必要があります。Luceneの削除済みの処理」では、「全体として、おそらく最大セグメントサイズを縮小することに加えて、Luceneのをそのままにして、削除がいつ再利用されるかをあまり気にする必要はありません。

ただし、一部の大規模なインストールでは、マージポリシー設定を調整したほうがよい場合があります:

• index.merge.policy.max_merged_segmentサイズをデフォルトの5 GBから、たぶん2 GBまたは3 GBに削減することを検討してください。マージは、セグメントに少なくとも50%の削除がある場合にのみ発生します。セグメントサイズが小さいほど、マージの頻度が高くなります。

  curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' \
       --data '{
         "index" : {
           "merge.policy.max_merged_segment": "2gb"
         }
       }'

• また、削除がどれだけ積極的にターゲットにされるかを制御するindex.merge.policy.reclaim_deletes_weightを調整することもできます。ただし、これによりコストのかかるマージの決定につながる可能性があるため、トレードオフを理解していない限り、このパラメータを変更しないことをお勧めします。

  curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' \
       --data '{
         "index" : {
           "merge.policy.reclaim_deletes_weight": "3.0"
         }
       }'

• 削除されたドキュメントを取り除くために、強制マージを実行しないでください。このドキュメントの警告には、これにより、回収されない可能性のある非常に大きなセグメントが発生し、パフォーマンスまたは可用性に関する重大な問題を引き起こす可能性があると記載されています。

専用のSidekiqノードまたはプロセスで大規模なインスタンスにインデックスを作成する

大規模なインスタンスにインデックスを作成することは、リソースを大量に消費する長時間のプロセスになることがあり、Sidekiqノードおよびプロセスに過負荷をかける可能性があります。これは、GitLabのパフォーマンスと可用性に悪影響を及ぼします。

GitLabでは複数のSidekiqプロセスを開始できるため、一連のキュー（またはキューグループ）にインデックスを作成する専用の追加プロセスを作成できます。これにより、インデックス作成キューに常に専任のワーカーを配置し、残りのキューには別の専任の作業者を配置して競合を回避できるようになります。

この目的のために、ルーティングルールオプションを使用して、ワーカー一致クエリに基づいて、Sidekiqがジョブを特定のキューにルーティングできるようにします。

これに対処するために、次の2つのオプションのいずれかを選択できます:

• 1つの単一ノードで2つのキューグループを使用します。
• 2つのキューグループを、各ノードでそれぞれ1つ使用します。

以下の手順では、sidekiq['routing_rules']のエントリを検討してください:

• ["feature_category=global_search", "global_search"]: すべてのインデックス作成ジョブがglobal_searchキューにルーティングされます。
• ["*", "default"]: 他のすべての非インデックス作成ジョブがdefaultキューにルーティングされます。

sidekiq['queue_groups']の少なくとも1つのプロセスには、mailersキューが含まれている必要があります。そうでない場合、メーラージョブはまったく処理されません。

単一ノード、2つのプロセス

1つのノードにインデックス作成Sidekiqプロセスと非インデックス作成Sidekiqプロセスの両方を作成するには、次の手順に従います:

1. Sidekiqノードで、/etc/gitlab/gitlab.rbファイルを次のように変更します:

   sidekiq['enable'] = true
   
   sidekiq['routing_rules'] = [
      ["feature_category=global_search", "global_search"],
      ["*", "default"],
   ]
   
   sidekiq['queue_groups'] = [
      "global_search", # process that listens to global_search queue
      "default,mailers" # process that listens to default and mailers queue
   ]
   
   sidekiq['concurrency'] = 20

   GitLab 16.11以前を使用している場合は、キューセレクターを明示的に無効にします:

   sidekiq['queue_selector'] = false

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

3. 他のすべてのRailsおよびSidekiqノードで、sidekiq['routing_rules']が前の設定と同じであることを確認します。

4. Rakeタスクを実行して、既存のジョブを移行します:

2つのノード、各ノードに1つのプロセス

2つのノードでこれらのキューグループを処理するには、次の手順に従います:

1. インデックス作成Sidekiqプロセスを設定するには、インデックス作成Sidekiqノードで、/etc/gitlab/gitlab.rbファイルを次のように変更します:

   sidekiq['enable'] = true
   
   sidekiq['routing_rules'] = [
      ["feature_category=global_search", "global_search"],
      ["*", "default"],
   ]
   
   sidekiq['queue_groups'] = [
     "global_search", # process that listens to global_search queue
   ]
   
   sidekiq['concurrency'] = 20

   GitLab 16.11以前を使用している場合は、キューセレクターを明示的に無効にします:

   sidekiq['queue_selector'] = false

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

3. 非インデックス作成Sidekiqプロセスを設定するには、非インデックス作成Sidekiqノードで、/etc/gitlab/gitlab.rbファイルを次のように変更します:

   sidekiq['enable'] = true
   
   sidekiq['routing_rules'] = [
      ["feature_category=global_search", "global_search"],
      ["*", "default"],
   ]
   
   sidekiq['queue_groups'] = [
      "default,mailers" # process that listens to default and mailers queue
   ]
   
   sidekiq['concurrency'] = 20

   GitLab 16.11以前を使用している場合は、キューセレクターを明示的に無効にします:

   sidekiq['queue_selector'] = false

4. 他のすべてのRailsおよびSidekiqノードで、sidekiq['routing_rules']が前の設定と同じであることを確認します。

5. ファイルを保存して、GitLabを再設定し、変更を有効にします。

6. Rakeタスクを実行して、既存のジョブを移行します:

   sudo gitlab-rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued

基本検索に戻す

Elasticsearchインデックスデータに問題が発生することがあります。そのため、GitLabでは、検索結果がない場合に、そのスコープで基本検索がサポートされていることを前提として、「基本検索」に戻すことができます。この「基本検索」は、インスタンスで高度な検索がまったく有効になっていないかのように動作し、他のデータソース（PostgreSQLデータやGitデータなど）を使用して検索を行います。

ディザスターリカバリー

ElasticsearchはGitLabのセカンダリデータストアです。Elasticsearchに保存されているすべてのデータは、他のデータソース、特にPostgreSQLやGitalyから再度派生させることができます。Elasticsearchデータストアが破損した場合は、最初からすべてを再インデックスできます。

Elasticsearchインデックスが大きすぎる場合は、最初からすべてを再インデックスすると、ダウンタイムが長くなりすぎる可能性があります。Elasticsearchインデックスの不一致を自動的に見つけて再同期することはできませんが、ログを調べて不足している更新がないかどうかを確認できます。データをより迅速に回復するには、次の操作を再び行うことができます:

1. elasticsearch.logでtrack_itemsを検索して、同期されたすべての非リポジトリ更新を行います。::Elastic::ProcessBookkeepingService.track!を介して、これらのアイテムを再度送信する必要があります。
2. elasticsearch.logでindexing_commit_rangeを検索して、すべてのリポジトリ更新を行います。ログで最も古いfrom_shaにIndexStatus#last_commit/last_wiki_commitを設定し、Search::Elastic::CommitIndexerWorkerとElasticWikiIndexerWorkerを使用して、プロジェクトの別のインデックスをトリガーする必要があります。
3. sidekiq.logでElasticDeleteProjectWorkerを検索して、すべてのプロジェクト削除を行います。別のElasticDeleteProjectWorkerをトリガーする必要があります。

Elasticsearchスナップショットを定期的に作成して、最初からすべてを再インデックスすることなく、データ損失からの復旧にかかる時間を短縮することもできます。