diff --git a/doc/administration/geo/replication/container_registry.md b/doc/administration/geo/replication/container_registry.md index 1eacca32902d8542af422ba5e425eafbcc5b0bff..107260ce2f46071ee1715606a92961bd465efa04 100644 --- a/doc/administration/geo/replication/container_registry.md +++ b/doc/administration/geo/replication/container_registry.md @@ -11,7 +11,7 @@ You can set up a container registry on your **secondary** Geo site that mirrors NOTE: The container registry replication is used only for disaster recovery purposes. We do not recommend pulling the container registry data from the secondary. For a feature proposal to implement it in the -future, see [Geo: Accelerate container images by serving read request from secondary site](https://gitlab.com/gitlab-org/gitlab/-/issues/365864) for details. +future, see [Geo: Accelerate container images by serving read request from secondary site](https://gitlab.com/gitlab-org/gitlab/-/issues/365864) for details. You or your GitLab representative are encouraged to upvote this feature to register your interest. ## Supported container registries diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md index f29d7967feb91baa153d1ad1c15b34e45f944096..c5ac25ba1523cd6e9bfe14bf2896a2b4a6b082f8 100644 --- a/doc/administration/geo/replication/faq.md +++ b/doc/administration/geo/replication/faq.md @@ -44,12 +44,12 @@ Read the documentation for [Disaster Recovery](../disaster_recovery/index.md). ## What data is replicated to a **secondary** site? -We currently replicate project repositories, LFS objects, generated -attachments and avatars, and the whole database. This means information such as user accounts, +We currently replicate the whole rails database, project repositories, LFS objects, generated +attachments, avatars and more. This means information such as user accounts, issues, merge requests, groups, and project data are available for query. -For more details, see the [supported Geo data types](datatypes.md). +For a comprehensive list of data replicated by Geo, see the [supported Geo data types page](datatypes.md). ## Can I `git push` to a **secondary** site? @@ -65,10 +65,26 @@ connectivity between your sites, and your hardware. That's totally fine. We use HTTP(s) to fetch repository changes from the **primary** site to all **secondary** sites. -## Is this possible to set up a container registry for a **secondary** site that mirrors the one on the **primary** site? +## Is it possible to set up a container registry for a **secondary** site that mirrors the one on the **primary** site? -Yes. See [container registry for a **secondary** site](container_registry.md). +Yes, however, we only support this for Disaster Recovery scenarios. See [container registry for a **secondary** site](container_registry.md). ## Can you sign in to a secondary site? Yes, but secondary sites receive all authentication data (like user accounts and logins) from the primary instance. This means you are re-directed to the primary for authentication and then routed back. + +## Do all Geo sites need to be the same as the primary? + +No, Geo sites can be based on different reference architectures. For example, you can have the primary site based on a 3K reference architecture, one secondary site based 3K reference architecture, and another one based on a 1K reference architecture. + +## Does Geo replicate archived projects? + +Yes, provided they are not excluded through [selective sync](../replication/configuration.md#selective-synchronization). + +## Does Geo replicate personal projects? + +Yes, provided they are not excluded through [selective sync](../replication/configuration.md#selective-synchronization). + +## Are delayed deletion projects replicated to secondary sites? + +Yes, projects scheduled for deletion by [delayed deletion](../../settings/visibility_and_access_controls.md#delayed-project-deletion), but are yet to be permanently deleted, are replicated to secondary sites. diff --git a/doc/administration/geo/replication/usage.md b/doc/administration/geo/replication/usage.md index 0594709b23dda7212e7b6caa7c72f8eda7aab988..d05fb75af1111534ddebddee245022e089cf0fdc 100644 --- a/doc/administration/geo/replication/usage.md +++ b/doc/administration/geo/replication/usage.md @@ -10,6 +10,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w After you set up the [database replication and configure the Geo nodes](../index.md#setup-instructions), use your closest GitLab site as you would do with the primary one. +## Git operations + You can push directly to a **secondary** site (for both HTTP, SSH including Git LFS), and the request is proxied to the primary site instead. @@ -34,6 +36,12 @@ for Unix-like operating systems or `_netrc` for Windows. In that case, the crede are stored as a plain text. If you're looking for a more secure way to store credentials, you can use [Git Credential Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage). +## Web user interface + +The web user interface on the **secondary** site is read/write. As a user, all actions permitted on the **primary** site can be performed on the **secondary** site without limitations. + +Web interface access requests on the **secondary** sites are automatically and transparently proxied to the **primary** site. + ## Fetch Go modules from Geo secondary sites Go modules can be pulled from secondary sites, with a number of limitations: