debian-mirror-gitlab/doc/administration/geo/replication/upgrading_the_geo_sites.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

66 lines
3 KiB
Markdown
Raw Normal View History

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
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
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).