Add latest changes from gitlab-org/gitlab@master

5 files changed, 40 insertions, 10 deletions

diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 811ac92de27..83a52bb6107 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -124,7 +124,7 @@ The following are required to run Geo:
     across Geo sites to avoid silent corruption of database indexes.
 - Git 2.9 or later
 - Git-lfs 2.4.2 or later on the user side when using LFS
-- All sites must run the same GitLab version.
+- All sites must run the exact same GitLab version. The [major, minor, and patch versions](../../policy/maintenance.md#versioning) must all match.
 - All sites must define the same [repository storages](../repository_storage_paths.md).
 
 Additionally, check the GitLab [minimum requirements](../../install/requirements.md),
diff --git a/doc/administration/geo/replication/container_registry.md b/doc/administration/geo/replication/container_registry.md
index 1eacca32902..107260ce2f4 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 f29d7967feb..c5ac25ba152 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 0594709b23d..d05fb75af11 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:
diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index 2d0e9e45197..a17c09c85e8 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -17,9 +17,10 @@ to [avoid version mismatches](../index.md#requirements-for-running-geo)
 in case a Geo site has to be rebuilt.
 
 NOTE:
-We strongly recommend running instances installed using the Linux package as they are actively
-developed and tested. We aim to be compatible with most external
-(not managed by Omnibus) databases but we do not guarantee compatibility.
+If you’re using GitLab Geo, we strongly recommend running instances installed by using the Linux package or using
+[validated cloud-managed instances](../../reference_architectures/index.md#recommended-cloud-providers-and-services),
+as we actively develop and test based on those.
+We cannot guarantee compatibility with other external databases. 
 
 ## **Primary** site
 
@@ -81,6 +82,11 @@ cloud providers:
 
 When your read-only replica is set up, you can skip to [configure your secondary site](#configure-secondary-site-to-use-the-external-read-replica)
 
+WARNING:
+The use of logical replication methods such as [AWS Database Migration Service](https://aws.amazon.com/dms/) 
+or [Google Cloud Database Migration Service](https://cloud.google.com/database-migration) to, for instance, 
+replicate from an on-premise primary database to an RDS secondary are not supported.  
+
 #### Manually configure the primary database for replication
 
 The [`geo_primary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)