Elasticsearch

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

This page describes how to enable advanced search. When enabled, advanced search provides faster search response times and improved search features.

To enable advanced search, you must:

1. Install an Elasticsearch or AWS OpenSearch cluster.
2. Enable advanced search.

[!note] Advanced search stores all projects in the same Elasticsearch indices. However, private projects appear in search results only to users who have access.

Elasticsearch glossary

This glossary provides definitions for terms related to Elasticsearch.

• Lucene: A full-text search library written in Java.
• Near real time (NRT): Refers to the slight latency from the time to index a document to the time when it becomes searchable.
• Cluster: A collection of one or more nodes that work together to hold all the data, providing indexing and search capabilities.
• Node: A single server that works as part of a cluster.
• Index: A collection of documents that have somewhat similar characteristics.
• Document: A basic unit of information that can be indexed.
• Shards: Fully-functional and independent subdivisions of indices. Each shard is actually a Lucene index.
• Replicas: Failover mechanisms that duplicate indices.

Install an Elasticsearch or AWS OpenSearch cluster

Elasticsearch and AWS OpenSearch are not included in the Linux package. You can install a search cluster yourself or use a cloud-hosted offering such as:

• Elasticsearch Service (available on Amazon Web Services, Google Cloud Platform, and Microsoft Azure)
• Amazon OpenSearch Service

You should install the search cluster on a separate server. Running the search cluster on the same server as GitLab might lead to performance issues.

For a search cluster with a single node, the cluster status is always yellow because the primary shard is allocated. The cluster cannot assign replica shards to the same node as primary shards.

[!note] Before you use a new Elasticsearch cluster in production, see important Elasticsearch configuration.

Version requirements

Elasticsearch

{{< history >}}

• Support for Elasticsearch 6.8 removed in GitLab 15.0.

{{< /history >}}

[!warning] Support for Elasticsearch 7.x was deprecated in GitLab 18.10 and is planned for removal in 19.1.

[!note] GitLab.com uses Elasticsearch 9.x in production. For self-managed instances, Elasticsearch 9.x is the recommended version for optimal performance and forward compatibility.

Advanced search works with the following versions of Elasticsearch.

Advanced search follows the Elasticsearch end-of-life policy.

OpenSearch

OpenSearch 3.x is supported starting from GitLab 18.1. See merge request 192197 for details.

If your version of Elasticsearch or OpenSearch is incompatible, to prevent data loss, indexing pauses and a message is logged in the elasticsearch.log file.

If you are using a compatible version and after connecting to OpenSearch, you get the message Elasticsearch version not compatible, resume indexing.

System requirements

Elasticsearch and AWS OpenSearch require more resources than GitLab installation requirements.

Memory, CPU, and storage requirements depend on the amount of data you index into the cluster. Heavily used Elasticsearch clusters might require more resources. The estimate_cluster_size Rake task uses the total repository size to estimate the advanced search storage requirements.

Access requirements

GitLab supports both HTTP and role-based authentication methods depending on your requirements and the backend service you use.

Role-based access control for Elasticsearch

Elasticsearch can offer role-based access control to further secure a cluster. To access and perform operations in the Elasticsearch cluster, the Username configured in the Admin area must have roles that grant the following privileges. The Username makes requests from GitLab to the search cluster.

For more information, see Elasticsearch role based access control and Elasticsearch security privileges.

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

Access control for AWS OpenSearch Service

Prerequisites:

• You must have a service-linked role in your AWS account named AWSServiceRoleForAmazonOpenSearchService when you create OpenSearch domains.
• The domain access policy for AWS OpenSearch must allow es:ESHttp* actions.

AWSServiceRoleForAmazonOpenSearchService is used by all OpenSearch domains. In most cases, this role is created automatically when you use the AWS Management Console to create the first OpenSearch domain. To create a service-linked role manually, see the AWS documentation.

AWS OpenSearch Service has three main security layers:

• Network
• Domain access policy
• Fine-grained access control

Network

With this security layer, you can select Public access when you create a domain so requests from any client can reach the domain endpoint. If you select VPC access, clients must connect to the VPC for requests to reach the endpoint.

For more information, see the AWS documentation.

Domain access policy

GitLab supports the following methods of domain access control for AWS OpenSearch:

