info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Multi-node upgrades with downtime **(FREE SELF)**
NOTE:
This process is a work in progress. You're welcome to provide feedback by either raising a ticket to support,
or [commenting on this issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6244).
While you can upgrade a multi-node GitLab deployment [with zero downtime](zero_downtime.md),
there are a number of constraints. In particular, you can upgrade to only one minor release
at a time, for example, from 14.6 to 14.7, then to 14.8, etc.
If you want to upgrade to more than one minor release at a time (for example, from 14.6 to 14.9),
you need to take your GitLab instance offline, which implies downtime.
Before starting this process, verify the
[version specific upgrading instructions](index.md#version-specific-upgrading-instructions)
relevant to your [upgrade path](index.md#upgrade-paths).
For a single node installation, you only need to [uprgade the GitLab package](package/index.md).
The process for upgrading a number of components of a multi-node GitLab
installation is the same as for zero downtime upgrades.
The differences relate to the servers running Rails (Puma/Sidekiq) and
the order of events.
At a high level, the process is:
1. Shut down the GitLab application.
1. Upgrade your Consul servers.
1. Upgrade the other back-end components:
- Gitaly, Rails PostgreSQL, Redis, PgBouncer: these can be upgraded in any order.
- If you use PostgreSQL or Redis from your cloud platform and upgrades are required,
substitute the instructions for Omnibus GitLab with your cloud provider's instructions.
1. Upgrade the GitLab application (Sidekiq, Puma) and start the application up.
If you are a Community Edition user, replace `gitlab-ee` with
`gitlab-ce` in the following commands.
## Stop writes to the database
Shut down Puma and Sidekiq on all servers running these processes:
```shell
sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma
```
## Upgrade the Consul nodes
[Consult the Consul documentation for the complete instructions](../administration/consul.md#upgrade-the-consul-nodes).
In summary:
1. Check the Consul nodes are all healthy.
1. Upgrade the GitLab package on all your Consul servers:
1. The upgrade process does not restart PostgreSQL when the binaries are upgraded.
Restart to load the new version:
```shell
sudo gitlab-ctl restart
```
## Upgrade the Patroni node
Patroni is used to achiece high availabilty with PostgreSQL.
If a PostgreSQL major version upgrade is required,
[follow the major version process](../administration/postgresql/replication_and_failover.md#upgrading-postgresql-major-version-in-a-patroni-cluster).
The upgrade process for all other versions is performed on all replicas first.
After they're upgraded, a cluster failover occurs from the leader to one of the upgraded
replicas. This ensures that only one failover is needed, and once complete the new
leader will be upgraded.
Follow the following process:
1. Identify the leader and replica nodes, and [verify that the cluster is healthy](../administration/postgresql/replication_and_failover.md#check-replication-status).
Run on a database node:
```shell
sudo gitlab-ctl patroni members
```
1. Upgrade the GitLab package on one of the replica nodes: