doc/administration/gitaly/praefect/troubleshooting.md
{{< details >}}
{{< /details >}}
Refer to the information below when troubleshooting Gitaly Cluster (Praefect). For information on troubleshooting Gitaly, see Troubleshooting Gitaly.
You must have administrator access.
The check Praefect sub-command runs a series of checks to determine the health of the Gitaly Cluster (Praefect).
gitlab-ctl praefect check
If Praefect is deployed by using the Praefect chart, run the binary directly.
/usr/local/bin/praefect check
The following sections describe the checks that are run.
Because Database migrations must be up to date for Praefect to work correctly, checks if Praefect migrations are up to date.
If this check fails:
schema_migrations table in the database to see which migrations have run.praefect sql-migrate to bring the migrations up to date.Checks if Praefect can reach all of its Gitaly nodes, and if each Gitaly node has read and write access to all of its storages.
If this check fails:
gitaly process being run as git. There might be a permissions issue that is preventing Gitaly from
accessing its storage directories.Checks if Praefect can read from and write to the database.
If this check fails:
See if the Praefect database is in recovery mode. In recovery mode, tables may be read only. To check, run:
select pg_is_in_recovery()
Confirm that the user that Praefect uses to connect to PostgreSQL has read and write access to the database.
See if the database has been placed into read-only mode. To check, run:
show default_transaction_read_only
Checks how many repositories are inaccessible because they are missing a primary assignment, or their primary is unavailable.
If this check fails:
praefect ping-nodes to check.If you receive an error, check /var/log/gitlab/gitlab-rails/production.log.
Here are common errors and potential causes:
ActionView::Template::Error (7:permission denied)
praefect['configuration'][:auth][:token] and gitlab_rails['gitaly_token'] do not match on the GitLab server.gitlab_rails['repositories_storages'] storage configuration is missing on the Sidekiq server.Unable to save project. Error: 7:permission denied
praefect['configuration'][:virtual_storage] on GitLab server does not match the
value in gitaly['auth_token'] on one or more Gitaly servers.GRPC::Unavailable (14:failed to connect to all addresses)
GRPC::Unavailable (14:all SubCons are in TransientFailure...)
Some common reasons for the Praefect database to experience elevated CPU usage include:
praefect['configuration'][:prometheus_exclude_database_from_default_metrics] = true in gitlab.rb.To determine the primary node of a repository, use the praefect metadata subcommand.
Gitaly Cluster (Praefect) maintains a metadata database that contains information about the
repositories stored on the cluster. Use the praefect metadata subcommand to inspect the metadata for troubleshooting.
You can retrieve a repository's metadata by either:
{{< tabs >}}
{{< tab title="Virtual storage and relative path" >}}
To retrieve a repository's metadata by its virtual storage and relative path:
In the upper-right corner, select Admin.
Select Overview > Projects and select the project.
Note the values of Storage name and Relative path for the project.
With these values, run the following command:
sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml metadata -virtual-storage <virtual-storage> -relative-path <relative-path>
{{< /tab >}}
{{< tab title="Praefect-assigned repository ID" >}}
[!note] A repository ID is not the same as a project ID.
To retrieve a repository's metadata by its Praefect-assigned repository ID:
Note the final component of the repository's replica path. For example, for @cluster/repositories/6f/96/54771 the repository ID is 54771.
With that value, run the following command:
sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml metadata -repository-id <repository-id>
{{< /tab >}}
{{< /tabs >}}
To retrieve the metadata for a repository with virtual storage default and relative path @hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git:
sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml metadata -virtual-storage default -relative-path @hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git
To retrieve the metadata for a repository with a Praefect-assigned repository ID of 1:
sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml metadata -repository-id 1
Either of these examples retrieve the following metadata for an example repository:
Repository ID: 54771
Virtual Storage: "default"
Relative Path: "@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"
Replica Path: "@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"
Primary: "gitaly-1"
Generation: 1
Replicas:
- Storage: "gitaly-1"
Assigned: true
Generation: 1, fully up to date
Healthy: true
Valid Primary: true
Verified At: 2021-04-01 10:04:20 +0000 UTC
- Storage: "gitaly-2"
Assigned: true
Generation: 0, behind by 1 changes
Healthy: true
Valid Primary: false
Verified At: unverified
- Storage: "gitaly-3"
Assigned: true
Generation: replica not yet created
Healthy: false
Valid Primary: false
Verified At: unverified
The metadata retrieved by praefect metadata includes the fields in the following tables.
| Field | Description |
|---|---|
Repository ID | Permanent unique ID assigned to the repository by Praefect. Different to the ID GitLab uses for repositories. |
Virtual Storage | Name of the virtual storage the repository is stored in. |
Relative Path | Repository's path in the virtual storage. |
Replica Path | Where on the Gitaly node's disk the repository's replicas are stored. |
Primary | Current primary of the repository. |
Generation | Used by Praefect to track repository changes. Each write in the repository increments the repository's generation. |
Replicas | A list of replicas that exist or are expected to exist. |
For each replica, the following metadata is available:
Replicas Field | Description |
|---|---|
Storage | Name of the Gitaly storage that contains the replica. |
Assigned | Indicates whether the replica is expected to exist in the storage. Can be false if a Gitaly node is removed from the cluster or if the storage contains an extra copy after the repository's replication factor was decreased. |
Generation | Latest confirmed generation of the replica. It indicates: |
The replica is fully up to date if the generation matches the repository's generation.
The replica is outdated if the replica's generation is less than the repository's generation.
replica not yet created if the replica does not yet exist at all on the storage. |
| Healthy | Indicates whether the Gitaly node that is hosting this replica is considered healthy by the consensus of Praefect nodes. |
| Valid Primary | Indicates whether the replica is fit to serve as the primary node. If the repository's primary is not a valid primary, a failover occurs on the next write to the repository if there is another replica that is a valid primary. A replica is a valid primary if:
It is stored on a healthy Gitaly node.
It is fully up to date.
It is not targeted by a pending deletion job from decreasing replication factor.
It is assigned. |
| Verified At | Indicates last successful verification of the replica by the verification worker. If the replica has not yet been verified, unverified is displayed in place of the last successful verification time. |
If the supplied value for -virtual-storage is incorrect, the command returns the following error:
get metadata: rpc error: code = NotFound desc = repository not found
The documented examples specify -virtual-storage default. Check the Praefect server setting praefect['configuration'][:virtual_storage] in /etc/gitlab/gitlab.rb.
Is some cases the Praefect database can get out of sync with the underlying Gitaly nodes. To check that
a given repository is fully synced on all nodes, run the gitlab:praefect:replicas Rake task on your Rails node.
This Rake task checksums the repository on all Gitaly nodes.
The Praefect dataloss command only checks the state of the repository in the Praefect database, and cannot
be relied to detect sync problems in this scenario.
dataloss command shows @failed-geo-sync repositories as out of sync@failed-geo-sync is a legacy path that was used on GitLab 16.1 and earlier by Geo when project synchronization failed and has been
deprecated.
On GitLab 16.2 and later, you can safely delete this path. The @failed-geo-sync directories are located under the repository path on the Gitaly nodes.
By default Praefect database tables are created automatically by gitlab-ctl reconfigure task.
However, the Praefect database tables are not created on initial reconfigure and can throw errors that relations do not exist if either:
gitlab-ctl reconfigure command isn't executed.For example:
ERROR: relation "node_status" does not exist at character 13
ERROR: relation "replication_queue_lock" does not exist at character 40
This error:
{"level":"error","msg":"Error updating node: pq: relation \"node_status\" does not exist","pid":210882,"praefectName":"gitlab1x4m:0.0.0.0:2305","time":"2021-04-01T19:26:19.473Z","virtual_storage":"praefect-cluster-1"}
To solve this, the database schema migration can be done using sql-migrate sub-command of
the praefect command:
$ sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate
praefect sql-migrate: OK (applied 21 migrations)
This indicates that the virtual storage name used in the
Praefect configuration does not match the storage name used in
gitaly['configuration'][:storage][<index>][:name] setting for GitLab.
Resolve this by matching the virtual storage names used in Praefect and GitLab configuration.
Praefect does not require a lot of CPU or memory, and can run on small virtual machines. Cloud services may place other limits on the resources that small VMs can use, such as disk IO and network traffic.
Praefect nodes generate a lot of network traffic. The following symptoms can be observed if their network bandwidth has been throttled by the cloud service:
Possible solutions:
gitlab-ctl reconfigure fails with a Praefect configuration errorIf gitlab-ctl reconfigure fails, you might see this error:
STDOUT: praefect: configuration error: error reading config file: toml: cannot store TOML string into a Go int
This error occurs when praefect['database_port'] or praefect['database_direct_port'] are configured as a string instead of an integer.
The following are some common replication errors with possible solutions.
Lock files are used to prevent multiple updates to the same ref. Sometimes lock files become stale, and replication fails with the error error: cannot lock ref.
To clear stale *.lock files, you can trigger OptimizeRepositoryRequest on the Rails console:
p = Project.find <Project ID>
client = Gitlab::GitalyClient::RepositoryService.new(p.repository)
client.optimize_repository
If triggering OptimizeRepositoryRequest does not work, inspect the files manually to confirm the creation date and decide if the *.lock file can be manually removed.
Any lock files created over 24 hours ago are safe to remove.
fsck errorsGitaly repositories with invalid objects can lead to replication failures with errors in Gitaly logs such as:
exit status 128, stderr: "fatal: git upload-pack: not our ref"."fatal: bad object 58....e0f... ssh://gitaly/internal.git did not send all necessary objects.As long one of the Gitaly nodes still has a healthy copy of the repository, these issues can be fixed by:
track-repository subcommand to re-track it.This will use the copy of the repository from the authoritative Gitaly node to overwrite the copies on all other Gitaly nodes. Be sure a recent backup of the repository has been made before running these commands.
Move the bad repository out of place:
run `mv <REPOSITORY_PATH> <REPOSITORY_PATH>.backup`
For example:
mv /var/opt/gitlab/git-data/repositories/@cluster/repositories/de/74/2335 /var/opt/gitlab/git-data/repositories/@cluster/repositories/de/74/2335.backup
Run the Praefect commands to trigger replication:
# Validate you have the correct repository.
sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage gitaly -relative-path '<relative_path>' -db-only
# Run again with '--apply' flag to remove repository from the Praefect tracking database
sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage gitaly -relative-path '<relative_path>' -db-only --apply
# Re-track the repository, overwriting the secondary nodes
sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml track-repository -virtual-storage gitaly -authoritative-storage '<healthy_gitaly>' -relative-path '<relative_path>' -replica-path '<replica_path>'-replicate-immediately
If the Praefect dataloss shows repositories partially unavailable, and accept-dataloss command fails to synchronize the repository with no error present on the logs, this could be due to a mismatch in Praefect database in the repository_id field of the storage_repositories table. To check for a mismatch:
Connect to the Praefect database.
Run the following query:
select * from storage_repositories where relative_path = '<relative-path>';
Replace <relative-path> with the repository path beginning with @hashed.
GitLab uses the Git alternates mechanism for deduplication. alternates is a text file that points to the objects directory on
a @pool repository to fetch objects. If this file points to an invalid path, replication can fail with one of the following the errors:
"error":"no alternates directory exists", "warning","msg":"alternates file does not point to valid git repository""error":"unexpected alternates content:remote: error: unable to normalize alternate object pathTo investigate the cause of this error:
Check if the project is part of a pool by using the Rails console:
project = Project.find_by_id(<project id>)
project.pool_repository
Check if the pool repository path exists on disk and that it matches the alternates file content.
Check if the path in the alternates file is reachable from the objects directory in the project.
After performing these checks, reach out to GitLab Support with the information collected.
When using Horizontal Pod Autoscaler (HPA) with Sidekiq pods, repository storage moves can fail silently due to pod scaling during job execution. If a repository storage move has failed because of this issue, failed projects can remain stuck in a read-only state.
To recover affected repositories: