diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md index 96c6482e3db09db0b179642b927669fea1ca8797..bd8467f5437a750ef6ca154af6d1823b6a3cee2a 100644 --- a/doc/administration/geo/disaster_recovery/planned_failover.md +++ b/doc/administration/geo/disaster_recovery/planned_failover.md @@ -27,7 +27,7 @@ have a high degree of confidence in being able to perform them accurately. ## Not all data is automatically replicated -If you are using any GitLab features that Geo [doesn't support](../index.md#limitations), +If you are using any GitLab features that Geo [doesn't support](../replication/datatypes.md#limitations-on-replicationverification), you must make separate provisions to ensure that the **secondary** node has an up-to-date copy of any data associated with that feature. This may extend the required scheduled maintenance period significantly. @@ -40,8 +40,7 @@ final transfer inside the maintenance window) will then transfer only the Repository-centric strategies for using `rsync` effectively can be found in the [moving repositories](../../operations/moving_repositories.md) documentation; these strategies can -be adapted for use with any other file-based data, such as GitLab Pages (to -be found in `/var/opt/gitlab/gitlab-rails/shared/pages` if using Omnibus). +be adapted for use with any other file-based data, such as [GitLab Pages](../../pages/index.md#change-storage-path). ## Preflight checks diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md index 6cec13fde0221f2f76c6acbe7857d2cd52ed1edd..412b302ad261d3165b74e8c48b2198f2f5823bd3 100644 --- a/doc/administration/geo/index.md +++ b/doc/administration/geo/index.md @@ -181,6 +181,25 @@ When something is marked to be updated in the tracking database instance, asynch This new architecture allows GitLab to be resilient to connectivity issues between the nodes. It doesn't matter how long the **secondary** node is disconnected from the **primary** node as it will be able to replay all the events in the correct order and become synchronized with the **primary** node again. +## Limitations + +WARNING: +This list of limitations only reflects the latest version of GitLab. If you are using an older version, extra limitations may be in place. + +- Pushing directly to a **secondary** node redirects (for HTTP) or proxies (for SSH) the request to the **primary** node instead of [handling it directly](https://gitlab.com/gitlab-org/gitlab/-/issues/1381), except when using Git over HTTP with credentials embedded within the URI. For example, `https://user:password@secondary.tld`. +- The **primary** node has to be online for OAuth login to happen. Existing sessions and Git are not affected. Support for the **secondary** node to use an OAuth provider independent from the primary is [being planned](https://gitlab.com/gitlab-org/gitlab/-/issues/208465). +- The installation takes multiple manual steps that together can take about an hour depending on circumstances. We are working on improving this experience. See [Omnibus GitLab issue #2978](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/2978) for details. +- Real-time updates of issues/merge requests (for example, via long polling) doesn't work on the **secondary** node. +- [Selective synchronization](replication/configuration.md#selective-synchronization) applies only to files and repositories. Other datasets are replicated to the **secondary** node in full, making it inappropriate for use as an access control mechanism. +- Object pools for forked project deduplication work only on the **primary** node, and are duplicated on the **secondary** node. +- GitLab Runners cannot register with a **secondary** node. Support for this is [planned for the future](https://gitlab.com/gitlab-org/gitlab/-/issues/3294). +- Geo **secondary** nodes can not be configured to [use high-availability configurations of PostgreSQL](https://gitlab.com/groups/gitlab-org/-/epics/2536). +- [Selective synchronization](replication/configuration.md#selective-synchronization) only limits what repositories are replicated. The entire PostgreSQL data is still replicated. Selective synchronization is not built to accomodate compliance / export control use cases. + +### Limitations on replication/verification + +There is a complete list of all GitLab [data types](replication/datatypes.md) and [existing support for replication and verification](replication/datatypes.md#limitations-on-replicationverification). + ## Setup instructions For setup instructions, see [Setting up Geo](setup/index.md). @@ -275,25 +294,6 @@ For more information on removing a Geo node, see [Removing **secondary** Geo nod To find out how to disable Geo, see [Disabling Geo](replication/disable_geo.md). -## Limitations - -WARNING: -This list of limitations only reflects the latest version of GitLab. If you are using an older version, extra limitations may be in place. - -- Pushing directly to a **secondary** node redirects (for HTTP) or proxies (for SSH) the request to the **primary** node instead of [handling it directly](https://gitlab.com/gitlab-org/gitlab/-/issues/1381), except when using Git over HTTP with credentials embedded within the URI. For example, `https://user:password@secondary.tld`. -- The **primary** node has to be online for OAuth login to happen. Existing sessions and Git are not affected. Support for the **secondary** node to use an OAuth provider independent from the primary is [being planned](https://gitlab.com/gitlab-org/gitlab/-/issues/208465). -- The installation takes multiple manual steps that together can take about an hour depending on circumstances. We are working on improving this experience. See [Omnibus GitLab issue #2978](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/2978) for details. -- Real-time updates of issues/merge requests (for example, via long polling) doesn't work on the **secondary** node. -- [Selective synchronization](replication/configuration.md#selective-synchronization) applies only to files and repositories. Other datasets are replicated to the **secondary** node in full, making it inappropriate for use as an access control mechanism. -- Object pools for forked project deduplication work only on the **primary** node, and are duplicated on the **secondary** node. -- GitLab Runners cannot register with a **secondary** node. Support for this is [planned for the future](https://gitlab.com/gitlab-org/gitlab/-/issues/3294). -- Geo **secondary** nodes can not be configured to [use high-availability configurations of PostgreSQL](https://gitlab.com/groups/gitlab-org/-/epics/2536). -- [Selective synchronization](replication/configuration.md#selective-synchronization) only limits what repositories are replicated. The entire PostgreSQL data is still replicated. Selective synchronization is not built to accomodate compliance / export control use cases. - -### Limitations on replication/verification - -There is a complete list of all GitLab [data types](replication/datatypes.md) and [existing support for replication and verification](replication/datatypes.md#limitations-on-replicationverification). - ## Frequently Asked Questions For answers to common questions, see the [Geo FAQ](replication/faq.md). diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index 079a3713c73edaa35330d1dec887be9ec9149077..d0b00536e23c1de476f7daca96804b571c2356fa 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -853,6 +853,12 @@ To resolve this issue: the **primary** node using IPv4 in the `/etc/hosts` file. Alternatively, you should [enable IPv6 on the **primary** node](https://docs.gitlab.com/omnibus/settings/nginx.html#setting-the-nginx-listen-address-or-addresses). +### GitLab Pages return 404 errors after promoting + +This is due to [Pages data not being managed by Geo](datatypes.md#limitations-on-replicationverification). +Find advice to resolve those errors in the +[Pages administration documentation](../../../administration/pages/index.md#404-error-after-promoting-a-geo-secondary-to-a-primary-node). + ## Fixing client errors ### Authorization errors from LFS HTTP(s) client requests diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md index fd5642b2c4bc2e25ded846489cb07f90708995bb..a422efc0fcf68677a90ae18b9da31422b214a97f 100644 --- a/doc/administration/pages/index.md +++ b/doc/administration/pages/index.md @@ -1167,6 +1167,17 @@ date > /var/opt/gitlab/gitlab-rails/shared/pages/.update If you've customized the Pages storage path, adjust the command above to use your custom path. +### 404 error after promoting a Geo secondary to a primary node + +These are due to the Pages files not being among the +[supported data types](../geo/replication/datatypes.md#limitations-on-replicationverification). + +It is possible to copy the subfolders and files in the [Pages path](#change-storage-path) +to the new primary node to resolve this. +For example, you can adapt the `rsync` strategy from the +[moving repositories documenation](../operations/moving_repositories.md). +Alternatively, run the CI pipelines of those projects that contain a `pages` job again. + ### Failed to connect to the internal GitLab API If you have enabled [API-based configuration](#gitlab-api-based-configuration) and see the following error: diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md index da2e2e8dcc2cf969a40202dfe55a64975fd7e47a..50aa2c4309c56c9dae2edc1e0dd40ed8801543c4 100644 --- a/doc/user/project/pages/introduction.md +++ b/doc/user/project/pages/introduction.md @@ -302,6 +302,9 @@ A 404 can also be related to incorrect permissions. If [Pages Access Control](pa navigates to the Pages URL and receives a 404 response, it is possible that the user does not have permission to view the site. To fix this, verify that the user is a member of the project. +For Geo instances, 404 errors on Pages occur after promoting a secondary to a primary. +Find more details in the [Pages administration documentation](../../../administration/pages/index.md#404-error-after-promoting-a-geo-secondary-to-a-primary-node) + ### Cannot play media content on Safari Safari requires the web server to support the [Range request header](https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6)