• Resource-based (domain) access policy: where the AWS OpenSearch domain is configured with an IAM policy
• Identity-based policy: where clients use IAM principals with policies to configure access

Resource-based policy examples

Here's an example of a resource-based (domain) access policy where es:ESHttp* actions are allowed:

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

Here's an example of a resource-based (domain) access policy where es:ESHttp* actions are allowed only for a specific IAM principal:

{
  "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/*"
    }
  ]
}

[!note] The aws_role_arn must be provided if using AWS AssumeRole across accounts. The ARN should be the role that has permissions to access OpenSearch.

Identity-based policy examples

Here's an example of an identity-based access policy attached to an IAM principal where es:ESHttp* actions are allowed:

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

Fine-grained access control

When you enable fine-grained access control, you must set a master user in one of the following ways:

• Set an IAM ARN as a master user.
• Create a master user.

Set an IAM ARN as a master user

If you use an IAM principal as a master user, all requests to the cluster must be signed with AWS Signature Version 4. You can also specify an IAM ARN, which is the IAM role you assigned to your EC2 instance. For more information, see the AWS documentation.

Prerequisites:

• Administrator access.

To set an IAM ARN as a master user, you must use AWS OpenSearch Service with IAM credentials on your GitLab instance:

1. In the upper-right corner, select Admin.

2. Select Settings > Search.

3. Expand Advanced search.

4. In the AWS OpenSearch IAM credentials section:

   1. Select the Use AWS OpenSearch Service with IAM credentials checkbox.

   2. In AWS region, enter the AWS region where your OpenSearch domain is located (for example, us-east-1).

   3. In AWS access key and AWS secret access key, enter your access keys for authentication.

      [!note] GitLab deployments that run directly on EC2 instances (not in containers) don't have to enter access keys. Your GitLab instance obtains these keys automatically from the AWS Instance Metadata Service (IMDS).

5. Select Save changes.

Create a master user

If you create a master user in the internal user database, you can use HTTP basic authentication to make requests to the cluster. For more information, see the AWS documentation.

Prerequisites:

• Administrator access.

To create a master user, you must configure the OpenSearch domain URL and the master username and password on your GitLab instance:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Expand Advanced search.
4. In OpenSearch domain URL, enter the URL to the OpenSearch domain endpoint.
5. In Username, enter the master username.
6. In Password, enter the master password.
7. Select Save changes.

Upgrade to a new Elasticsearch version

{{< history >}}

• Support for Elasticsearch 6.8 removed in GitLab 15.0.

{{< /history >}}

Prerequisites:

• Disable search with advanced search so searches do not fail with an HTTP 500 error.
• Pause indexing so changes can still be tracked.

When you upgrade Elasticsearch to a new minor or major version, you do not have to change the GitLab configuration. When the Elasticsearch cluster is fully upgraded and active:

1. Validate cluster connectivity, index, and search operations:

   shellCopy

   sudo gitlab-rake gitlab:elastic:index_and_search_validation
   

2. Resume indexing.

3. Optional. Check indexing status. For correct search results, ensure indexing is complete especially if your Elasticsearch instance was offline for some time.

4. Enable search with advanced search.

Elasticsearch repository indexer

To index Git repository data, GitLab uses gitlab-elasticsearch-indexer. For self-compiled installations, see install the indexer.

Install the indexer

You first install some dependencies and then build and install the indexer itself.

Install dependencies

This project relies on International Components for Unicode (ICU) for text encoding, so ensure the development packages for your platform are installed before running make.

Debian / Ubuntu

To install on Debian or Ubuntu, run:

sudo apt install libicu-dev

CentOS / RHEL

To install on CentOS or RHEL, run:

sudo yum install libicu-devel

macOS

[!note] You must first install Homebrew.

To install on macOS, run:

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

Build and install

To build and install the indexer, run:

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

The gitlab-elasticsearch-indexer is installed to /usr/local/bin.

You can change the installation path with the PREFIX environment variable. Remember to pass the -E flag to sudo if you do so.

Example:

PREFIX=/usr sudo -E make install

After installation, be sure to enable Elasticsearch.

[!note] If you see an error such as Permission denied - /home/git/gitlab-elasticsearch-indexer/ while indexing, you may need to set the production -> elasticsearch -> indexer_path setting in your gitlab.yml file to /usr/local/bin/gitlab-elasticsearch-indexer, which is where the binary is installed.

View indexing errors

Errors from the GitLab Elasticsearch Indexer are reported in the elasticsearch.log file and the sidekiq.log file with a json.exception.class of Gitlab::Elastic::Indexer::Error. These errors may occur when indexing Git repository data.

Enable advanced search

Prerequisites:

• You must have administrator access to the instance.
• Configure the number of shards per index.
• Configure the number of replicas per index.
• Optional. Prepare for indexing large instances.

To enable advanced search:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Configure the advanced search settings for your Elasticsearch cluster. Do not select the Search with advanced search checkbox yet.
4. Index the instance.
5. Optional. Check indexing status.
6. After the indexing is complete, select the Search with advanced search checkbox, then select Save changes.

[!note] When your Elasticsearch cluster is down while Elasticsearch is enabled, you might have problems updating documents such as issues because your instance queues a job to index the change, but cannot find a valid Elasticsearch cluster.

For GitLab instances with more than 50 GB of repository data, see Index large instances efficiently.

Index the instance

From the user interface

{{< history >}}

• Introduced in GitLab 17.3.

{{< /history >}}

Prerequisites:

• You must have administrator access to the instance.

You can perform initial indexing or re-create an index from the user interface.

To enable advanced search and index the instance from the user interface:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Select the Turn on indexing for advanced search checkbox, then select Save changes.
4. Select Index the instance.

With a Rake task

Prerequisites:

• You must have administrator access to the instance.

To index the entire instance, use the following Rake tasks:

# 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

To index specific data, use the following Rake tasks:

# 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

Check indexing status

Prerequisites:

• You must have administrator access to the instance.

To check indexing status:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Expand Advanced search indexing status.

Monitor the status of background jobs

Prerequisites:

• You must have administrator access to the instance.

To monitor indexing progress, you can also check the status of background jobs:

1. In the upper-right corner, select Admin.
2. Select Monitoring > Background jobs.
3. On the Sidekiq dashboard, select Busy and watch for these indexing jobs:
   • Search::Elastic::CommitIndexerWorker for code and commits.
   • ElasticWikiIndexerWorker for wiki data.

Enable search with advanced search

Prerequisites:

• You must have administrator access to the instance.

To enable search with advanced search in GitLab:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Select the Search with advanced search checkbox.
4. Select Save changes.

Enable code search with advanced search

Prerequisites:

• You must have administrator access to the instance.

To enable code search with advanced search in GitLab:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Select the Code search with advanced search checkbox.
4. Select Save changes.

Advanced search configuration

The following Elasticsearch settings are available:

[!warning] Increasing the values of Maximum bulk request size (MiB) and Bulk request concurrency can negatively impact Sidekiq performance. Return them to their default values if you see increased scheduling_latency_s durations in your Sidekiq logs. For more information, see issue 322147.

Limit the amount of namespace and project data to index

{{< history >}}

• Indexing all project records introduced in GitLab 16.7 with a flag named search_index_all_projects. Disabled by default.
• Generally available in GitLab 16.11. Feature flag search_index_all_projects removed.
• Indexing vulnerability records introduced on GitLab.com and GitLab Dedicated in GitLab 18.1 with a flag named vulnerability_es_ingestion. Disabled by default.
• Indexing vulnerability records is generally available on GitLab.com and GitLab Dedicated in GitLab 18.2. Feature flag vulnerability_es_ingestion removed.

{{< /history >}}

[!flag] The availability of this feature is controlled by a feature flag. For more information, see the history.

When you select the Limit the amount of namespace and project data to index checkbox, you can specify namespaces and projects to index. If the namespace is a group, any subgroups and projects in these subgroups are also indexed.

When you enable this setting:

• Namespaces or projects must be specified for full indexing.
• Project records (metadata like project names and descriptions) are always indexed for all projects.
• Vulnerability records are always indexed for all projects and namespaces to support filtering in security reports.
• Associated data is indexed only for the namespaces and projects you specify.

[!warning] If you do not specify any namespace or project after you enable this setting, only project records are indexed and no associated data can be searched.

Indexed namespaces

{{< history >}}

