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
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
type:howto
---
# Disaster Recovery (Geo) **(PREMIUM SELF)**
...
...
@@ -503,7 +502,7 @@ secondary domain, like changing Git remotes and API URLs.
This command uses the changed `external_url` configuration defined
in `/etc/gitlab/gitlab.rb`.
1. For GitLab 11.11 through 12.7 only, you may need to update the **primary**
1. For GitLab 12.0 through 12.7, you may need to update the **primary**
node's name in the database. This bug has been fixed in GitLab 12.8.
To determine if you need to do this, search for the
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
@@ -54,7 +53,7 @@ For more details, see the [supported Geo data types](datatypes.md).
## Can I `git push` to a **secondary** site?
Yes! Pushing directly to a **secondary** site (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in GitLab 11.3.
Pushing directly to a **secondary** site (for both HTTP and SSH, including Git LFS) is supported.
## How long does it take to have a commit replicated to a **secondary** site?
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
type:howto
---
# Geo validation tests **(PREMIUM SELF)**
...
...
@@ -175,7 +174,7 @@ The following are PostgreSQL upgrade validation tests we performed.
[Test and validate PostgreSQL 10.0 upgrade for Geo](https://gitlab.com/gitlab-org/gitlab/-/issues/12092):
- Description: With the 12.0 release, GitLab required an upgrade to PostgreSQL 10.0. We tested
various upgrade scenarios from GitLab 11.11.5 through to GitLab 12.1.8.
various upgrade scenarios up to GitLab 12.1.8.
- Outcome: Multiple issues were found when upgrading and addressed in follow-up issues.
- Follow up issues:
-[`gitlab-ctl` reconfigure fails on Redis node in multi-node Geo setup](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4706).
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
type:howto
---
# Troubleshooting Geo **(PREMIUM SELF)**
...
...
@@ -288,9 +287,8 @@ errors (indicated by `Database replication working? ... no` in the
### Message: `ERROR: replication slots can only be used if max_replication_slots > 0`?
This means that the `max_replication_slots` PostgreSQL variable needs to
be set on the **primary** database. In GitLab 9.4, we have made this setting
default to 1. You may need to increase this value if you have more
**secondary** nodes.
be set on the **primary** database. This setting defaults to 1. You may need to
increase this value if you have more **secondary** nodes.
Be sure to restart PostgreSQL for this to take effect. See the
[PostgreSQL replication setup](../setup/database.md#postgresql-replication) guide for more details.
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
type:howto
---
<!-- Please update EE::GitLab::GeoGitAccess::GEO_SERVER_DOCS_URL if this file is moved) -->
...
...
@@ -11,7 +10,8 @@ type: howto
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.
You can push directly to a **secondary** site (for both HTTP, SSH including Git LFS), and the request will be proxied to the primary site instead ([introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in GitLab 11.3).
You can push directly to a **secondary** site (for both HTTP, SSH including
Git LFS), and the request will be proxied to the primary site instead.
Example of the output you will see when pushing to a **secondary** site:
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
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
type:howto
---
# Geo sites Admin Area **(PREMIUM SELF)**
...
...
@@ -50,8 +49,8 @@ download them all at once; so, GitLab places an upper limit on the concurrency o
these operations.
How long the backfill takes is dependent on the maximum concurrency, but higher
values place more strain on the **primary** site. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3107),
the limits are configurable. If your **primary** site has lots of surplus capacity,
values place more strain on the **primary** site. The limits are configurable.
If your **primary** site has lots of surplus capacity,
you can increase the values to complete backfill in a shorter time. If it's
under heavy load and backfill reduces its availability for normal requests,
you can decrease them.
...
...
@@ -85,7 +84,7 @@ to the internal URL instead of the external one.
## Multiple secondary sites behind a load balancer
In GitLab 11.11, **secondary** sites can use identical external URLs if
**Secondary** sites can use identical external URLs if
a unique `name` is set for each Geo site. The `gitlab.rb` setting
