2021-11-11 11:23:49 +05:30
---
2022-07-23 23:45:48 +05:30
stage: Systems
2021-11-11 11:23:49 +05:30
group: Geo
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2021-11-11 11:23:49 +05:30
type: howto
---
2022-07-23 23:45:48 +05:30
# Upgrading the Geo sites **(PREMIUM SELF)**
2021-11-11 11:23:49 +05:30
WARNING:
Read these sections carefully before updating your Geo sites. Not following
2022-07-23 23:45:48 +05:30
version-specific upgrade steps may result in unexpected downtime. If you have
2021-11-11 11:23:49 +05:30
any specific questions, [contact Support ](https://about.gitlab.com/support/#contact-support ).
2022-07-23 23:45:48 +05:30
Upgrading Geo sites involves performing:
2021-11-11 11:23:49 +05:30
2022-07-23 23:45:48 +05:30
1. [Version-specific upgrade steps ](version_specific_upgrades.md ), depending on the
version being upgraded to or from.
1. [General upgrade steps ](#general-upgrade-steps ), for all upgrades.
2021-11-11 11:23:49 +05:30
2022-07-23 23:45:48 +05:30
## General upgrade steps
2021-11-11 11:23:49 +05:30
NOTE:
2022-07-23 23:45:48 +05:30
These general upgrade steps are not intended for multi-site deployments,
and cause downtime. If you want to avoid downtime, consider using
2021-11-11 11:23:49 +05:30
[zero downtime upgrades ](../../../update/zero_downtime.md#multi-node--ha-deployment-with-geo ).
2022-07-23 23:45:48 +05:30
To upgrade the Geo sites when a new GitLab version is released, upgrade **primary**
2021-11-11 11:23:49 +05:30
and all **secondary** sites:
2022-08-27 11:52:29 +05:30
1. Optional. [Pause replication on each **secondary** site ](../index.md#pausing-and-resuming-replication )
to protect the disaster recovery (DR) capability of the **secondary** sites.
2021-11-11 11:23:49 +05:30
1. SSH into each node of the **primary** site.
1. [Upgrade GitLab on the **primary** site ](../../../update/package/index.md#upgrade-using-the-official-repositories ).
2022-08-27 11:52:29 +05:30
1. Perform testing on the **primary** site, particularly if you paused replication in step 1 to protect DR. [There are some suggestions for post-upgrade testing ](../../../update/plan_your_upgrade.md#pre-upgrade-and-post-upgrade-checks ) in the upgrade documentation.
2021-11-11 11:23:49 +05:30
1. SSH into each node of **secondary** sites.
1. [Upgrade GitLab on each **secondary** site ](../../../update/package/index.md#upgrade-using-the-official-repositories ).
2022-08-27 11:52:29 +05:30
1. If you paused replication in step 1, [resume replication on each **secondary** ](../index.md#pausing-and-resuming-replication ).
Then, restart Puma and Sidekiq on each **secondary** site. This is to ensure they
are initialized against the newer database schema that is now replicated from
the previously upgraded **primary** site.
```shell
sudo gitlab-ctl restart sidekiq
sudo gitlab-ctl restart puma
```
2022-07-23 23:45:48 +05:30
1. [Test ](#check-status-after-upgrading ) **primary** and **secondary** sites, and check version in each.
2021-11-11 11:23:49 +05:30
2022-07-23 23:45:48 +05:30
### Check status after upgrading
2021-11-11 11:23:49 +05:30
2022-07-23 23:45:48 +05:30
Now that the upgrade process is complete, you may want to check whether
2021-11-11 11:23:49 +05:30
everything is working correctly:
1. Run the Geo Rake task on an application node for the primary and secondary sites. Everything should be green:
```shell
sudo gitlab-rake gitlab:geo:check
```
1. Check the **primary** site's Geo dashboard for any errors.
1. Test the data replication by pushing code to the **primary** site and see if it
is received by **secondary** sites.
If you encounter any issues, see the [Geo troubleshooting guide ](troubleshooting.md ).