• Global search for limited indexing introduced in GitLab 13.4 with a flag named advanced_global_search_for_limited_indexing. Disabled by default.
• Enabled on GitLab.com in GitLab 14.2.
• Global search for limited indexing generally available in GitLab 17.11 as a UI option, instead of the advanced_global_search_for_limited_indexing flag.

{{< /history >}}

When you index all namespaces, you can use advanced search for global code and commit search. When you index only some namespaces:

• Global search does not include a code or commit search scope.
• Code and commit searches are available only in a single indexed namespace.
• A single code or commit search is not possible across multiple indexed namespaces.
• Cross-project search is available in an indexed namespace.

For example, if you index two separate groups, you must run separate code searches on each group individually.

To enable global search for limited indexing:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Expand Advanced search
4. Select Enable global search for limited indexing.
5. Select Save changes.
6. If you've already indexed your instance, you must reindex the instance. This deletes existing search data, to enable filtering to work correctly.

Enable custom language analyzers

Prerequisites:

• You must have administrator access to the instance.

You can improve language support for Chinese and Japanese by using the smartcn and kuromoji analysis plugins from Elastic.

To enable custom language analyzers:

1. Install the desired plugins, refer to Elasticsearch documentation for plugins installation instructions. The plugins must be installed on every node in the cluster, and each node must be restarted after installation. For a list of plugins, see the table later in this section.
2. In the upper-right corner, select Admin.
3. Select Settings > Search.
4. Locate Custom analyzers: language support.
5. Enable plugins support for Indexing.
6. Select Save changes for the changes to take effect.
7. Trigger zero-downtime reindexing or reindex everything from scratch to create a new index with updated mappings.
8. Enable plugins support for Searching after the previous step is completed.

For guidance on what to install, see the following Elasticsearch language plugin options:

Disable advanced search

Prerequisites:

• You must have administrator access to the instance.

To disable advanced search in GitLab:

1. In the upper-right corner, select Admin.

2. Select Settings > Search.

3. Clear the Turn on indexing for advanced search and Search with advanced search checkboxes.

4. Select Save changes.

5. Optional. For Elasticsearch instances that are still online, delete existing indices:

   shellCopy

   # 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
   

Disable search with advanced search

Prerequisites:

• You must have administrator access to the instance.

To disable search with advanced search in GitLab:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Clear the Search with advanced search checkbox.
4. Select Save changes.

Disable code search with advanced search

Prerequisites:

• You must have administrator access to the instance.

To disable code search with advanced search in GitLab:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Clear the Code search with advanced search checkbox.
4. Select Save changes.

Pause indexing

Prerequisites:

• You must have administrator access to the instance.

To pause indexing:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Expand Advanced search.
4. Select the Pause indexing for advanced search checkbox.
5. Select Save changes.

Resume indexing

Prerequisites:

• You must have administrator access to the instance.

To resume indexing:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Expand Advanced search.
4. Clear the Pause indexing for advanced search checkbox.
5. Select Save changes.

Zero-downtime reindexing

The idea behind this reindexing method is to use the Elasticsearch reindex API and Elasticsearch index alias feature to perform the operation. An index alias connects to a primary index that GitLab uses for reads and writes. When the reindexing process starts, writes to the primary index are temporarily paused. Then, another index is created and the Reindex API is invoked to migrate the index data to the new index. After the reindexing job is complete, the index alias switches to the new index, which becomes the new primary index. Finally, writes resume and typical operation continues.

Using zero-downtime reindexing

You can use zero-downtime reindexing to configure index settings or mappings that cannot be changed without creating a new index and copying existing data. You should not use zero-downtime reindexing to fix missing data. Zero-downtime reindexing does not add data to the search cluster if the data is not already indexed. You must complete all advanced search migrations before you start reindexing.

Trigger reindexing

Prerequisites:

• You must have administrator access to the instance.

To trigger reindexing:

1. Sign in to your GitLab instance as an administrator.
2. In the upper-right corner, select Admin.
3. Select Settings > Search.
4. Expand Advanced search zero-downtime reindexing.
5. Select Trigger cluster reindexing.

Reindexing can be a lengthy process depending on the size of your Elasticsearch cluster.

After this process is completed, the original index is scheduled to be deleted after 14 days. You can cancel this action by pressing the Cancel button on the same page you triggered the reindexing process.

While the reindexing is running, you can follow its progress under that same section.

Trigger zero-downtime reindexing

Prerequisites:

• You must have administrator access to the instance.

To trigger zero-downtime reindexing:

1. In the upper-right corner, select Admin.

2. Select Settings > Search.

3. Expand Advanced search zero-downtime reindexing. The following settings are available:

   • Slice multiplier
   • Maximum running slices

Slice multiplier

The slice multiplier calculates the number of slices during reindexing.

GitLab uses manual slicing to control the reindex efficiently and safely, which enables users to retry only failed slices.

The multiplier defaults to 2 and applies to the number of shards per index. For example, if this value is 2 and your index has 20 shards, then the reindex task is split into 40 slices.

Maximum running slices

The maximum running slices parameter defaults to 60 and corresponds to the maximum number of slices allowed to run concurrently during Elasticsearch reindexing.

Setting this value too high can have adverse performance impacts as your cluster may become heavily saturated with searches and writes. Setting this value too low may lead the reindexing process to take a very long time to complete.

The best value for this depends on your cluster size, whether you're willing to accept some degraded search performance during reindexing, and how important it is for the reindex to finish quickly and resume indexing.

Mark the most recent reindexing job as failed and resume indexing

Prerequisites:

• You must have administrator access to the instance.

To abandon an unfinished reindexing job and resume indexing:

1. Mark the most recent reindexing job as failed:

   shellCopy

   # 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. In the upper-right corner, select Admin.

3. Select Settings > Search.

4. Expand Advanced search.

5. Clear the Pause indexing for advanced search checkbox.

Index integrity

{{< history >}}

• Introduced in GitLab 15.10 with a flag named search_index_integrity. Disabled by default.
• Generally available in GitLab 16.4. Feature flag search_index_integrity removed.

{{< /history >}}

Index integrity detects and fixes missing repository data. This feature is automatically used when code searches scoped to a group or project return no results.

Advanced search migrations

Reindex migrations run in the background, which means you do not have to reindex the instance manually.

In GitLab 18.0 and later, you can use the elastic_migration_worker_enabled application setting to enable or disable the migration worker. By default, the migration worker is enabled.

Migration dictionary files

{{< history >}}

• Introduced in GitLab 16.3.

{{< /history >}}

Every migration has a corresponding dictionary file in the ee/elastic/docs/ folder with the following information:

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

You can use this information, for example, to identify when a migration was introduced or was marked as obsolete.

Check for pending migrations

To check for pending advanced search migrations, run this command:

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

This should return something similar to:

{
  "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
        }
      }
    ]
  }
}

To debug issues with the migrations, check the elasticsearch.log file.

Retry a halted migration

Some migrations are built with a retry limit. If the migration cannot finish within the retry limit, it is halted and a notification is displayed in the advanced search integration settings.

It is recommended to check the elasticsearch.log file to debug why the migration was halted and make any changes before retrying the migration.

When you believe you've fixed the cause of the failure:

1. In the upper-right corner, select Admin.
2. Select Settings > Search.
3. Expand Advanced search.
4. Inside the Elasticsearch migration halted alert box, select Retry migration. The migration is scheduled to be retried in the background.

If you cannot get the migration to succeed, you may consider the last resort to recreate the index from scratch. This may allow you to skip over the problem because a newly created index skips all migrations as the index is recreated with the correct up-to-date schema.

All migrations must be finished before doing a major upgrade

Before upgrading to a major GitLab version, you must complete all migrations that exist up until the latest minor version before that major version. You must also resolve and retry any halted migrations before proceeding with a major version upgrade. For more information, see Migrations for upgrades.

Migrations that have been removed are marked as obsolete. If you upgrade GitLab before all pending advanced search migrations are completed, any pending migrations that have been removed in the new version cannot be executed or retried. In this case, you must re-create your index from scratch.

Skippable migrations

Skippable migrations are only executed when a condition is met. For example, if a migration depends on a specific version of Elasticsearch, it could be skipped until that version is reached.

If a skippable migration is not executed by the time the migration is marked as obsolete, to apply the change you must re-create the index.

GitLab advanced search Rake tasks

Rake tasks are available to:

• Build and install the indexer.
• Delete indices when disabling Elasticsearch.
• Add GitLab data to an index.

The following are some available Rake tasks:

Environment variables

In addition to the Rake tasks, there are some environment variables that can be used to modify the process:

