diff options
Diffstat (limited to 'doc/administration/geo/replication/version_specific_updates.md')
-rw-r--r-- | doc/administration/geo/replication/version_specific_updates.md | 41 |
1 files changed, 28 insertions, 13 deletions
diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md index d3a132a6666..95833a290dd 100644 --- a/doc/administration/geo/replication/version_specific_updates.md +++ b/doc/administration/geo/replication/version_specific_updates.md @@ -8,7 +8,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w Review this page for update instructions for your version. These steps accompany the [general steps](updating_the_geo_sites.md#general-update-steps) -for updating Geo nodes. +for updating Geo sites. + +## Updating to 14.2 through 14.7 + +There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467) +that affects Geo when the GitLab-managed object storage replication is used, causing blob object types to fail synchronization. + +Since GitLab 14.2, verification failures result in synchronization failures and cause +a resynchronization of these objects. + +As verification is not yet implemented for files stored in object storage (see +[issue 13845](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) for more details), this +results in a loop that consistently fails for all objects stored in object storage. + +For information on how to fix this, see +[Troubleshooting - Failed syncs with GitLab-managed object storage replication](troubleshooting.md#failed-syncs-with-gitlab-managed-object-storage-replication). ## Updating to 14.4 @@ -18,7 +33,7 @@ There is [an issue in GitLab 14.4.0 through 14.4.2](../../../update/index.md#144 ### Multi-arch images -We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture (for example `amd64`) would be replicated to the secondary node. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync. +We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture (for example `amd64`) would be replicated to the secondary site. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync. You can check if you are affected by running: @@ -26,12 +41,12 @@ You can check if you are affected by running: docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType' ``` -Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary node. +Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary site. If the output matches `application/vnd.docker.distribution.manifest.list.v2+json` (there can be a `mediaType` entry at several levels, we only care about the top level entry), then you don't need to do anything. -Otherwise, on all your **secondary** nodes, in a [Rails console](../../operations/rails_console.md), run the following: +Otherwise, for each **secondary** site, on a Rails application node, open a [Rails console](../../operations/rails_console.md), and run the following: ```ruby list_type = 'application/vnd.docker.distribution.manifest.list.v2+json' @@ -63,7 +78,7 @@ We found an issue where [Primary sites can not be removed from the UI](https://g This bug only exists in the UI and does not block the removal of Primary sites using any other method. -If you are running an affected version and need to remove your Primary site, you can manually remove the Primary site by using the [Geo Nodes API](../../../api/geo_nodes.md#delete-a-geo-node). +If you are running an affected version and need to remove your Primary site, you can manually remove the Primary site by using the [Geo Sites API](../../../api/geo_nodes.md#delete-a-geo-node). ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode @@ -71,9 +86,9 @@ GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab ## Updating to GitLab 13.12 -### Secondary nodes re-download all LFS files upon update +### Secondary sites re-download all LFS files upon update -We found an issue where [secondary nodes re-download all LFS files](https://gitlab.com/gitlab-org/gitlab/-/issues/334550) upon update. This bug: +We found an issue where [secondary sites re-download all LFS files](https://gitlab.com/gitlab-org/gitlab/-/issues/334550) upon update. This bug: - Only applies to Geo secondary sites that have replicated LFS objects. - Is _not_ a data loss risk. @@ -172,7 +187,7 @@ In GitLab 13.3, Geo removed the PostgreSQL [Foreign Data Wrapper](https://www.po dependency for the tracking database. The FDW server, user, and the extension is removed during the upgrade -process on each secondary node. The GitLab settings related to the FDW in the +process on each secondary site. The GitLab settings related to the FDW in the `/etc/gitlab/gitlab.rb` have been deprecated and can be safely removed. There are some scenarios like using an external PostgreSQL instance for the @@ -185,9 +200,9 @@ DROP EXTENSION IF EXISTS postgres_fdw; ``` WARNING: -In GitLab 13.3, promoting a secondary node to a primary while the secondary is +In GitLab 13.3, promoting a secondary site to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the -node is paused, be sure to resume before promoting. To avoid this issue, +site is paused, be sure to resume before promoting. To avoid this issue, upgrade to GitLab 13.4 or later. WARNING: @@ -198,9 +213,9 @@ contain a workaround if you run into errors during the failover. ## Updating to GitLab 13.2 -In GitLab 13.2, promoting a secondary node to a primary while the secondary is +In GitLab 13.2, promoting a secondary site to a primary while the secondary is paused fails. Do not pause replication before promoting a secondary. If the -node is paused, be sure to resume before promoting. To avoid this issue, +site is paused, be sure to resume before promoting. To avoid this issue, upgrade to GitLab 13.4 or later. ## Updating to GitLab 13.0 @@ -375,5 +390,5 @@ For the recommended procedure, see the WARNING: This version is affected by a [bug that results in new LFS objects not being -replicated to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696). +replicated to Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/32696). The issue is fixed in GitLab 12.1. Be sure to upgrade to GitLab 12.1 or later. |