diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-09-19 23:18:09 +0000 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-09-19 23:18:09 +0000 |
| commit | 6ed4ec3e0b1340f96b7c043ef51d1b33bbe85fde (patch) | |
| tree | dc4d20fe6064752c0bd323187252c77e0a89144b /doc/development/elasticsearch.md | |
| parent | 9868dae7fc0655bd7ce4a6887d4e6d487690eeed (diff) | |
| download | gitlab-ce-6ed4ec3e0b1340f96b7c043ef51d1b33bbe85fde.tar.gz | |
Add latest changes from gitlab-org/gitlab@15-4-stable-eev15.4.0-rc42
Diffstat (limited to 'doc/development/elasticsearch.md')
| -rw-r--r-- | doc/development/elasticsearch.md | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index 47942817790..b3996e16fa1 100644 --- a/doc/development/elasticsearch.md +++ b/doc/development/elasticsearch.md @@ -277,7 +277,7 @@ These Advanced Search migrations, like any other GitLab changes, need to support Depending on the order of deployment, it's possible that the migration has started or finished and there's still a server running the application code from before the -migration. We need to take this into consideration until we can +migration. We need to take this into consideration until we can [ensure all Advanced Search migrations start after the deployment has finished](https://gitlab.com/gitlab-org/gitlab/-/issues/321619). ### Reverting a migration @@ -317,7 +317,7 @@ safely can. We choose to use GitLab major version upgrades as a safe time to remove backwards compatibility for indices that have not been fully migrated. We -[document this in our upgrade documentation](../update/index.md#upgrading-to-a-new-major-version). +[document this in our upgrade documentation](../update/index.md#upgrading-to-a-new-major-version). We also choose to replace the migration code with the halted migration and remove tests so that: @@ -399,7 +399,7 @@ that may contain information to help diagnose performance issues. ### Performance Bar -Elasticsearch requests will be displayed in the +Elasticsearch requests will be displayed in the [`Performance Bar`](../administration/monitoring/performance/performance_bar.md), which can be used both locally in development and on any deployed GitLab instance to diagnose poor search performance. This will show the exact queries being made, @@ -495,7 +495,7 @@ theoretically be used to figure out what needs to be replayed are: These updates can be replayed by triggering another `ElasticDeleteProjectWorker`. -With the above methods and taking regular +With the above methods and taking regular [Elasticsearch snapshots](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html) we should be able to recover from different kinds of data loss issues in a relatively short period of time compared to indexing everything from |