Indexing a range of projects or a specific project

Using the ID_FROM and ID_TO environment variables, you can index a limited number of projects. This can be useful for staging indexing.

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

Because ID_FROM and ID_TO use the or equal to comparison, you can use them to index only one project by setting both to the same project ID:

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!

Advanced search index scopes

When performing a search, the GitLab index uses the following scopes:

On GitLab.com and GitLab Dedicated, vulnerability records are always indexed for all projects and namespaces to support features outside of search. Indexing vulnerability records on GitLab Self-Managed is proposed in issue 525484.

Tuning

Guidance on choosing optimal cluster configuration

For basic guidance on choosing a cluster configuration, see also Elastic Cloud Calculator.

• Generally, you want to use at least a 2-node cluster configuration with one replica, which allows you to have resilience. If your storage usage is growing quickly, you may want to plan horizontal scaling (adding more nodes) beforehand.
• It's not recommended to use HDD storage with the search cluster, because it takes a hit on performance. It's better to use SSD storage (NVMe or SATA SSD drives for example).
• You should not use coordinating-only nodes with large instances. Coordinating-only nodes are smaller than data nodes, which can impact performance and advanced search migrations.
• You can use the GitLab Performance Tool to benchmark search performance with different search cluster sizes and configurations.
• Heap size should be set to no more than 50% of your physical RAM. Additionally, it shouldn't be set to more than the threshold for zero-based compressed oops. The exact threshold varies, but 26 GB is safe on most systems, but can also be as large as 30 GB on some systems. See Heap size settings and Setting JVM options for more details.
• refresh_interval is a per index setting. You may want to adjust that from default 1s to a bigger value if you don't need data in real-time. This changes how soon you see fresh results. If that's important for you, you should leave it as close as possible to the default value.
• You might want to raise indices.memory.index_buffer_size to 30% or 40% if you have a lot of heavy indexing operations.

Advanced search settings

Number of Elasticsearch shards

{{< history >}}

• gitlab:elastic:estimate_shard_sizes introduced in GitLab 16.11.
• gitlab:elastic:estimate_shard_sizes changed in GitLab 18.3 to include sizing for indices that contain repository data.

{{< /history >}}

For single-node clusters, set the number of Elasticsearch shards per index to the number of CPU cores on the Elasticsearch data nodes.

For multi-node clusters, run the Rake task gitlab:elastic:estimate_shard_sizes to determine the number of shards for each index. The task returns recommendations for shard and replica sizes and approximate document counts for indices that contain database data.

Keep the average shard size between a few GB and 30 GB. If the average shard size grows to more than 30 GB, increase the shard size for the index and trigger zero-downtime reindexing. To ensure the cluster is healthy, the number of shards per node must not exceed 20 times the configured heap size. For example, a node with a 30 GB heap must have a maximum of 600 shards.

To update the number of shards for an index, change the setting and trigger zero-downtime reindexing.

Number of Elasticsearch replicas

For single-node clusters, set the number of Elasticsearch replicas per index to 0.

For multi-node clusters, set the number of Elasticsearch replicas per index to 1 (each shard has one replica). The number must not be 0 because losing one node corrupts the index.

If shard allocation awareness is enabled, the total number of copies per shard must be evenly divisible by the number of awareness attributes (typically nodes or zones). The even distribution of shard copies across all awareness attributes ensures optimal fault tolerance and load distribution.

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

To update the number of replicas for an index, change the setting and trigger zero-downtime reindexing.

Index large instances efficiently

Prerequisites:

• You must have administrator access to the instance.

[!warning] Indexing a large instance generates a lot of Sidekiq jobs. Make sure to prepare for this task by having a scalable setup or by creating extra Sidekiq processes.

Both Geo primary and secondary nodes point to the same Elasticsearch cluster. However, Elasticsearch indexing workers run only on the Sidekiq nodes of the primary site.

For this reason, you must configure any extra Sidekiq processes on the primary site's Sidekiq nodes.

If enabling advanced search causes problems due to large volumes of data being indexed:

1. Configure your Elasticsearch host and port.

2. Create empty indices:

   shellCopy

   # 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. If this is a reindex of your GitLab instance, clear the index status:

   shellCopy

   # 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. Select the Turn on indexing for advanced search checkbox.

5. Indexing large Git repositories can take a while. To speed up the process, you can tune for indexing speed:

   • You can temporarily increase refresh_interval.

   • You can set the number of replicas to 0. This setting controls the number of copies each primary shard of an index has. Thus, having 0 replicas effectively disables the replication of shards across nodes, which should increase the indexing performance. This is an important trade-off in terms of reliability and query performance. It is important to remember to set the replicas to a considered value after the initial indexing is complete.

   You can expect a 20% decrease in indexing time. After the indexing is complete, you can set refresh_interval and number_of_replicas back to their desired values.

   [!note] This step is optional but may help significantly speed up large indexing operations.

   shellCopy

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

6. Index projects and their associated data:

   shellCopy

   # 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
   

   This enqueues a Sidekiq job for each project that needs to be indexed. You can query indexing status with a Rake task:

   shellCopy

   # 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). Considers only code, commits, and wikis.
   

   If you want to limit the index to a range of projects you can provide the ID_FROM and ID_TO parameters:

   shellCopy

   # 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
   

   Where ID_FROM and ID_TO are project IDs. Both parameters are optional. The previous example indexes all projects from ID 1001 up to (and including) ID 2000.

   [!note] Sometimes the project indexing jobs queued by gitlab:elastic:index_projects can get interrupted. This may happen for many reasons, but it's always safe to run the indexing task again.

   You can also use the gitlab:elastic:clear_index_status Rake task to force the indexer to "forget" all progress, so it retries the indexing process from the start.

7. Work items, group wikis, personal snippets, and users are not associated with a project and must be indexed separately:

   shellCopy

   # 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. Enable replication and refreshing again after indexing (only if you previously increased refresh_interval):

   shellCopy

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

   A force merge should be called after enabling refreshing.

   For Elasticsearch 6.x and later, ensure the index is in read-only mode before proceeding with the force merge:

   shellCopy

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

   Then, initiate the force merge:

   shellCopy

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

   Then, change the index back to read-write mode:

   shellCopy

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

9. After the indexing is complete, select the Search with advanced search checkbox.

Index large instances with dedicated Sidekiq nodes or processes

[!warning] For most instances, you do not have to configure dedicated Sidekiq nodes or processes. The following steps use an advanced setting of Sidekiq called routing rules. Be sure to fully understand about the implication of using routing rules to avoid losing jobs entirely.

Indexing a large instance can be a lengthy and resource-intensive process that has the potential of overwhelming Sidekiq nodes and processes. This negatively affects the GitLab performance and availability.

As GitLab allows you to start multiple Sidekiq processes, you can create an additional process dedicated to indexing a set of queues (or queue group). This way, you can ensure that indexing queues always have a dedicated worker, while the rest of the queues have another dedicated worker to avoid contention.

For this purpose, use the routing rules option that allows Sidekiq to route jobs to a specific queue based on worker matching query.

[!note] Routing rules (sidekiq['routing_rules']) must be the same across all GitLab nodes (especially GitLab Rails and Sidekiq nodes).

You can choose one of the two following options to handle this:

• Use two queue groups on one single node.
• Use two queue groups, one on each node.

For the following steps, consider the entry of sidekiq['routing_rules']:

• ["feature_category=global_search", "global_search"] as all indexing jobs are routed to the global_search queue.
• ["*", "default"] as all other non-indexing jobs are routed to the default queue.

At least one process in sidekiq['queue_groups'] has to include the mailers queue, otherwise mailers jobs are not processed at all.

[!warning] When starting multiple processes, the number of processes cannot exceed the number of CPU cores you want to dedicate to Sidekiq. Each Sidekiq process can use only one CPU core, subject to the available workload and concurrency settings. For more details, see how to run multiple Sidekiq processes.

Single node, two processes

To create both an indexing and a non-indexing Sidekiq process in one node:

1. On your Sidekiq node, change the /etc/gitlab/gitlab.rb file to:

   rubyCopy

   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
   

   If you are using GitLab 16.11 and earlier, explicitly disable any queue selectors:

   rubyCopy

   sidekiq['queue_selector'] = false
   

2. Save the file and reconfigure GitLab for the changes to take effect.

3. On all other Rails and Sidekiq nodes, ensure that sidekiq['routing_rules'] is the same as the previous configuration.

4. Run the Rake task to migrate existing jobs:

