From 2ca866ef4dbe9a12d6aa1d8e2628de5d1bdadbc0 Mon Sep 17 00:00:00 2001
From: Hubert Maraszek <hmaraszek@gitlab.com>
Date: Mon, 22 Apr 2024 05:35:18 +0000
Subject: [PATCH] Remove unsupported GitLab versions from Gitaly docs
There is a push to remove references to unsupported GitLab versions from
the documentation. Due to the size of the undertaking, it has been split
into multiple issues. This MR resolves outdated references identified by
Vale, among others spotted manually, with changes to structure and
wording if required (for example, if the removal caused a list to have
only one bullet point).
Closes https://gitlab.com/gitlab-org/gitlab/-/issues/443317.
---
doc/administration/gitaly/configure_gitaly.md | 3 -
doc/administration/gitaly/index.md | 6 +-
doc/administration/gitaly/monitoring.md | 8 +-
doc/administration/gitaly/praefect.md | 72 +--------------
doc/administration/gitaly/recovery.md | 89 ++++---------------
doc/administration/gitaly/troubleshooting.md | 10 +--
.../gitaly/troubleshooting_gitaly_cluster.md | 29 +-----
.../operations/moving_repositories.md | 16 +---
doc/administration/raketasks/praefect.md | 2 -
.../repository_storage_paths.md | 2 +-
doc/administration/server_hooks.md | 11 +--
doc/api/project_repository_storage_moves.md | 20 +----
doc/api/projects.md | 2 +-
doc/development/git_object_deduplication.md | 4 +-
14 files changed, 43 insertions(+), 231 deletions(-)
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index 90f310725e72..3c20460ccfc3 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -323,9 +323,6 @@ Configure Gitaly server.
dir = '/var/log/gitaly'
```
- For GitLab 14.9 and earlier, set `internal_socket_dir = '/var/opt/gitlab/gitaly'` instead
- of `runtime_dir`.
-
1. Append the following to `/home/git/gitaly/config.toml` for each respective Gitaly server:
On `gitaly1.internal`:
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 273a719706a7..c443dbebc6a6 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -71,7 +71,7 @@ the current status of these issues, refer to the referenced issues and epics.
| Issue | Summary | How to avoid |
|:--------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------|
-| Gitaly Cluster + Geo - Issues retrying failed syncs | If Gitaly Cluster is used on a Geo secondary site, repositories that have failed to sync could continue to fail when Geo tries to resync them. Recovering from this state requires assistance from support to run manual steps. | No known solution prior to GitLab 15.0. In GitLab 15.0 to 15.2, enable the [`gitaly_praefect_generated_replica_paths` feature flag](#praefect-generated-replica-paths-gitlab-150-and-later) on your Geo primary site. In GitLab 15.3, the feature flag is enabled by default. |
+| Gitaly Cluster + Geo - Issues retrying failed syncs | If Gitaly Cluster is used on a Geo secondary site, repositories that have failed to sync could continue to fail when Geo tries to resync them. Recovering from this state requires assistance from support to run manual steps. | In GitLab 15.0 to 15.2, enable the [`gitaly_praefect_generated_replica_paths` feature flag](#praefect-generated-replica-paths) on your Geo primary site. In GitLab 15.3, the feature flag is enabled by default. |
| Praefect unable to insert data into the database due to migrations not being applied after an upgrade | If the database is not kept up to date with completed migrations, then the Praefect node is unable to perform standard operation. | Make sure the Praefect database is up and running with all migrations completed (For example: `/opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate-status` should show a list of all applied migrations). Consider [requesting upgrade assistance](https://about.gitlab.com/support/scheduling-upgrade-assistance/) so your upgrade plan can be reviewed by support. |
| Restoring a Gitaly Cluster node from a snapshot in a running cluster | Because the Gitaly Cluster runs with consistent state, introducing a single node that is behind results in the cluster not being able to reconcile the nodes data and other nodes data | Don't restore a single Gitaly Cluster node from a backup snapshot. If you must restore from backup:<br/><br/>1. [Shut down GitLab](../read_only_gitlab.md#shut-down-the-gitlab-ui).<br/>2. Snapshot all Gitaly Cluster nodes at the same time.<br/>3. Take a database dump of the Praefect database. |
| Limitations when running in Kubernetes, Amazon ECS, or similar | Praefect (Gitaly Cluster) is not supported and Gitaly has known limitations. For more information, see [epic 6127](https://gitlab.com/groups/gitlab-org/-/epics/6127). | Use our [reference architectures](../reference_architectures/index.md). |
@@ -344,7 +344,7 @@ Repositories are stored in the storages at the relative path determined by the [
identified by them not beginning with the `@cluster` prefix. The relative paths
follow the [hashed storage](../repository_storage_paths.md#hashed-storage) schema.
-#### Praefect-generated replica paths (GitLab 15.0 and later)
+#### Praefect-generated replica paths
> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/4218) in GitLab 15.0 [with a flag](../feature_flags.md) named `gitaly_praefect_generated_replica_paths`. Disabled by default.
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitaly/-/issues/4218) in GitLab 15.2.
@@ -494,8 +494,6 @@ You can [monitor distribution of reads](monitoring.md#monitor-gitaly-cluster) us
#### Strong consistency
-> - In GitLab 14.0, strong consistency is the primary replication method.
-
Gitaly Cluster provides strong consistency by writing changes synchronously to all healthy, up-to-date replicas. If a
replica is outdated or unhealthy at the time of the transaction, the write is asynchronously replicated to it.
diff --git a/doc/administration/gitaly/monitoring.md b/doc/administration/gitaly/monitoring.md
index 41a1f1aff338..a4dc13f78419 100644
--- a/doc/administration/gitaly/monitoring.md
+++ b/doc/administration/gitaly/monitoring.md
@@ -253,10 +253,10 @@ The following metrics are available from the `/metrics` endpoint:
They reflect configuration defined for this instance of Praefect.
- `gitaly_praefect_replication_latency_bucket`, a histogram measuring the amount of time it takes
- for replication to complete after the replication job starts. Available in GitLab 12.10 and later.
+ for replication to complete after the replication job starts.
- `gitaly_praefect_replication_delay_bucket`, a histogram measuring how much time passes between
- when the replication job is created and when it starts. Available in GitLab 12.10 and later.
-- `gitaly_praefect_connections_total`, the total number of connections to Praefect. [Introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4220) in GitLab 14.7.
+ when the replication job is created and when it starts.
+- `gitaly_praefect_connections_total`, the total number of connections to Praefect.
- `gitaly_praefect_method_types`, a count of accessor and mutator RPCs per node.
To monitor [strong consistency](index.md#strong-consistency), you can use the following Prometheus metrics:
@@ -288,8 +288,6 @@ You can also monitor the [Praefect logs](../logs/index.md#praefect-logs).
### Database metrics `/db_metrics` endpoint
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/3286) in GitLab 14.5.
-
The following metrics are available from the `/db_metrics` endpoint:
- `gitaly_praefect_unavailable_repositories`, the number of repositories that have no healthy, up to date replicas.
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index a5d045886204..7e21a630e6c8 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -495,8 +495,6 @@ praefect['configuration'] = {
### Praefect
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/2634) in GitLab 13.4, Praefect nodes can no longer be designated as `primary`.
-
If there are multiple Praefect nodes:
1. Designate one node as the deploy node, and configure it using the following steps.
@@ -1608,7 +1606,7 @@ praefect['configuration'] = {
WARNING:
Deletions were disabled by default prior to GitLab 15.9 due to a race condition with repository renames
that can cause incorrect deletions, which is especially prominent in Geo instances as Geo performs more renames
-than instances without Geo. In GitLab 15.0 to 15.5, you should enable deletions only if the [`gitaly_praefect_generated_replica_paths` feature flag](index.md#praefect-generated-replica-paths-gitlab-150-and-later) is enabled. The feature flag was removed in GitLab 15.6 making deletions always safe to enable.
+than instances without Geo. In GitLab 15.0 to 15.5, you should enable deletions only if the [`gitaly_praefect_generated_replica_paths` feature flag](index.md#praefect-generated-replica-paths) is enabled. The feature flag was removed in GitLab 15.6 making deletions always safe to enable.
By default, the worker deletes invalid metadata records. It also logs the deleted records and outputs Prometheus
metrics.
@@ -1660,14 +1658,10 @@ The output includes the number of replicas that were marked unverified.
Praefect regularly checks the health of each Gitaly node, which is used to automatically fail over
to a newly-elected primary Gitaly node if the current primary node is found to be unhealthy.
-You should use [repository-specific primary nodes](#repository-specific-primary-nodes). This is
-[the only available election strategy](https://gitlab.com/gitlab-org/gitaly/-/issues/3574) from GitLab 14.0.
+[Repository-specific primary nodes](#repository-specific-primary-nodes) is the only available election strategy.
### Repository-specific primary nodes
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/3492) in GitLab 13.12, with primary elections run when Praefect starts or the cluster's consensus of a Gitaly node's health changes.
-> - [Changed](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3543) in GitLab 14.1, primary elections are run lazily.
-
Gitaly Cluster elects a primary Gitaly node separately for each repository. Combined with
[configurable replication factors](#configure-replication-factor), you can horizontally scale storage capacity and distribute write load across Gitaly nodes.
@@ -1692,65 +1686,3 @@ If there are no valid primary candidates for a repository:
- The unhealthy primary node is demoted and the repository is left without a primary node.
- Operations that require a primary node fail until a primary is successfully elected.
-
-#### Migrate to repository-specific primary Gitaly nodes
-
-New Gitaly Clusters can start using the `per_repository` election strategy immediately.
-
-To migrate existing clusters:
-
-1. Praefect nodes didn't historically keep database records of every repository stored on the cluster. When
- the `per_repository` election strategy is configured, Praefect expects to have database records of
- each repository. A [background database migration](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2749)
- creates any missing database records for repositories. Before migrating, check Praefect's logs to verify
- that the database migration ran.
-
- Check Praefect's logs for `repository importer finished` message. The `virtual_storages` field contains
- the names of virtual storages and whether they've had any missing database records created.
-
- For example, the `default` virtual storage has been successfully migrated:
-
- ```json
- {"level":"info","msg":"repository importer finished","pid":19752,"time":"2021-04-28T11:41:36.743Z","virtual_storages":{"default":true}}
- ```
-
- If a virtual storage has not been successfully migrated, it would have `false` next to it:
-
- ```json
- {"level":"info","msg":"repository importer finished","pid":19752,"time":"2021-04-28T11:41:36.743Z","virtual_storages":{"default":false}}
- ```
-
- The database migration runs when Praefect starts. If the database migration is unsuccessful, you can restart
- a Praefect node to reattempt it.
-
-1. Running two different election strategies side by side can cause a split brain, where different
- Praefect nodes consider repositories to have different primaries. This can be avoided either:
-
- - If a short downtime is acceptable:
-
- 1. Shut down all Praefect nodes before changing the election strategy. Do this by running `gitlab-ctl stop praefect` on the Praefect nodes.
-
- 1. On the Praefect nodes, configure the election strategy in `/etc/gitlab/gitlab.rb` with `praefect['failover_election_strategy'] = 'per_repository'`.
-
- 1. Run `gitlab-ctl reconfigure && gitlab-ctl start` to reconfigure and start the Praefect nodes.
-
- - If downtime is unacceptable:
-
- 1. Determine which Gitaly node is [the current primary](troubleshooting_gitaly_cluster.md#determine-primary-gitaly-node).
-
- 1. Comment out the secondary Gitaly nodes from the virtual storage's configuration in `/etc/gitlab/gitlab.rb`
- on all Praefect nodes. This ensures there's only one Gitaly node configured, causing both of the election
- strategies to elect the same Gitaly node as the primary.
-
- 1. Run `gitlab-ctl reconfigure` on all Praefect nodes. Wait until all Praefect processes have restarted and
- the old processes have exited. This can take up to one minute.
-
- 1. On all Praefect nodes, configure the election strategy in `/etc/gitlab/gitlab.rb` with
- `praefect['failover_election_strategy'] = 'per_repository'`.
-
- 1. Run `gitlab-ctl reconfigure` on all Praefect nodes. Wait until all of the Praefect processes have restarted and
- the old processes have exited. This can take up to one minute.
-
- 1. Uncomment the secondary Gitaly node configuration commented out in the earlier step on all Praefect nodes.
-
- 1. Run `gitlab-ctl reconfigure` on all Praefect nodes to reconfigure and restart the Praefect processes.
diff --git a/doc/administration/gitaly/recovery.md b/doc/administration/gitaly/recovery.md
index 4d5481d4707b..0b4ca3e2b107 100644
--- a/doc/administration/gitaly/recovery.md
+++ b/doc/administration/gitaly/recovery.md
@@ -72,40 +72,28 @@ If the default replication factor is used, replace the node in the configuration
## Primary node failure
-> - Introduced in GitLab 13.0, Gitaly Cluster, elects the secondary with the least unreplicated writes from the primary to be the new primary. There can still be some unreplicated writes, so [data loss can occur](#check-for-data-loss).
-> - Primary node failure recovery support added in GitLab 14.1.
-
Gitaly Cluster recovers from a failing primary Gitaly node by promoting a healthy secondary as the new primary. Gitaly
Cluster:
- Elects a healthy secondary with a fully up to date copy of the repository as the new primary.
-- Repository becomes unavailable if there are no fully up to date copies of it on healthy secondaries.
+- If no fully up to date secondary is available, elects the secondary with the least unreplicated writes from the primary as the new primary.
+- Repository becomes unavailable if there are no fully up to date copies of it on healthy secondaries. Use the [Praefect `dataloss` subcommand](#check-for-data-loss) to detect it.
### Unavailable repositories
-> - From GitLab 13.0 through 14.0, repositories became read-only if they were outdated on the primary but fully up to date on a healthy secondary. `dataloss` sub-command displays read-only repositories by default through these versions.
-> - From GitLab 14.1, Praefect contains more responsive failover logic which immediately fails over to one of the fully up to date secondaries rather than placing the repository in read-only mode. From GitLab 14.1, the `dataloss` sub-command displays repositories which are unavailable due to having no fully up to date copies on healthy Gitaly nodes.
-
A repository is unavailable if all of its up to date replicas are unavailable. Unavailable repositories are
not accessible through Praefect to prevent serving stale data that may break automated tooling.
### Check for data loss
-The Praefect `dataloss` subcommand identifies:
-
-- Copies of repositories in GitLab 13.0 to GitLab 14.0 that at are likely to be outdated.
- This can help identify potential data loss after a failover.
-- Repositories in GitLab 14.1 and later that are unavailable. This helps identify potential
- data loss and repositories which are no longer accessible because all of their up-to-date
- replicas copies are unavailable.
+The Praefect `dataloss` subcommand identifies unavailable repositories. This helps identify potential data loss
+and repositories that are no longer accessible because all of their up-to-date replicas copies are unavailable.
The following parameters are available:
- `-virtual-storage` that specifies which virtual storage to check. Because they might require
- an administrator to intervene, the default behavior is to display:
- - In GitLab 13.0 to 14.0, copies of read-only repositories.
- - In GitLab 14.1 and later, unavailable repositories.
-- In GitLab 14.1 and later, [`-partially-unavailable`](#unavailable-replicas-of-available-repositories)
+ an administrator to intervene, the default behavior is to display unavailable repositories.
+- [`-partially-unavailable`](#unavailable-replicas-of-available-repositories)
that specifies whether to include in the output repositories that are available but have
some assigned copies that are not available.
@@ -124,20 +112,12 @@ Every configured virtual storage is checked if none is specified:
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dataloss
```
-Repositories are listed in the output that have either:
-
-- An outdated copy of the repository on the primary, in GitLab 13.0 to GitLab 14.0.
-- No healthy and fully up-to-date copies available, in GitLab 14.1 and later.
-
-The following information is printed for each repository:
+Repositories are listed in the output that have no healthy and fully up-to-date copies available. The following
+information is printed for each repository:
- A repository's relative path to the storage directory identifies each repository and groups the related
information.
-- The repository's current status is printed in parentheses next to the disk path:
- - In GitLab 13.0 to 14.0, either `(read-only)` if the repository's primary node is outdated
- and can't accept writes. Otherwise, `(writable)`.
- - In GitLab 14.1 and later, `(unavailable)` is printed next to the disk path if the
- repository is unavailable.
+- `(unavailable)` is printed next to the disk path if the repository is unavailable.
- The primary field lists the repository's current primary. If the repository has no primary, the field shows
`No Primary`.
- The In-Sync Storages lists replicas which have replicated the latest successful write and all writes
@@ -154,8 +134,7 @@ Additional information includes:
text is omitted if the node contains a copy of the repository but is not assigned to store
the repository. Such copies aren't kept in sync by Praefect, but may act as replication
sources to bring assigned copies up to date.
-- In GitLab 14.1 and later, `unhealthy` is printed next to the copies that are located
- on unhealthy Gitaly nodes.
+- `unhealthy` is printed next to the copies that are located on unhealthy Gitaly nodes.
Example output:
@@ -180,8 +159,6 @@ Virtual storage: default
#### Unavailable replicas of available repositories
-> - Introduced in GitLab 14.0, flag renamed from `-partially-replicated` and behavior changed.
-
To also list information of repositories which are available but are unavailable from some of the assigned nodes,
use the `-partially-unavailable` flag.
@@ -260,20 +237,8 @@ When accepting data loss, Praefect:
## Data recovery
If a Gitaly node fails replication jobs for any reason, it ends up hosting outdated versions of the
-affected repositories. Praefect provides tools for:
-
-- [Automatic](#automatic-reconciliation) reconciliation, for GitLab 13.4 and later.
-- [Manual](#manual-reconciliation) reconciliation, for:
- - GitLab 13.3 and earlier.
- - Repositories upgraded to GitLab 13.4 and later without entries in the `repositories` table. In
- GitLab 13.6 and later, [a migration is run](https://gitlab.com/gitlab-org/gitaly/-/issues/3033)
- when Praefect starts for these repositories.
-
-These tools reconcile the outdated repositories to bring them fully up to date again.
-
-### Automatic reconciliation
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/2717) in GitLab 13.4.
+affected repositories. Praefect provides tools for automatic reconciliation. These tools reconcile the outdated
+repositories to bring them fully up to date again.
Praefect automatically reconciles repositories that are not up to date. By default, this is done every
five minutes. For each outdated repository on a healthy Gitaly node, Praefect picks a
@@ -316,28 +281,8 @@ praefect['configuration'] = {
}
```
-### Manual reconciliation
-
-WARNING:
-The `reconcile` sub-command was removed in GitLab 14.1. Use [automatic reconciliation](#automatic-reconciliation) instead.
-Manual reconciliation may produce excess replication jobs and is limited in functionality. Manual reconciliation does not
-work when [repository-specific primary nodes](praefect.md#repository-specific-primary-nodes) are enabled.
-
-The Praefect `reconcile` sub-command allows for the manual reconciliation between two Gitaly nodes. The
-command replicates every repository on a later version on the reference storage to the target storage.
-
-```shell
-sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml reconcile -virtual <virtual-storage> -reference <up-to-date-storage> -target <outdated-storage> -f
-```
-
-- Replace the placeholder `<virtual-storage>` with the virtual storage containing the Gitaly node storage to be checked.
-- Replace the placeholder `<up-to-date-storage>` with the Gitaly storage name containing up to date repositories.
-- Replace the placeholder `<outdated-storage>` with the Gitaly storage name containing outdated repositories.
-
### Manually remove repositories
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3767) in GitLab 14.3.
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4054) in GitLab 14.6, support for dry-run mode.
> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4715) in GitLab 15.3, support for removing repositories from the Praefect tracking database.
The `remove-repository` Praefect sub-command removes a repository from a Gitaly Cluster, and all state associated with a given repository including:
@@ -345,7 +290,7 @@ The `remove-repository` Praefect sub-command removes a repository from a Gitaly
- On-disk repositories on all relevant Gitaly nodes.
- Any database state tracked by Praefect.
-In GitLab 14.6 and later, by default, the command operates in dry-run mode. In earlier versions, the command didn't support dry-run mode. For example:
+By default, the command operates in dry-run mode. For example:
```shell
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage <virtual-storage> -relative-path <repository>
@@ -356,7 +301,7 @@ sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.t
- In GitLab 15.3 and later, add `-db-only` to remove the Praefect tracking database entry without removing the on-disk repository. Use this option to remove orphaned database entries and to
protect on-disk repository data from deletion when a valid repository is accidentally specified. If the database entry is accidentally deleted, re-track the repository with the
[`track-repository` command](#manually-add-a-single-repository-to-the-tracking-database).
-- In GitLab 14.6 and later, add `-apply` to run the command outside of dry-run mode and remove the repository. For example:
+- Add `-apply` to run the command outside of dry-run mode and remove the repository. For example:
```shell
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage <virtual-storage> -relative-path <repository> -apply
@@ -402,7 +347,6 @@ Common maintenance tasks on the Praefect tracking database are documented in thi
### List untracked repositories
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3926) in GitLab 14.4.
> - `older-than` option added in GitLab 15.0.
The `list-untracked-repositories` Praefect sub-command lists repositories of the Gitaly Cluster that both:
@@ -439,9 +383,6 @@ sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.t
### Manually add a single repository to the tracking database
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5658) in GitLab 14.4.
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5789) in GitLab 14.6, support for immediate replication.
-
WARNING:
Because of a [known issue](https://gitlab.com/gitlab-org/gitaly/-/issues/5402), you can't add repositories to the
Praefect tracking database with Praefect-generated replica paths (`@cluster`). These repositories are not associated with the repository path used by GitLab and are
@@ -483,7 +424,7 @@ sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.t
- `-replica-path` is the relative path on physical storage. Can start with [`@cluster` or match `relative_path`](../repository_storage_paths.md#gitaly-cluster-storage).
- `-authoritative-storage` is the storage we want Praefect to treat as the primary. Required if
[per-repository replication](praefect.md#configure-replication-factor) is set as the replication strategy.
-- `-replicate-immediately`, available in GitLab 14.6 and later, causes the command to replicate the repository to its secondaries immediately.
+- `-replicate-immediately` causes the command to replicate the repository to its secondaries immediately.
Otherwise, replication jobs are scheduled for execution in the database and are picked up by a Praefect background process.
The command outputs:
diff --git a/doc/administration/gitaly/troubleshooting.md b/doc/administration/gitaly/troubleshooting.md
index ba72e2a06243..096130b4a908 100644
--- a/doc/administration/gitaly/troubleshooting.md
+++ b/doc/administration/gitaly/troubleshooting.md
@@ -251,10 +251,8 @@ server.
## Repository pushes fail with a `deny updating a hidden ref` error
-Due to [a change](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3426)
-introduced in GitLab 13.12, Gitaly has read-only, internal GitLab references that users are not
-permitted to update. If you attempt to update internal references with `git push --mirror`, Git
-returns the rejection error, `deny updating a hidden ref`.
+Gitaly has read-only, internal GitLab references that users are not permitted to update. If you attempt to update
+internal references with `git push --mirror`, Git returns the rejection error, `deny updating a hidden ref`.
The following references are read-only:
@@ -428,8 +426,8 @@ and:
## Gitaly fails to fork processes stored on `noexec` file systems
-Because of changes [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5999) in GitLab 14.10, applying the `noexec` option to a mount
-point (for example, `/var`) causes Gitaly to throw `permission denied` errors related to forking processes. For example:
+Applying the `noexec` option to a mount point (for example, `/var`) causes Gitaly to throw `permission denied` errors
+related to forking processes. For example:
```shell
fork/exec /var/opt/gitlab/gitaly/run/gitaly-2057/gitaly-git2go: permission denied
diff --git a/doc/administration/gitaly/troubleshooting_gitaly_cluster.md b/doc/administration/gitaly/troubleshooting_gitaly_cluster.md
index 1f0b75602bbb..d5e936fb0ead 100644
--- a/doc/administration/gitaly/troubleshooting_gitaly_cluster.md
+++ b/doc/administration/gitaly/troubleshooting_gitaly_cluster.md
@@ -15,8 +15,6 @@ see [Troubleshooting Gitaly](troubleshooting.md).
## Check cluster health
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5688) in GitLab 14.5.
-
The `check` Praefect sub-command runs a series of checks to determine the health of the Gitaly Cluster.
```shell
@@ -78,8 +76,6 @@ If this check fails:
### Check clock synchronization
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4225) in GitLab 14.8.
-
Authentication between Praefect and the Gitaly servers requires the server times to be
in sync so the token check succeeds.
@@ -123,34 +119,17 @@ Here are common errors and potential causes:
Some common reasons for the Praefect database to experience elevated CPU usage include:
-- Prometheus metrics scrapes [running an expensive query](https://gitlab.com/gitlab-org/gitaly/-/issues/3796). If you have GitLab 14.2
- or above, set `praefect['configuration'][:prometheus_exclude_database_from_default_metrics] = true` in `gitlab.rb`.
+- Prometheus metrics scrapes [running an expensive query](https://gitlab.com/gitlab-org/gitaly/-/issues/3796). Set
+ `praefect['configuration'][:prometheus_exclude_database_from_default_metrics] = true` in `gitlab.rb`.
- [Read distribution caching](praefect.md#reads-distribution-caching) is disabled, increasing the number of queries made to the
database when user traffic is high. Ensure read distribution caching is enabled.
## Determine primary Gitaly node
-To determine the primary node of a repository:
-
-- In GitLab 14.6 and later, use the [`praefect metadata`](#view-repository-metadata) subcommand.
-- In GitLab 13.12 to GitLab 14.5 with [repository-specific primaries](praefect.md#repository-specific-primary-nodes),
- use the [`gitlab:praefect:replicas` Rake task](../raketasks/praefect.md#replica-checksums).
-- With legacy election strategies in GitLab 13.12 and earlier, the primary was the same for all repositories in a virtual storage.
- To determine the current primary Gitaly node for a specific virtual storage:
-
- - (Recommended) Use the `Shard Primary Election` [Grafana chart](praefect.md#grafana) on the
- [`Gitlab Omnibus - Praefect` dashboard](https://gitlab.com/gitlab-org/grafana-dashboards/-/blob/master/omnibus/praefect.json).
- - If you do not have Grafana set up, use the following command on each host of each
- Praefect node:
-
- ```shell
- curl localhost:9652/metrics | grep gitaly_praefect_primaries
- ```
+To determine the primary node of a repository, use the [`praefect metadata`](#view-repository-metadata) subcommand.
## View repository metadata
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/3481) in GitLab 14.6.
-
Gitaly Cluster maintains a [metadata database](index.md#components) about the repositories stored on the cluster. Use the `praefect metadata` subcommand
to inspect the metadata for troubleshooting.
@@ -161,7 +140,7 @@ sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.t
```
When the physical path on the physical storage starts with `@cluster`, you can
-[find the repository ID in the physical path](index.md#praefect-generated-replica-paths-gitlab-150-and-later).
+[find the repository ID in the physical path](index.md#praefect-generated-replica-paths).
You can also retrieve a repository's metadata by its virtual storage and relative path:
diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md
index 8a29a870b6ac..b1bc213f324d 100644
--- a/doc/administration/operations/moving_repositories.md
+++ b/doc/administration/operations/moving_repositories.md
@@ -38,20 +38,6 @@ GitLab repositories can be associated with projects, groups, and snippets. Each
has a separate API to schedule the respective repositories to move. To move all repositories
on a GitLab instance, each of these types must be scheduled to move for each storage.
-WARNING:
-To move repositories into a [Gitaly Cluster](../gitaly/index.md#gitaly-cluster) in GitLab versions
-13.12 to 14.1, you must [enable the `gitaly_replicate_repository_direct_fetch` feature flag](../feature_flags.md).
-
-WARNING:
-Repositories can be **permanently deleted** by a call to `/projects/:project_id/repository_storage_moves`
-that attempts to move a project already stored in a Gitaly Cluster back into that cluster.
-See [this issue for more details](https://gitlab.com/gitlab-org/gitaly/-/issues/3752). This issue was fixed in
-GitLab 14.3.0 and backported to
-[14.2.4](https://about.gitlab.com/releases/2021/09/17/gitlab-14-2-4-released/),
-[14.1.6](https://about.gitlab.com/releases/2021/09/27/gitlab-14-1-6-released/),
-[14.0.11](https://about.gitlab.com/releases/2021/09/27/gitlab-14-0-11-released/), and
-[13.12.12](https://about.gitlab.com/releases/2021/09/22/gitlab-13-12-12-released/).
-
Each repository is made read-only for the duration of the move. The repository is not writable
until the move has completed.
@@ -200,7 +186,7 @@ For either Gitaly or Gitaly Cluster targets, the GitLab [backup and restore capa
should be used. Git repositories are accessed, managed, and stored on GitLab servers by Gitaly as a database. Data loss
can result from directly accessing and copying Gitaly files using tools like `rsync`.
-- From GitLab 13.3, backup performance can be improved by
+- Backup performance can be improved by
[processing multiple repositories concurrently](../../administration/backup_restore/backup_gitlab.md#back-up-git-repositories-concurrently).
- Backups can be created of just the repositories using the
[skip feature](../../administration/backup_restore/backup_gitlab.md#excluding-specific-data-from-the-backup).
diff --git a/doc/administration/raketasks/praefect.md b/doc/administration/raketasks/praefect.md
index 85d673e98281..f107777da00f 100644
--- a/doc/administration/raketasks/praefect.md
+++ b/doc/administration/raketasks/praefect.md
@@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28369) in GitLab 12.10.
-
Rake tasks are available for projects that have been created on Praefect storage. See the
[Praefect documentation](../gitaly/praefect.md) for information on configuring Praefect.
diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md
index 041d7dfb64d5..a72872c23c49 100644
--- a/doc/administration/repository_storage_paths.md
+++ b/doc/administration/repository_storage_paths.md
@@ -176,7 +176,7 @@ For example:
If Gitaly Cluster is used, Praefect manages storage locations. The internal path used by Praefect for the repository
differs from the hashed path. For more information, see
-[Praefect-generated replica paths](gitaly/index.md#praefect-generated-replica-paths-gitlab-150-and-later).
+[Praefect-generated replica paths](gitaly/index.md#praefect-generated-replica-paths).
### Object storage support
diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md
index 1055d5b97528..ed066c5daecd 100644
--- a/doc/administration/server_hooks.md
+++ b/doc/administration/server_hooks.md
@@ -10,7 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/196051) in GitLab 12.8 replacing Custom Hooks.
> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/372991) from server hooks to Git server hooks in GitLab 15.6.
Git server hooks (not to be confused with [system hooks](system_hooks.md) or [file hooks](file_hooks.md)) run custom logic
@@ -120,7 +119,7 @@ The location to copy the scripts to depends on where repositories are stored:
- In GitLab 15.2 and earlier, Gitaly Cluster uses the [hashed storage path](repository_storage_paths.md#hashed-storage)
reported by the GitLab application.
- In GitLab 15.3 and later, new repositories are created using
- [Praefect-generated replica paths](gitaly/index.md#praefect-generated-replica-paths-gitlab-150-and-later),
+ [Praefect-generated replica paths](gitaly/index.md#praefect-generated-replica-paths),
which are not the hashed storage path. The replica path can be identified by
[querying the Praefect repository metadata](../administration/gitaly/troubleshooting_gitaly_cluster.md#view-repository-metadata)
using `-relative-path` to specify the expected GitLab hashed storage path.
@@ -145,11 +144,9 @@ For Linux package installations, the directory is set in `gitlab.rb` under `gita
For self-compiled installations:
-- The directory is set in a configuration file. The location of the configuration file depends on the GitLab version:
- - For GitLab 13.1 and later, the directory is set in `gitaly/config.toml` under the `[hooks]` section. However,
+- The directory is set in `gitaly/config.toml` under the `[hooks]` section. However,
GitLab honors the `custom_hooks_dir` value in `gitlab-shell/config.yml` if the value in `gitaly/config.toml` is blank
or non-existent.
- - For GitLab 13.0 and earlier, the directory set in `gitlab-shell/config.yml`.
- The default directory is `/home/git/gitlab-shell/hooks`.
### Create the global server hook
@@ -217,8 +214,8 @@ The following GitLab environment variables are supported for all server hooks:
| Environment variable | Description |
|:---------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------|
| `GL_ID` | GitLab identifier of user or SSH key that initiated the push. For example, `user-2234` or `key-4`. |
-| `GL_PROJECT_PATH` | (GitLab 13.2 and later) GitLab project path. |
-| `GL_PROTOCOL` | (GitLab 13.2 and later) Protocol used for this change. One of: `http` (Git `push` using HTTP), `ssh` (Git `push` using SSH), or `web` (all other actions). |
+| `GL_PROJECT_PATH` | GitLab project path. |
+| `GL_PROTOCOL` | Protocol used for this change. One of: `http` (Git `push` using HTTP), `ssh` (Git `push` using SSH), or `web` (all other actions). |
| `GL_REPOSITORY` | `project-<id>` where `id` is the ID of the project. |
| `GL_USERNAME` | GitLab username of the user that initiated the push. |
diff --git a/doc/api/project_repository_storage_moves.md b/doc/api/project_repository_storage_moves.md
index 1b5a5b821084..bbc3acc55eb4 100644
--- a/doc/api/project_repository_storage_moves.md
+++ b/doc/api/project_repository_storage_moves.md
@@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31285) in GitLab 13.0.
-
Project repositories including wiki and design repositories can be moved between storages. This API can help you when
[migrating to Gitaly Cluster](../administration/gitaly/index.md#migrate-to-gitaly-cluster), for example.
@@ -200,24 +198,16 @@ Example response:
## Schedule a repository storage move for a project
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34119) in GitLab 13.1.
-> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/2618) in GitLab 13.3, original repository is automatically removed after successful move and integrity check.
-
-WARNING:
-Before GitLab 13.3, a repository move worked more like a repository copy as the
-original repository was not deleted from the original storage disk location and
-had to be manually cleaned up.
-
```plaintext
POST /projects/:project_id/repository_storage_moves
```
Parameters:
-| Attribute | Type | Required | Description |
-| --------- | ---- | -------- | ----------- |
-| `project_id` | integer | yes | ID of the project |
-| `destination_storage_name` | string | no | Name of the destination storage shard. In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitaly/-/issues/3209), the storage is selected [automatically based on storage weights](../administration/repository_storage_paths.md#configure-where-new-repositories-are-stored) if not provided |
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `project_id` | integer | yes | ID of the project |
+| `destination_storage_name` | string | no | Name of the destination storage shard. The storage is selected [automatically based on storage weights](../administration/repository_storage_paths.md#configure-where-new-repositories-are-stored) if not provided |
Example request:
@@ -250,8 +240,6 @@ Example response:
## Schedule repository storage moves for all projects on a storage shard
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47142) in GitLab 13.7.
-
Schedules repository storage moves for each project repository stored on the source storage shard.
This endpoint migrates all projects at once. For more information, see
[Move all projects](../administration/operations/moving_repositories.md#move-all-projects).
diff --git a/doc/api/projects.md b/doc/api/projects.md
index c0de6137d10a..e7b0dee77f2f 100644
--- a/doc/api/projects.md
+++ b/doc/api/projects.md
@@ -3422,7 +3422,7 @@ GET /projects/:id/snapshot
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29861) in GitLab 14.0.
Get the path to repository storage for specified project if Gitaly Cluster is not being used. If Gitaly Cluster is being used, see
-[Praefect-generated replica paths (GitLab 15.0 and later)](../administration/gitaly/index.md#praefect-generated-replica-paths-gitlab-150-and-later).
+[Praefect-generated replica paths](../administration/gitaly/index.md#praefect-generated-replica-paths).
Available for administrators only.
diff --git a/doc/development/git_object_deduplication.md b/doc/development/git_object_deduplication.md
index 0c835dd4ab8e..0498563f677f 100644
--- a/doc/development/git_object_deduplication.md
+++ b/doc/development/git_object_deduplication.md
@@ -80,7 +80,7 @@ projects benefit from the new objects that got added to the pool.
## SQL model
-As of GitLab 11.8, project repositories in GitLab do not have their own
+Project repositories in GitLab do not have their own
SQL table. They are indirectly identified by columns on the `projects`
table. In other words, the only way to look up a project repository is to
first look up its project, and then call `project.repository`.
@@ -145,7 +145,7 @@ are as follows:
of the project's repository on the new storage shard.
- If the source project of a pool gets moved to another Gitaly storage
shard or is deleted the "source project" relation is not broken.
- However, as of GitLab 12.0 a pool does not fetch from a source
+ However, a pool does not fetch from a source
unless the source is on the same Gitaly shard.
## Consistency between the SQL pool relation and Gitaly
--
GitLab