• Steps
• Upgrade the bundled PostgreSQL to version 12
• Upgrade the bundled PostgreSQL chart
• Upgrade steps for 5.0 release
  • Troubleshooting 5.0 release upgrade process
• Upgrade steps for 4.0 release
  • Troubleshooting 4.0 release upgrade process
    • 4.8: Repository data appears to be lost upgrading Praefect

Upgrade Guide

Before upgrading your GitLab installation, you need to check the changelog corresponding to the specific release you want to upgrade to and look for any release notes that might pertain to the new GitLab chart version.

We also recommend that you take a backup first. Also note that you must provide all values using helm upgrade --set key=value syntax or -f values.yaml instead of using --reuse-values, because some of the current values might be deprecated.

You can retrieve your previous --set arguments cleanly, with helm get values <release name>. If you direct this into a file (helm get values <release name> > gitlab.yaml), you can safely pass this file via -f. Thus helm upgrade gitlab gitlab/gitlab -f gitlab.yaml. This safely replaces the behavior of --reuse-values

Mappings between chart versioning and GitLab versioning can be found here.

Steps

The following are the steps to upgrade GitLab to a newer version:

1. Check the change log for the specific version you would like to upgrade to
2. Go through deployment documentation step by step

3. Extract your previous --set arguments with

   helm get values gitlab > gitlab.yaml
   

4. Decide on all the values you need to set
5. If you were using the GitLab Operator, it is deprecated, and will be removed in the future.

6. Perform the upgrade, with all --set arguments extracted in step 4

   helm upgrade gitlab gitlab/gitlab \
     --version <new version> \
     -f gitlab.yaml \
     --set gitlab.migrations.enabled=true \
     --set ...
   

During a major database upgrade, we ask you to set gitlab.migrations.enabled set to false. Ensure that you explicitly set it back to true for future updates.

Upgrade the bundled PostgreSQL to version 12

Upgrading to PostgreSQL 12 for GitLab 14.x is required. PostgreSQL 12 is supported by GitLab 13.4 and later. PostgreSQL 12 brings significant performance improvements.

To upgrade the bundled PostgreSQL to version 12, the following steps are required:

1. Prepare the existing database.
2. Delete existing PostgreSQL data.
3. Update the postgresql.image.tag value to 12.4.0 and reinstall the chart to create a new PostgreSQL 12 database.
4. Restore the database.

Upgrade the bundled PostgreSQL chart

As part of the 5.0.0 release of this chart, we upgraded the bundled PostgreSQL version from 11.9.0 to 12.7.0. This is not a drop in replacement. Manual steps need to be performed to upgrade the database. The steps have been documented in the 5.0 upgrade steps.

As part of the 4.0.0 release of this chart, we upgraded the bundled PostgreSQL chart from 7.7.0 to 8.9.4. This is not a drop in replacement. Manual steps need to be performed to upgrade the database. The steps have been documented in the 4.0 upgrade steps.

Upgrade steps for 5.0 release

The 5.0.0 release requires manual steps in order to perform the upgrade. If you’re using the bundled PostgreSQL, the best way to perform this upgrade is to back up your old database, and restore into a new database instance.

If you are using an external PostgreSQL database, you should first upgrade the database to version 12 or greater. Then follow the normal upgrade steps.

If you are using the bundled PostgreSQL database, you should follow the bundled database upgrade steps.

Troubleshooting 5.0 release upgrade process

• If you see any failure during the upgrade, it may be useful to check the description of gitlab-upgrade-check pod for details:

  kubectl get pods -lrelease=RELEASE,app=gitlab
  kubectl describe pod <gitlab-upgrade-check-pod-full-name>
  

Upgrade steps for 4.0 release

The 4.0.0 release requires manual steps in order to perform the upgrade. If you’re using the bundled PostgreSQL, the best way to perform this upgrade is to back up your old database, and restore into a new database instance.

If you are using an external PostgreSQL database, you should first upgrade the database to version 11 or greater. Then follow the normal upgrade steps.

If you are using the bundled PostgreSQL database, you should follow the bundled database upgrade steps.

Troubleshooting 4.0 release upgrade process

• If you see any failure during the upgrade, it may be useful to check the description of gitlab-upgrade-check pod for details:

  kubectl get pods -lrelease=RELEASE,app=gitlab
  kubectl describe pod <gitlab-upgrade-check-pod-full-name>
  

4.8: Repository data appears to be lost upgrading Praefect

The Praefect chart is not yet considered suitable for production use.

If you have enabled Praefect before upgrading to version 4.8 of the chart (GitLab 13.8), note that the StatefulSet name for Gitaly will now include the virtual storage name.

In version 4.8 of the Praefect chart, the ability to specify multiple virtual storages was added, making it necessary to change the StatefulSet name.

Any existing Praefect-managed Gitaly StatefulSet names (and, therefore, their associated PersistentVolumeClaims) will change as well, leading to repository data appearing to be lost.

Prior to upgrading, ensure that:

• All your repositories are in sync across the Gitaly Cluster, and GitLab is not in use during the upgrade. To check whether the repositories are in sync, run the following command in one of your Praefect pods:

  /usr/local/bin/praefect -config /etc/gitaly/config.toml dataloss
  

• You have a complete and tested backup.

Repository data can be restored by following the managing persistent volumes documentation, which provides guidance on reconnecting existing PersistentVolumeClaims to previous PersistentVolumes.

A key step of the process is setting the old persistent volumes’ persistentVolumeReclaimPolicy to Retain. If this step is missed, actual data loss will likely occur.

After reviewing the documentation, there is a scripted summary of the procedure in a comment on one of a related issues.

Having reconnected the PersistentVolumes, it is likely that all your repositories will be set read-only by Praefect, as shown by running the following in a Praefect container:

praefect -config /etc/gitaly/config.toml dataloss

If all your Git repositories are in sync across the old persistent volumes, use the accept-dataloss procedure for each repository to fix the Gitaly Cluster in Praefect.

We have an issue open to verify that this is the best approach to fixing Praefect.