[!note] It is important to run the Rake task immediately after reconfiguring GitLab. After reconfiguring GitLab, existing jobs are not processed until the Rake task starts to migrate the jobs.

Two nodes, one process for each

To handle these queue groups on two nodes:

1. To set up the indexing Sidekiq process, on your indexing Sidekiq node, change the /etc/gitlab/gitlab.rb file to:

   rubyCopy

   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
   

   If you are using GitLab 16.11 and earlier, explicitly disable any queue selectors:

   rubyCopy

   sidekiq['queue_selector'] = false
   

2. Save the file and reconfigure GitLab for the changes to take effect.

3. To set up the non-indexing Sidekiq process, on your non-indexing Sidekiq node, change the /etc/gitlab/gitlab.rb file to:

   rubyCopy

   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
   

   If you are using GitLab 16.11 and earlier, explicitly disable any queue selectors:

   rubyCopy

   sidekiq['queue_selector'] = false
   

4. On all other Rails and Sidekiq nodes, ensure that sidekiq['routing_rules'] is the same as the previous configuration.

5. Save the file and reconfigure GitLab for the changes to take effect.

6. Run the Rake task to migrate existing jobs:

   shellCopy

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

[!note] It is important to run the Rake task immediately after reconfiguring GitLab. After reconfiguring GitLab, existing jobs are not processed until the Rake task starts to migrate the jobs.

Deleted documents

Whenever a change or deletion is made to an indexed GitLab object (a merge request description is changed, a file is deleted from the default branch in a repository, a project is deleted, etc), a document in the index is deleted. However, because these are "soft" deletes, the overall number of "deleted documents", and therefore wasted space, increases.

Elasticsearch does intelligent merging of segments to remove these deleted documents. However, depending on the amount and type of activity in your GitLab installation, it's possible to see as much as 50% of wasted space in the index.

You should generally let Elasticsearch merge and reclaim space automatically with the default settings. From Lucene's Handling of Deleted Documents, "Overall, besides perhaps decreasing the maximum segment size, it is best to leave Lucene defaults as-is and not fret too much about when deletes are reclaimed."

However, some larger installations may wish to tune the merge policy settings:

• Consider reducing the index.merge.policy.max_merged_segment size from the default 5 GB to maybe 2 GB or 3 GB. Merging only happens when a segment has at least 50% deletions. Smaller segment sizes allows merging to happen more frequently.

  shellCopy

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

• You can also adjust index.merge.policy.reclaim_deletes_weight, which controls how aggressively deletions are targeted. But this can lead to costly merge decisions, so you should not change this unless you understand the tradeoffs.

  shellCopy

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

• Do not do a force merge to remove deleted documents. A warning in the documentation states that this can lead to very large segments that may never get reclaimed, and can also cause significant performance or availability issues.

Reverting to Basic Search

Sometimes there may be issues with your Elasticsearch index data and as such GitLab allows you to revert to "basic search" when there are no search results and assuming that basic search is supported in that scope. This "basic search" behaves as though you don't have advanced search enabled at all for your instance and search using other data sources (such as PostgreSQL data and Git data).

Disaster recovery

Elasticsearch is a secondary data store for GitLab. All of the data stored in Elasticsearch can be derived again from other data sources, specifically PostgreSQL and Gitaly. If the Elasticsearch data store gets corrupted, you can reindex everything from scratch.

If your Elasticsearch index is too large, it might cause too much downtime to reindex everything from scratch. You cannot automatically find discrepancies and resync an Elasticsearch index, but you can inspect the logs for any missing updates. To recover data more quickly, you can replay:

1. All synced non-repository updates by searching in elasticsearch.log for track_items. You must send these items again through ::Elastic::ProcessBookkeepingService.track!.
2. All repository updates by searching in elasticsearch.log for indexing_commit_range. You must set IndexStatus#last_commit/last_wiki_commit to the oldest from_sha in the logs and then trigger another index of the project with Search::Elastic::CommitIndexerWorker and ElasticWikiIndexerWorker.
3. All project deletes by searching in sidekiq.log for ElasticDeleteProjectWorker. You must trigger another ElasticDeleteProjectWorker.

You can also take regular Elasticsearch snapshots to reduce the time it takes to recover from data loss without reindexing everything from scratch.