Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/administration/geo/replication/faq.md')
-rw-r--r--doc/administration/geo/replication/faq.md10
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md
index 12b3b382bf7..bdf1771e8a8 100644
--- a/doc/administration/geo/replication/faq.md
+++ b/doc/administration/geo/replication/faq.md
@@ -1,5 +1,5 @@
---
-stage: Enablement
+stage: Systems
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
---
@@ -32,10 +32,10 @@ To ensure that problems with pipelines (for example, syncs failing too many time
the number of concurrent syncs falls below `repos_max_capacity` and there are no new projects waiting to be synced.
Geo also has a checksum feature which runs a SHA256 sum across all the Git references to the SHA values.
-If the refs don't match between the **primary** site and the **secondary** site, then the **secondary** site will mark that project as dirty and try to resync it.
+If the refs don't match between the **primary** site and the **secondary** site, then the **secondary** site marks that project as dirty and try to resync it.
So even if we have an outdated tracking database, the validation should activate and find discrepancies in the repository state and resync.
-## Can I use Geo in a disaster recovery situation?
+## Can you use Geo in a disaster recovery situation?
Yes, but there are limitations to what we replicate (see
[What data is replicated to a **secondary** site?](#what-data-is-replicated-to-a-secondary-site)).
@@ -46,7 +46,7 @@ Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
We currently replicate project repositories, LFS objects, generated
attachments and avatars, and the whole database. This means user accounts,
-issues, merge requests, groups, project data, and so on, will be available for
+issues, merge requests, groups, project data, and so on, are available for
query.
For more details, see the [supported Geo data types](datatypes.md).
@@ -69,6 +69,6 @@ That's totally fine. We use HTTP(s) to fetch repository changes from the **prima
Yes. See [Docker Registry for a **secondary** site](docker_registry.md).
-## Can I login to a secondary site?
+## Can you login 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.