summaryrefslogtreecommitdiff
path: root/doc/administration/geo/replication/configuration.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/administration/geo/replication/configuration.md')
-rw-r--r--doc/administration/geo/replication/configuration.md35
1 files changed, 14 insertions, 21 deletions
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 8c818bcfbe2..43a422c4bc3 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -229,19 +229,10 @@ replicating missing data from the **primary** node in a process known as **backf
Meanwhile, the **primary** node will start to notify each **secondary** node of any changes, so
that the **secondary** node can act on those notifications immediately.
-Make sure the **secondary** node is running and accessible.
-You can login to the **secondary** node with the same credentials as used for the **primary** node.
+Be sure the _secondary_ node is running and accessible. You can sign in to the
+_secondary_ node with the same credentials as were used with the _primary_ node.
-### Step 4. Enabling Hashed Storage
-
-Using Hashed Storage significantly improves Geo replication. Project and group
-renames no longer require synchronization between nodes.
-
-1. Visit the **primary** node's **Admin Area > Settings > Repository**
- (`/admin/application_settings/repository`) in your browser.
-1. In the **Repository storage** section, check **Use hashed storage paths for newly created and renamed projects**.
-
-### Step 5. (Optional) Configuring the **secondary** node to trust the **primary** node
+### Step 4. (Optional) Configuring the **secondary** node to trust the **primary** node
You can safely skip this step if your **primary** node uses a CA-issued HTTPS certificate.
@@ -251,21 +242,23 @@ certificate from the **primary** node and follow
[these instructions](https://docs.gitlab.com/omnibus/settings/ssl.html)
on the **secondary** node.
-### Step 6. Enable Git access over HTTP/HTTPS
+### Step 5. Enable Git access over HTTP/HTTPS
Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
-method to be enabled. Navigate to **Admin Area > Settings**
-(`/admin/application_settings/general`) on the **primary** node, and set
-`Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
+method to be enabled. This is enabled by default, but if converting an existing node to Geo it should be checked:
+
+1. Navigate to **Admin Area > Settings** (`/admin/application_settings/general`) on the **primary** node.
+1. Expand "Visibility and access controls".
+1. Ensure "Enabled Git access protocols" is set to either "Both SSH and HTTP(S)" or "Only HTTP(S)".
-### Step 7. Verify proper functioning of the **secondary** node
+### Step 6. Verify proper functioning of the **secondary** node
Your **secondary** node is now configured!
-You can login to the **secondary** node with the same credentials you used for the
-**primary** node. Visit the **secondary** node's **Admin Area > Geo**
-(`/admin/geo/nodes`) in your browser to check if it's correctly identified as a
-**secondary** Geo node and if Geo is enabled.
+You can sign in to the _secondary_ node with the same credentials you used with
+the _primary_ node. Visit the _secondary_ node's **Admin Area > Geo**
+(`/admin/geo/nodes`) in your browser to determine if it's correctly identified
+as a _secondary_ Geo node, and if Geo is enabled.
The initial replication, or 'backfill', will probably still be in progress. You
can monitor the synchronization process on each Geo node from the **primary**