Move geo docs to administration/geo/replication

doc/administration/geo/replication/configuration.md

+# Geo configuration
+
+>**Note:**
+This is the documentation for the Omnibus GitLab packages. For installations
+from source, follow the [**Geo nodes configuration for installations
+from source**](configuration_source.md) guide.
+
+## Configuring a new secondary node
+
+>**Note:**
+This is the final step in setting up a secondary Geo node. Stages of the
+setup process must be completed in the documented order.
+Before attempting the steps in this stage, [complete all prior stages](README.md#using-omnibus-gitlab).
+
+The basic steps of configuring a secondary node are to replicate required
+configurations between the primary and the secondaries; to configure a tracking
+database on each secondary; and to start GitLab on the secondary node.
+
+You are encouraged to first read through all the steps before executing them
+in your testing/production environment.
+
+>**Notes:**
+- **Do not** setup any custom authentication in the secondary nodes, this will be
+  handled by the primary node.
+- **Do not** add anything in the secondaries Geo nodes admin area
+  (**Admin Area ➔ Geo Nodes**). This is handled solely by the primary node.
+
+### Step 1. Manually replicate secret GitLab values
+
+GitLab stores a number of secret values in the `/etc/gitlab/gitlab-secrets.json`
+file which *must* match between the primary and secondary nodes. Until there is
+a means of automatically replicating these between nodes (see
+[issue #3789](https://gitlab.com/gitlab-org/gitlab-ee/issues/3789)), they must
+be manually replicated to the secondary.
+
+1. SSH into the **primary** node, and execute the command below:
+
+    ```bash
+    sudo cat /etc/gitlab/gitlab-secrets.json
+    ```
+
+    This will display the secrets that need to be replicated, in JSON format.
+
+1. SSH into the **secondary** node and login as the `root` user:
+
+    ```
+    sudo -i
+    ```
+
+1. Make a backup of any existing secrets:
+
+    ```bash
+    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
+    ```
+
+1. Copy `/etc/gitlab/gitlab-secrets.json` from the primary to the secondary, or
+   copy-and-paste the file contents between nodes:
+
+    ```bash
+    sudo editor /etc/gitlab/gitlab-secrets.json
+
+    # paste the output of the `cat` command you ran on the primary
+    # save and exit
+    ```
+
+1. Ensure the file permissions are correct:
+
+    ```bash
+    chown root:root /etc/gitlab/gitlab-secrets.json
+    chmod 0600 /etc/gitlab/gitlab-secrets.json
+    ```
+
+1. Reconfigure the secondary node for the change to take effect:
+
+    ```
+    gitlab-ctl reconfigure
+    ```
+
+Once reconfigured, the secondary will automatically start
+replicating missing data from the primary in a process known as backfill.
+Meanwhile, the primary node will start to notify the secondary of any changes, so
+that the secondary can act on those notifications immediately.
+
+Make sure the secondary instance is
+running and accessible. You can login to the secondary node
+with the same credentials as used in the primary.
+
+### Step 2. Manually replicate primary SSH host keys
+
+GitLab integrates with the system-installed SSH daemon, designating a user
+(typically named git) through which all access requests are handled.
+
+In a [Disaster Recovery](../disaster_recovery/index.md) situation, GitLab system
+administrators will promote a secondary Geo replica to a primary and they can
+update the DNS records for the primary domain to point to the secondary to prevent
+the need to update all references to the primary domain to the secondary domain,
+like changing Git remotes and API URLs.
+
+This will cause all SSH requests to the newly promoted primary node from
+failing due to SSH host key mismatch. To prevent this, the primary SSH host
+keys must be manually replicated to the secondary node.
+
+1. SSH into the **secondary** node and login as the `root` user:
+
+    ```
+    sudo -i
+    ```
+
+1. Make a backup of any existing SSH host keys:
+
+    ```bash
+    find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
+    ```
+
+1. SSH into the **primary** node, and execute the command below:
+
+    ```bash
+    sudo find /etc/ssh -iname ssh_host_* -not -iname '*.pub'
+    ```
+
+1. For each file in that list replace the file from the primary node to
+   the **same** location on your **secondary** node.
+
+1. On your **secondary** node, ensure the file permissions are correct:
+
+    ```bash
+    chown root:root /etc/ssh/ssh_host_*
+    chmod 0600 /etc/ssh/ssh_host_*
+    ```
+
+1. Regenerate the public keys from the private keys:
+
+    ```bash
+    find /etc/ssh -iname ssh_host_* -not -iname '*.backup*' -exec sh -c 'ssh-keygen -y -f "{}" > "{}.pub"' \;
+    ```
+
+1. Restart sshd:
+
+    ```bash
+    service ssh restart
+    ```
+
+### Step 3. (Optional) Enabling hashed storage (from GitLab 10.0)
+
+>**Warning**
+Hashed storage is in **Beta**. It is not considered production-ready. See
+[Hashed Storage](../repository_storage_types.md) for more detail,
+and for the latest updates, check
+[infrastructure issue #2821](https://gitlab.com/gitlab-com/infrastructure/issues/2821).
+
+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**
+   (`/admin/application_settings`) in your browser
+1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
+
+    ![](img/hashed-storage.png)
+
+### Step 4. (Optional) Configuring the secondary to trust the primary
+
+You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
+
+If your primary is using a self-signed certificate for *HTTPS* support, you will
+need to add that certificate to the secondary's trust store. Retrieve the
+certificate from the primary and follow
+[these instructions](https://docs.gitlab.com/omnibus/settings/ssl.html)
+on the secondary.
+
+### 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`) on the primary node, and set
+`Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
+
+### Step 6. Verify proper functioning of the secondary node
+
+Congratulations! Your secondary geo node is now configured!
+
+You can login to the secondary node with the same credentials you used on the
+primary. Visit the secondary node's **Admin Area ➔ Geo Nodes**
+(`/admin/geo_nodes`) in your browser to check 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
+node's Geo Nodes dashboard in your browser.
+
+![Geo dashboard](img/geo-node-dashboard.png)
+
+If your installation isn't working properly, check the
+[troubleshooting document](troubleshooting.md).
+
+The two most obvious issues that can become apparent in the dashboard are:
+
+1. Database replication not working well
+1. Instance to instance notification not working. In that case, it can be
+   something of the following:
+     - You are using a custom certificate or custom CA (see the
+       [troubleshooting document](troubleshooting.md))
+     - The instance is firewalled (check your firewall rules)
+
+Please note that disabling a secondary node will stop the sync process.
+
+Please note that if `git_data_dirs` is customized on the primary for multiple
+repository shards you must duplicate the same configuration on the secondary.
+
+Point your users to the ["Using a Geo Server" guide](using_a_geo_server.md).
+
+Currently, this is what is synced:
+
+* Git repositories
+* Wikis
+* LFS objects
+* Issues, merge requests, snippets, and comment attachments
+* Users, groups, and project avatars
+
+## Selective synchronization
+
+Geo supports selective synchronization, which allows admins to choose
+which projects should be synchronized by secondary nodes.
+
+It is important to note that selective synchronization does not:
+
+1. Restrict permissions from secondary nodes.
+1. Hide project metadata from secondary nodes.
+  * Since Geo currently relies on PostgreSQL replication, all project metadata
+    gets replicated to secondary nodes, but repositories that have not been
+    selected will be empty.
+1. Reduce the number of events generated for the Geo event log
+  * The primary generates events as long as any secondaries are present.
+    Selective synchronization restrictions are implemented on the secondaries,
+    not the primary.
+
+A subset of projects can be chosen, either by group or by storage shard. The
+former is ideal for replicating data belonging to a subset of users, while the
+latter is more suited to progressively rolling out Geo to a large GitLab
+instance.
+
+## Upgrading Geo
+
+See the [updating the Geo nodes document](updating_the_geo_nodes.md).
+
+## Troubleshooting
+
+See the [troubleshooting document](troubleshooting.md).

doc/administration/geo/replication/configuration_source.md

+# Geo configuration
+
+>**Note:**
+This is the documentation for installations from source. For installations
+using the Omnibus GitLab packages, follow the
+[**Omnibus Geo nodes configuration**](configuration.md) guide.
+
+## Configuring a new secondary node
+
+>**Note:**
+This is the final step in setting up a secondary Geo node. Stages of the setup
+process must be completed in the documented order. Before attempting the steps
+in this stage, [complete all prior stages](README.md#using-gitlab-installed-from-source).
+
+The basic steps of configuring a secondary node are to replicate required
+configurations between the primary and the secondaries; to configure a tracking
+database on each secondary; and to start GitLab on the secondary node.
+
+You are encouraged to first read through all the steps before executing them
+in your testing/production environment.
+
+
+>**Notes:**
+- **Do not** setup any custom authentication in the secondary nodes, this will be
+  handled by the primary node.
+- **Do not** add anything in the secondaries Geo nodes admin area
+  (**Admin Area ➔ Geo Nodes**). This is handled solely by the primary node.
+
+### Step 1. Manually replicate secret GitLab values
+
+GitLab stores a number of secret values in the `/home/git/gitlab/config/secrets.yml`
+file which *must* match between the primary and secondary nodes. Until there is
+a means of automatically replicating these between nodes (see
+[issue #3789](https://gitlab.com/gitlab-org/gitlab-ee/issues/3789)), they must
+be manually replicated to the secondary.
+
+1. SSH into the **primary** node, and execute the command below:
+
+    ```bash
+    sudo cat /home/git/gitlab/config/secrets.yml
+    ```
+
+    This will display the secrets that need to be replicated, in YAML format.
+
+1. SSH into the **secondary** node and login as the `git` user:
+
+    ```bash
+    sudo -i -u git
+    ```
+
+1. Make a backup of any existing secrets:
+
+    ```bash
+    mv /home/git/gitlab/config/secrets.yml /home/git/gitlab/config/secrets.yml.`date +%F`
+    ```
+
+1. Copy `/home/git/gitlab/config/secrets.yml` from the primary to the secondary, or
+   copy-and-paste the file contents between nodes:
+
+    ```bash
+    sudo editor /home/git/gitlab/config/secrets.yml
+
+    # paste the output of the `cat` command you ran on the primary
+    # save and exit
+    ```
+
+1. Ensure the file permissions are correct:
+
+    ```bash
+    chown git:git /home/git/gitlab/config/secrets.yml
+    chmod 0600 /home/git/gitlab/config/secrets.yml
+    ```
+
+1. Restart GitLab for the changes to take effect:
+
+    ```bash
+    service gitlab restart
+    ```
+
+Once restarted, the secondary will automatically start replicating missing data
+from the primary in a process known as backfill. Meanwhile, the primary node
+will start to notify the secondary of any changes, so that the secondary can
+act on those notifications immediately.
+
+Make sure the secondary instance is running and accessible. You can login to
+the secondary node with the same credentials as used in the primary.
+
+### Step 2. Manually replicate primary SSH host keys
+
+Read [Manually replicate primary SSH host keys](configuration.md#step-2-manually-replicate-primary-ssh-host-keys)
+
+### Step 3. (Optional) Enabling hashed storage (from GitLab 10.0)
+
+Read [Enabling Hashed Storage](configuration.md#step-3-optional-enabling-hashed-storage-from-gitlab-10-0)
+
+### Step 4. (Optional) Configuring the secondary to trust the primary
+
+You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
+
+If your primary is using a self-signed certificate for *HTTPS* support, you will
+need to add that certificate to the secondary's trust store. Retrieve the
+certificate from the primary and follow your distribution's instructions for
+adding it to the secondary's trust store. In Debian/Ubuntu, for example, with a
+certificate file of `primary.geo.example.com.crt`, you would follow these steps:
+
+```
+sudo -i
+cp primary.geo.example.com.crt /usr/local/share/ca-certificates
+update-ca-certificates
+```
+
+### 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`) on the primary node, and set
+`Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
+
+### Step 6. Verify proper functioning of the secondary node
+
+Read [Verify proper functioning of the secondary node](configuration.md#step-6-verify-proper-functioning-of-the-secondary-node).
+
+
+## Selective synchronization
+
+Read [Selective synchronization](configuration.md#selective-synchronization).
+
+## Troubleshooting
+
+Read the [troubleshooting document](troubleshooting.md).

doc/administration/geo/replication/docker_registry.md

+# Docker Registry for a secondary node
+
+You can setup a [Docker Registry](https://docs.docker.com/registry/) on your
+secondary Geo node that mirrors the one on the primary Geo node.
+
+## Storage support
+
+CAUTION: **Warning:**
+If you use [local storage](../container_registry.md#container-registry-storage-driver)
+for the Container Registry you **cannot** replicate it to the secondary Geo node.
+
+Docker Registry currently supports a few types of storages. If you choose a
+distributed storage (`azure`, `gcs`, `s3`, `swift`, or `oss`) for your Docker
+Registry on a primary Geo node, you can use the same storage for a secondary
+Docker Registry as well. For more information, read the
+[Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
+when deploying the Registry, and how to setup the storage driver for GitLab's
+integrated [Container Registry](../container_registry.md#container-registry-storage-driver).
+
+[ee]: https://about.gitlab.com/products/

doc/administration/geo/replication/faq.md

+# Geo Frequently Asked Questions
+
+## Can I use Geo in a disaster recovery situation?
+
+Yes, but there are limitations to what we replicate (see
+[What data is replicated to a secondary node?](#what-data-is-replicated-to-a-secondary-node)).
+
+Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
+
+## What data is replicated to a secondary node?
+
+We currently replicate project repositories, LFS objects, generated
+attachments / avatars and the whole database. This means user accounts,
+issues, merge requests, groups, project data, etc., will be available for
+query. We currently don't replicate artifact data (`shared/folder`).
+
+## Can I git push to a secondary node?
+
+No. All writing operations (this includes `git push`) must be done in your
+primary node.
+
+## How long does it take to have a commit replicated to a secondary node?
+
+All replication operations are asynchronous and are queued to be dispatched in
+a batched request every 10 minutes. Besides that, it depends on a lot of other
+factors including the amount of traffic, how big your commit is, the
+connectivity between your nodes, your hardware, etc.
+
+## What if the SSH server runs at a different port?
+
+We send the clone url from the primary server to any secondaries, so it
+doesn't matter. If primary is running on port `2200`, clone url will reflect
+that.
+
+## Is this possible to set up a Docker Registry for a secondary node that mirrors the one on a primary node?
+
+Yes. See [Docker Registry for a secondary Geo node](docker_registry.md).

doc/administration/geo/replication/high_availability.md

+# Geo High Availability
+
+This document describes a minimal reference architecture for running Geo
+in a high availability configuration. If your HA setup differs from the one
+described, it is possible to adapt these instructions to your needs.
+
+## Architecture overview
+
+![Geo HA Diagram](../img/high_availability/geo-ha-diagram.png)
+
+_[diagram source - gitlab employees only](https://docs.google.com/drawings/d/1z0VlizKiLNXVVVaERFwgsIOuEgjcUqDTWPdQYsE7Z4c/edit)_
+
+The topology above assumes that the primary and secondary Geo clusters
+are located in two separate locations, on their own virtual network
+with private IP addresses. The network is configured such that all machines within
+one geographic location can communicate with each other using their private IP addresses.
+The IP addresses given are examples and may be different depending on the
+network topology of your deployment.
+
+The only external way to access the two Geo deployments is by HTTPS at
+`gitlab.us.example.com` and `gitlab.eu.example.com` in the example above.
+
+> **Note:** The primary and secondary Geo deployments must be able to
+> communicate to each other over HTTPS.
+
+## Redis and PostgreSQL High Availability
+
+The primary and secondary Redis and PostgreSQL should be configured
+for high availability.  Because of the additional complexity involved
+in setting up this configuration for PostgreSQL and Redis
+it is not covered by this Geo HA documentation.
+The two services will instead be configured such that
+they will each run on a single machine.
+
+For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
+[PostgreSQL](../high_availability/database.md) and
+[Redis](../high_availability/redis.md), respectively.
+
+From these instructions you will need the following for the examples below:
+* `gitlab_rails['db_password']` for the PostgreSQL "DB password"
+* `redis['password']` for the Redis "Redis password"
+
+NOTE: **Note:**
+It is possible to use cloud hosted services for PostgreSQL and Redis but this is beyond the scope of this document.
+
+### Prerequisites
+
+Make sure you have GitLab EE installed using the
+[Omnibus package](https://about.gitlab.com/installation).
+
+
+### Step 1: Configure the Geo Backend Services
+
+On the **primary** backend servers configure the following services:
+
+* [Redis](../high_availability/redis.md) for high availability.
+* [NFS Server](../high_availability/nfs.md) for repository, LFS, and upload storage.
+* [PostgreSQL](../high_availability/database.md) for high availability.
+
+On the **secondary** backend servers configure the following services:
+
+* [Redis](../high_availability/redis.md) for high availability.
+* [NFS Server](../high_availability/nfs.md) which will store data that is synchronized from the Geo primary.
+
+### Step 2: Configure the Postgres services on the Geo Secondary
+
+1. Configure the [secondary Geo PostgreSQL database](../gitlab-geo/database.md)
+ as a read-only secondary of the primary Geo PostgreSQL database.
+
+1. Configure the Geo tracking database on the secondary server, to do this modify `/etc/gitlab/gitlab.rb`:
+
+    ```ruby
+    geo_postgresql['enable'] = true
+
+    geo_postgresql['listen_address'] = '10.1.4.1'
+    geo_postgresql['trust_auth_cidr_addresses'] = ['10.1.0.0/16']
+
+    geo_secondary['auto_migrate'] = true
+    geo_secondary['db_host'] = '10.1.4.1'
+    geo_secondary['db_password'] = 'Geo tracking DB password'
+    ```
+
+NOTE: **Note:**
+Be sure that other non-postgresql services are disabled by setting `enable` to `false` in
+the [gitlab.rb configuration](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template).
+
+After making these changes be sure to run `sudo gitlab-ctl reconfigure` so that they take effect.
+
+### Step 3: Setup the LoadBalancer
+
+In this topology there will need to be a load balancers at each geographical location
+to route traffic to the application servers.
+
+See the [Load Balancer for GitLab HA](../high_availability/load_balancer.md)
+documentation for more information.
+
+### Step 4: Configure the Geo Frontend Application Servers
+
+In the architecture overview there are two machines running the GitLab application
+services.  These services are enabled selectively in the configuration. Additionally
+the addresses of the remote endpoints for PostgreSQL and Redis will need to be specified.
+
+#### On the GitLab Primary Frontend servers
+
+1. Edit `/etc/gitlab/gitlab.rb` and ensure the following to disable PostgreSQL and Redis from running locally.
+
+    ```ruby
+    ##
+    ## Disable PostgreSQL on the local machine and connect to the remote
+    ##
+
+    postgresql['enable'] = false
+    gitlab_rails['auto_migrate'] = false
+    gitlab_rails['db_host'] = '10.0.3.1'
+    gitlab_rails['db_password'] = 'DB password'
+
+    ##
+    ## Disable Redis on the local machine and connect to the remote
+    ##
+
+    redis['enable'] = false
+    gitlab_rails['redis_host'] = '10.0.2.1'
+    gitlab_rails['redis_password'] = 'Redis password'
+
+    geo_primary_role['enable'] = true
+    ```
+
+#### On the GitLab Secondary Frontend servers
+
+On the secondary the remote endpoint for the PostgreSQL Geo database will
+be specified.
+
+1. Edit `/etc/gitlab/gitlab.rb` and ensure the following to disable PostgreSQL and Redis from running locally. Configure the secondary to connect to the Geo tracking database.
+
+
+    ```ruby
+    ##
+    ## Disable PostgreSQL on the local machine and connect to the remote
+    ##
+
+    postgresql['enable'] = false
+    gitlab_rails['auto_migrate'] = false
+    gitlab_rails['db_host'] = '10.1.3.1'
+    gitlab_rails['db_password'] = 'DB password'
+
+    ##
+    ## Disable Redis on the local machine and connect to the remote
+    ##
+
+    redis['enable'] = false
+    gitlab_rails['redis_host'] = '10.1.2.1'
+    gitlab_rails['redis_password'] = 'Redis password'
+
+
+    ##
+    ## Enable the geo secondary role and configure the
+    ## geo tracking database
+    ##
+
+    geo_secondary_role['enable'] = true
+    geo_secondary['db_host'] = '10.1.4.1'
+    geo_secondary['db_password'] = 'Geo tracking DB password'
+    geo_postgresql['enable'] = false
+    ```
+
+
+After making these changes [Reconfigure GitLab][] so that they take effect.
+
+On the primary the following GitLab frontend services will be enabled:
+
+* gitlab-pages
+* gitlab-workhorse
+* logrotate
+* nginx
+* registry
+* remote-syslog
+* sidekiq
+* unicorn
+
+On the secondary the following GitLab frontend services will be enabled:
+
+* geo-logcursor
+* gitlab-pages
+* gitlab-workhorse
+* logrotate
+* nginx
+* registry
+* remote-syslog
+* sidekiq
+* unicorn
+
+Verify these services by running `sudo gitlab-ctl status` on the frontend
+application servers.
+
+[reconfigure GitLab]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
+[restart GitLab]: ../restart_gitlab.md#omnibus-gitlab-restart

doc/administration/geo/replication/object_storage.md

+# Geo with Object storage
+
+Geo can be used in combination with Object Storage (AWS S3, or
+other compatible object storage).
+
+## Configuration
+
+At this time it is required that if object storage is enabled on the
+primary, it must also be enabled on the secondary.
+
+The secondary nodes can use the same storage bucket as the primary, or
+they can use a replicated storage bucket. At this time GitLab does not
+take care of content replication in object storage.
+
+For LFS, follow the documentation to
+[set up LFS object storage](../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
+
+For CI job artifacts, there is similar documentation to configure
+[jobs artifact object storage](../job_artifacts.md#using-object-storage)
+
+Complete these steps on all nodes, primary **and** secondary.
+
+## Replication
+
+When using Amazon S3, you can use
+[CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to
+have automatic replication between the bucket used by the primary and
+the bucket used by the secondary.
+
+If you are using Google Cloud Storage, consider using
+[Multi-Regional Storage](https://cloud.google.com/storage/docs/storage-classes#multi-regional).
+Or you can use the [Storage Transfer Service](https://cloud.google.com/storage/transfer/),
+although this only supports daily synchronization.
+
+For manual synchronization, or scheduled by `cron`, please have a look at:
+
+- [`s3cmd sync`](http://s3tools.org/s3cmd-sync)
+- [`gsutil rsync`](https://cloud.google.com/storage/docs/gsutil/commands/rsync)

doc/administration/geo/replication/troubleshooting.md

+# Geo Troubleshooting
+
+>**Note:**
+This list is an attempt to document all the moving parts that can go wrong.
+We are working into getting all this steps verified automatically in a
+rake task in the future.
+
+Setting up Geo requires careful attention to details and sometimes it's easy to
+miss a step. Here is a list of questions you should ask to try to detect
+what you need to fix (all commands and path locations are for Omnibus installs):
+
+#### First check the health of the secondary
+
+Visit the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`) in
+your browser. We perform the following health checks on each secondary node
+to help identify if something is wrong:
+
+- Is the node running?
+- Is the node's secondary database configured for streaming replication?
+- Is the node's secondary tracking database configured?
+- Is the node's secondary tracking database connected?
+- Is the node's secondary tracking database up-to-date?
+
+![Geo health check](img/geo-node-healthcheck.png)
+
+There is also an option to check the status of the secondary node by running a special rake task:
+
+```
+sudo gitlab-rake geo:status
+```
+
+#### Is Postgres replication working?
+
+#### Are my nodes pointing to the correct database instance?
+
+You should make sure your primary Geo node points to the instance with
+writing permissions.
+
+Any secondary nodes should point only to read-only instances.
+
+#### Can Geo detect my current node correctly?
+
+Geo uses the defined node from the `Admin ➔ Geo` screen, and tries to match
+it with the value defined in the `/etc/gitlab/gitlab.rb` configuration file.
+The relevant line looks like: `external_url "http://gitlab.example.com"`.
+
+To check if the node on the current machine is correctly detected type:
+
+```bash
+sudo gitlab-rails runner "puts Gitlab::Geo.current_node.inspect"
+```
+
+and expect something like:
+
+```
+#<GeoNode id: 2, schema: "https", host: "gitlab.example.com", port: 443, relative_url_root: "", primary: false, ...>
+```
+
+By running the command above, `primary` should be `true` when executed in
+the primary node, and `false` on any secondary.
+
+#### How do I fix 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 Geo
+secondary nodes. Be sure to restart PostgreSQL for this to take
+effect. See the [PostgreSQL replication
+setup](database.md#postgresql-replication) guide for more details.
+
+#### How do I fix the message, "FATAL:  could not start WAL streaming: ERROR:  replication slot "geo_secondary_my_domain_com" does not exist"?
+
+This occurs when PostgreSQL does not have a replication slot for the
+secondary by that name. You may want to rerun the [replication
+process](database.md) on the secondary.
+
+#### How do I fix the message, "Command exceeded allowed execution time" when setting up replication?
+
+This may happen while [initiating the replication process](database.md#step-4-initiate-the-replication-process) on the Geo secondary, and indicates that your
+initial dataset is too large to be replicated in the default timeout (30 minutes).
+
+Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
+`--backup-timeout`:
+
+```bash
+sudo gitlab-ctl replicate-geo-database --host=primary.geo.example.com --slot-name=secondary_geo_example_com --backup-timeout=21600
+```
+
+This will give the initial replication up to six hours to complete, rather than
+the default thirty minutes. Adjust as required for your installation.
+
+#### How do I fix the message, "PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device"
+
+Determine if you have any unused replication slots in the primary database.  This can cause large amounts of log data to build up in `pg_xlog`.
+Removing the unused slots can reduce the amount of space used in the `pg_xlog`.
+
+1. Start a PostgreSQL console session:
+
+    ```bash
+    sudo gitlab-psql gitlabhq_production
+    ```
+
+    Note that using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
+
+2. View your replication slots with
+
+     ```sql
+     SELECT * FROM pg_replication_slots;
+     ```
+
+Slots where `active` is `f` are not active.
+
+- When this slot should be active, because you have a secondary configured using that slot,
+log in to that secondary and check the PostgreSQL logs why the replication is not running.
+
+- If you are no longer using the slot (e.g. you no longer have Geo enabled), you can remove it with in the PostgreSQL console session:
+
+    ```sql
+    SELECT pg_drop_replication_slot('name_of_extra_slot');
+    ```
+
+#### Very large repositories never successfully synchronize on the secondary
+
+GitLab places a timeout on all repository clones, including project imports
+and Geo synchronization operations. If a fresh `git clone` of a repository
+on the primary takes more than a few minutes, you may be affected by this.
+To increase the timeout, add the following line to `/etc/gitlab/gitlab.rb`
+on the secondary:
+
+```ruby
+gitlab_rails['gitlab_shell_git_timeout'] = 10800
+```
+
+Then reconfigure GitLab:
+
+```bash
+sudo gitlab-ctl reconfigure
+```
+
+This will increase the timeout to three hours (10800 seconds). Choose a time
+long enough to accomodate a full clone of your largest repositories.

doc/administration/geo/replication/tuning.md

+# Tuning Geo
+
+## Changing the sync capacity values
+
+In the Geo admin page (`/admin/geo_nodes`), there are several variables that
+can be tuned to improve performance of Geo:
+
+* Repository sync capacity
+* File sync capacity
+
+Increasing these values will increase the number of jobs that are scheduled,
+but this may not lead to a more downloads in parallel unless the number of
+available Sidekiq threads is also increased. For example, if repository sync
+capacity is increased from 25 to 50, you may also want to increase the number
+of Sidekiq threads from 25 to 50. See the [Sidekiq concurrency
+documentation](../operations/extra_sidekiq_processes.html#concurrency)
+for more details.

doc/administration/geo/replication/using_a_geo_server.md

+[//]: # (Please update EE::GitLab::GeoGitAccess::GEO_SERVER_DOCS_URL if this file is moved)
+
+# Using a Geo Server
+
+After you set up the [database replication and configure the Geo nodes][req],
+there are a few things to consider:
+
+1. Users need an extra step to be able to fetch code from the secondary and push
+   to primary:
+
+     1. Clone the repository as you would normally do, but from the secondary node:
+
+         ```bash
+         git clone git@secondary.gitlab.example.com:user/repo.git
+         ```
+
+     1. Change the remote push URL to always push to primary, following this example:
+
+         ```bash
+         git remote set-url --push origin git@primary.gitlab.example.com:user/repo.git
+         ```
+
+[req]: README.md#setup-instructions

doc/gitlab-geo/configuration.md

-# Geo configuration
-
->**Note:**
-This is the documentation for the Omnibus GitLab packages. For installations
-from source, follow the [**Geo nodes configuration for installations
-from source**](configuration_source.md) guide.
-
-## Configuring a new secondary node
-
->**Note:**
-This is the final step in setting up a secondary Geo node. Stages of the
-setup process must be completed in the documented order.
-Before attempting the steps in this stage, [complete all prior stages](README.md#using-omnibus-gitlab).
-
-The basic steps of configuring a secondary node are to replicate required
-configurations between the primary and the secondaries; to configure a tracking
-database on each secondary; and to start GitLab on the secondary node.
-
-You are encouraged to first read through all the steps before executing them
-in your testing/production environment.
-
->**Notes:**
-- **Do not** setup any custom authentication in the secondary nodes, this will be
-  handled by the primary node.
-- **Do not** add anything in the secondaries Geo nodes admin area
-  (**Admin Area ➔ Geo Nodes**). This is handled solely by the primary node.
-
-### Step 1. Manually replicate secret GitLab values
-
-GitLab stores a number of secret values in the `/etc/gitlab/gitlab-secrets.json`
-file which *must* match between the primary and secondary nodes. Until there is
-a means of automatically replicating these between nodes (see
-[issue #3789](https://gitlab.com/gitlab-org/gitlab-ee/issues/3789)), they must
-be manually replicated to the secondary.
-
-1. SSH into the **primary** node, and execute the command below:
-
-    ```bash
-    sudo cat /etc/gitlab/gitlab-secrets.json
-    ```
-
-    This will display the secrets that need to be replicated, in JSON format.
-
-1. SSH into the **secondary** node and login as the `root` user:
-
-    ```
-    sudo -i
-    ```
-
-1. Make a backup of any existing secrets:
-
-    ```bash
-    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
-    ```
-
-1. Copy `/etc/gitlab/gitlab-secrets.json` from the primary to the secondary, or
-   copy-and-paste the file contents between nodes:
-
-    ```bash
-    sudo editor /etc/gitlab/gitlab-secrets.json
-
-    # paste the output of the `cat` command you ran on the primary
-    # save and exit
-    ```
-
-1. Ensure the file permissions are correct:
-
-    ```bash
-    chown root:root /etc/gitlab/gitlab-secrets.json
-    chmod 0600 /etc/gitlab/gitlab-secrets.json
-    ```
-
-1. Reconfigure the secondary node for the change to take effect:
-
-    ```
-    gitlab-ctl reconfigure
-    ```
-
-Once reconfigured, the secondary will automatically start
-replicating missing data from the primary in a process known as backfill.
-Meanwhile, the primary node will start to notify the secondary of any changes, so
-that the secondary can act on those notifications immediately.
-
-Make sure the secondary instance is
-running and accessible. You can login to the secondary node
-with the same credentials as used in the primary.
-
-### Step 2. Manually replicate primary SSH host keys
-
-GitLab integrates with the system-installed SSH daemon, designating a user
-(typically named git) through which all access requests are handled.
-
-In a [Disaster Recovery](../administration/disaster_recovery/index.md) situation, GitLab system
-administrators will promote a secondary Geo replica to a primary and they can
-update the DNS records for the primary domain to point to the secondary to prevent
-the need to update all references to the primary domain to the secondary domain,
-like changing Git remotes and API URLs.
-
-This will cause all SSH requests to the newly promoted primary node from
-failing due to SSH host key mismatch. To prevent this, the primary SSH host
-keys must be manually replicated to the secondary node.
-
-1. SSH into the **secondary** node and login as the `root` user:
-
-    ```
-    sudo -i
-    ```
-
-1. Make a backup of any existing SSH host keys:
-
-    ```bash
-    find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
-    ```
-
-1. SSH into the **primary** node, and execute the command below:
-
-    ```bash
-    sudo find /etc/ssh -iname ssh_host_* -not -iname '*.pub'
-    ```
-
-1. For each file in that list replace the file from the primary node to
-   the **same** location on your **secondary** node.
-
-1. On your **secondary** node, ensure the file permissions are correct:
-
-    ```bash
-    chown root:root /etc/ssh/ssh_host_*
-    chmod 0600 /etc/ssh/ssh_host_*
-    ```
-
-1. Regenerate the public keys from the private keys:
-
-    ```bash
-    find /etc/ssh -iname ssh_host_* -not -iname '*.backup*' -exec sh -c 'ssh-keygen -y -f "{}" > "{}.pub"' \;
-    ```
-
-1. Restart sshd:
-
-    ```bash
-    service ssh restart
-    ```
-
-### Step 3. (Optional) Enabling hashed storage (from GitLab 10.0)
-
->**Warning**
-Hashed storage is in **Beta**. It is not considered production-ready. See
-[Hashed Storage](../administration/repository_storage_types.md) for more detail,
-and for the latest updates, check
-[infrastructure issue #2821](https://gitlab.com/gitlab-com/infrastructure/issues/2821).
-
-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**
-   (`/admin/application_settings`) in your browser
-1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
-
-    ![](img/hashed-storage.png)
-
-### Step 4. (Optional) Configuring the secondary to trust the primary
-
-You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
-
-If your primary is using a self-signed certificate for *HTTPS* support, you will
-need to add that certificate to the secondary's trust store. Retrieve the
-certificate from the primary and follow
-[these instructions](https://docs.gitlab.com/omnibus/settings/ssl.html)
-on the secondary.
-
-### 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`) on the primary node, and set
-`Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
-
-### Step 6. Verify proper functioning of the secondary node
-
-Congratulations! Your secondary geo node is now configured!
-
-You can login to the secondary node with the same credentials you used on the
-primary. Visit the secondary node's **Admin Area ➔ Geo Nodes**
-(`/admin/geo_nodes`) in your browser to check 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
-node's Geo Nodes dashboard in your browser.
-
-![Geo dashboard](img/geo-node-dashboard.png)
-
-If your installation isn't working properly, check the
-[troubleshooting document](troubleshooting.md).
-
-The two most obvious issues that can become apparent in the dashboard are:
-
-1. Database replication not working well
-1. Instance to instance notification not working. In that case, it can be
-   something of the following:
-     - You are using a custom certificate or custom CA (see the
-       [troubleshooting document](troubleshooting.md))
-     - The instance is firewalled (check your firewall rules)
-
-Please note that disabling a secondary node will stop the sync process.
-
-Please note that if `git_data_dirs` is customized on the primary for multiple
-repository shards you must duplicate the same configuration on the secondary.
-
-Point your users to the ["Using a Geo Server" guide](using_a_geo_server.md).
-
-Currently, this is what is synced:
-
-* Git repositories
-* Wikis
-* LFS objects
-* Issues, merge requests, snippets, and comment attachments
-* Users, groups, and project avatars
-
-## Selective synchronization
-
-Geo supports selective synchronization, which allows admins to choose
-which projects should be synchronized by secondary nodes.
-
-It is important to note that selective synchronization does not:
-
-1. Restrict permissions from secondary nodes.
-1. Hide project metadata from secondary nodes.
-  * Since Geo currently relies on PostgreSQL replication, all project metadata
-    gets replicated to secondary nodes, but repositories that have not been
-    selected will be empty.
-1. Reduce the number of events generated for the Geo event log
-  * The primary generates events as long as any secondaries are present.
-    Selective synchronization restrictions are implemented on the secondaries,
-    not the primary.
-
-A subset of projects can be chosen, either by group or by storage shard. The
-former is ideal for replicating data belonging to a subset of users, while the
-latter is more suited to progressively rolling out Geo to a large GitLab
-instance.
-
-## Upgrading Geo
-
-See the [updating the Geo nodes document](updating_the_geo_nodes.md).
-
-## Troubleshooting
-
-See the [troubleshooting document](troubleshooting.md).
+This document was moved to [another location](../administration/geo/configuration.md).

doc/gitlab-geo/configuration_source.md

-# Geo configuration
-
->**Note:**
-This is the documentation for installations from source. For installations
-using the Omnibus GitLab packages, follow the
-[**Omnibus Geo nodes configuration**](configuration.md) guide.
-
-## Configuring a new secondary node
-
->**Note:**
-This is the final step in setting up a secondary Geo node. Stages of the setup
-process must be completed in the documented order. Before attempting the steps
-in this stage, [complete all prior stages](README.md#using-gitlab-installed-from-source).
-
-The basic steps of configuring a secondary node are to replicate required
-configurations between the primary and the secondaries; to configure a tracking
-database on each secondary; and to start GitLab on the secondary node.
-
-You are encouraged to first read through all the steps before executing them
-in your testing/production environment.
-
-
->**Notes:**
-- **Do not** setup any custom authentication in the secondary nodes, this will be
-  handled by the primary node.
-- **Do not** add anything in the secondaries Geo nodes admin area
-  (**Admin Area ➔ Geo Nodes**). This is handled solely by the primary node.
-
-### Step 1. Manually replicate secret GitLab values
-
-GitLab stores a number of secret values in the `/home/git/gitlab/config/secrets.yml`
-file which *must* match between the primary and secondary nodes. Until there is
-a means of automatically replicating these between nodes (see
-[issue #3789](https://gitlab.com/gitlab-org/gitlab-ee/issues/3789)), they must
-be manually replicated to the secondary.
-
-1. SSH into the **primary** node, and execute the command below:
-
-    ```bash
-    sudo cat /home/git/gitlab/config/secrets.yml
-    ```
-
-    This will display the secrets that need to be replicated, in YAML format.
-
-1. SSH into the **secondary** node and login as the `git` user:
-
-    ```bash
-    sudo -i -u git
-    ```
-
-1. Make a backup of any existing secrets:
-
-    ```bash
-    mv /home/git/gitlab/config/secrets.yml /home/git/gitlab/config/secrets.yml.`date +%F`
-    ```
-
-1. Copy `/home/git/gitlab/config/secrets.yml` from the primary to the secondary, or
-   copy-and-paste the file contents between nodes:
-
-    ```bash
-    sudo editor /home/git/gitlab/config/secrets.yml
-
-    # paste the output of the `cat` command you ran on the primary
-    # save and exit
-    ```
-
-1. Ensure the file permissions are correct:
-
-    ```bash
-    chown git:git /home/git/gitlab/config/secrets.yml
-    chmod 0600 /home/git/gitlab/config/secrets.yml
-    ```
-
-1. Restart GitLab for the changes to take effect:
-
-    ```bash
-    service gitlab restart
-    ```
-
-Once restarted, the secondary will automatically start replicating missing data
-from the primary in a process known as backfill. Meanwhile, the primary node
-will start to notify the secondary of any changes, so that the secondary can
-act on those notifications immediately.
-
-Make sure the secondary instance is running and accessible. You can login to
-the secondary node with the same credentials as used in the primary.
-
-### Step 2. Manually replicate primary SSH host keys
-
-Read [Manually replicate primary SSH host keys](configuration.md#step-2-manually-replicate-primary-ssh-host-keys)
-
-### Step 3. (Optional) Enabling hashed storage (from GitLab 10.0)
-
-Read [Enabling Hashed Storage](configuration.md#step-3-optional-enabling-hashed-storage-from-gitlab-10-0)
-
-### Step 4. (Optional) Configuring the secondary to trust the primary
-
-You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
-
-If your primary is using a self-signed certificate for *HTTPS* support, you will
-need to add that certificate to the secondary's trust store. Retrieve the
-certificate from the primary and follow your distribution's instructions for
-adding it to the secondary's trust store. In Debian/Ubuntu, for example, with a
-certificate file of `primary.geo.example.com.crt`, you would follow these steps:
-
-```
-sudo -i
-cp primary.geo.example.com.crt /usr/local/share/ca-certificates
-update-ca-certificates
-```
-
-### 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`) on the primary node, and set
-`Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
-
-### Step 6. Verify proper functioning of the secondary node
-
-Read [Verify proper functioning of the secondary node](configuration.md#step-6-verify-proper-functioning-of-the-secondary-node).
-
-
-## Selective synchronization
-
-Read [Selective synchronization](configuration.md#selective-synchronization).
-
-## Troubleshooting
-
-Read the [troubleshooting document](troubleshooting.md).
+This document was moved to [another location](../administration/geo/configuration_source.md).

doc/gitlab-geo/docker_registry.md

-# Docker Registry for a secondary node
-
-You can setup a [Docker Registry](https://docs.docker.com/registry/) on your
-secondary Geo node that mirrors the one on the primary Geo node.
-
-## Storage support
-
-CAUTION: **Warning:**
-If you use [local storage](../administration/container_registry.md#container-registry-storage-driver)
-for the Container Registry you **cannot** replicate it to the secondary Geo node.
-
-Docker Registry currently supports a few types of storages. If you choose a
-distributed storage (`azure`, `gcs`, `s3`, `swift`, or `oss`) for your Docker
-Registry on a primary Geo node, you can use the same storage for a secondary
-Docker Registry as well. For more information, read the
-[Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
-when deploying the Registry, and how to setup the storage driver for GitLab's
-integrated [Container Registry](../administration/container_registry.md#container-registry-storage-driver).
-
-[ee]: https://about.gitlab.com/products/
+This document was moved to [another location](../administration/geo/docker_registry.md).

doc/gitlab-geo/faq.md

-# Geo Frequently Asked Questions
-
-## Can I use Geo in a disaster recovery situation?
-
-Yes, but there are limitations to what we replicate (see
-[What data is replicated to a secondary node?](#what-data-is-replicated-to-a-secondary-node)).
-
-Read the documentation for [Disaster Recovery](../administration/disaster_recovery/index.md).
-
-## What data is replicated to a secondary node?
-
-We currently replicate project repositories, LFS objects, generated
-attachments / avatars and the whole database. This means user accounts,
-issues, merge requests, groups, project data, etc., will be available for
-query. We currently don't replicate artifact data (`shared/folder`).
-
-## Can I git push to a secondary node?
-
-No. All writing operations (this includes `git push`) must be done in your
-primary node.
-
-## How long does it take to have a commit replicated to a secondary node?
-
-All replication operations are asynchronous and are queued to be dispatched in
-a batched request every 10 minutes. Besides that, it depends on a lot of other
-factors including the amount of traffic, how big your commit is, the
-connectivity between your nodes, your hardware, etc.
-
-## What if the SSH server runs at a different port?
-
-We send the clone url from the primary server to any secondaries, so it
-doesn't matter. If primary is running on port `2200`, clone url will reflect
-that.
-
-## Is this possible to set up a Docker Registry for a secondary node that mirrors the one on a primary node?
-
-Yes. See [Docker Registry for a secondary Geo node](docker_registry.md).
+This document was moved to [another location](../administration/geo/faq.md).

doc/gitlab-geo/ha.md

-# Geo High Availability
-
-This document describes a minimal reference architecture for running Geo
-in a high availability configuration. If your HA setup differs from the one
-described, it is possible to adapt these instructions to your needs.
-
-## Architecture overview
-
-![Geo HA Diagram](../administration/img/high_availability/geo-ha-diagram.png)
-
-_[diagram source - gitlab employees only](https://docs.google.com/drawings/d/1z0VlizKiLNXVVVaERFwgsIOuEgjcUqDTWPdQYsE7Z4c/edit)_
-
-The topology above assumes that the primary and secondary Geo clusters
-are located in two separate locations, on their own virtual network
-with private IP addresses. The network is configured such that all machines within
-one geographic location can communicate with each other using their private IP addresses.
-The IP addresses given are examples and may be different depending on the
-network topology of your deployment.
-
-The only external way to access the two Geo deployments is by HTTPS at
-`gitlab.us.example.com` and `gitlab.eu.example.com` in the example above.
-
-> **Note:** The primary and secondary Geo deployments must be able to
-> communicate to each other over HTTPS.
-
-## Redis and PostgreSQL High Availability
-
-The primary and secondary Redis and PostgreSQL should be configured
-for high availability.  Because of the additional complexity involved
-in setting up this configuration for PostgreSQL and Redis
-it is not covered by this Geo HA documentation.
-The two services will instead be configured such that
-they will each run on a single machine.
-
-For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
-[PostgreSQL](../administration/high_availability/database.md) and
-[Redis](../administration/high_availability/redis.md), respectively.
-
-From these instructions you will need the following for the examples below:
-* `gitlab_rails['db_password']` for the PostgreSQL "DB password"
-* `redis['password']` for the Redis "Redis password"
-
-NOTE: **Note:**
-It is possible to use cloud hosted services for PostgreSQL and Redis but this is beyond the scope of this document.
-
-### Prerequisites
-
-Make sure you have GitLab EE installed using the
-[Omnibus package](https://about.gitlab.com/installation).
-
-
-### Step 1: Configure the Geo Backend Services
-
-On the **primary** backend servers configure the following services:
-
-* [Redis](../administration/high_availability/redis.md) for high availability.
-* [NFS Server](../administration/high_availability/nfs.md) for repository, LFS, and upload storage.
-* [PostgreSQL](../administration/high_availability/database.md) for high availability.
-
-On the **secondary** backend servers configure the following services:
-
-* [Redis](../administration/high_availability/redis.md) for high availability.
-* [NFS Server](../administration/high_availability/nfs.md) which will store data that is synchronized from the Geo primary.
-
-### Step 2: Configure the Postgres services on the Geo Secondary
-
-1. Configure the [secondary Geo PostgreSQL database](../gitlab-geo/database.md)
- as a read-only secondary of the primary Geo PostgreSQL database.
-
-1. Configure the Geo tracking database on the secondary server, to do this modify `/etc/gitlab/gitlab.rb`:
-
-    ```ruby
-    geo_postgresql['enable'] = true
-
-    geo_postgresql['listen_address'] = '10.1.4.1'
-    geo_postgresql['trust_auth_cidr_addresses'] = ['10.1.0.0/16']
-
-    geo_secondary['auto_migrate'] = true
-    geo_secondary['db_host'] = '10.1.4.1'
-    geo_secondary['db_password'] = 'Geo tracking DB password'
-    ```
-
-NOTE: **Note:**
-Be sure that other non-postgresql services are disabled by setting `enable` to `false` in
-the [gitlab.rb configuration](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template).
-
-After making these changes be sure to run `sudo gitlab-ctl reconfigure` so that they take effect.
-
-### Step 3: Setup the LoadBalancer
-
-In this topology there will need to be a load balancers at each geographical location
-to route traffic to the application servers.
-
-See the [Load Balancer for GitLab HA](../administration/high_availability/load_balancer.md)
-documentation for more information.
-
-### Step 4: Configure the Geo Frontend Application Servers
-
-In the architecture overview there are two machines running the GitLab application
-services.  These services are enabled selectively in the configuration. Additionally
-the addresses of the remote endpoints for PostgreSQL and Redis will need to be specified.
-
-#### On the GitLab Primary Frontend servers
-
-1. Edit `/etc/gitlab/gitlab.rb` and ensure the following to disable PostgreSQL and Redis from running locally.
-
-    ```ruby
-    ##
-    ## Disable PostgreSQL on the local machine and connect to the remote
-    ##
-
-    postgresql['enable'] = false
-    gitlab_rails['auto_migrate'] = false
-    gitlab_rails['db_host'] = '10.0.3.1'
-    gitlab_rails['db_password'] = 'DB password'
-
-    ##
-    ## Disable Redis on the local machine and connect to the remote
-    ##
-
-    redis['enable'] = false
-    gitlab_rails['redis_host'] = '10.0.2.1'
-    gitlab_rails['redis_password'] = 'Redis password'
-
-    geo_primary_role['enable'] = true
-    ```
-
-#### On the GitLab Secondary Frontend servers
-
-On the secondary the remote endpoint for the PostgreSQL Geo database will
-be specified.
-
-1. Edit `/etc/gitlab/gitlab.rb` and ensure the following to disable PostgreSQL and Redis from running locally. Configure the secondary to connect to the Geo tracking database.
-
-
-    ```ruby
-    ##
-    ## Disable PostgreSQL on the local machine and connect to the remote
-    ##
-
-    postgresql['enable'] = false
-    gitlab_rails['auto_migrate'] = false
-    gitlab_rails['db_host'] = '10.1.3.1'
-    gitlab_rails['db_password'] = 'DB password'
-
-    ##
-    ## Disable Redis on the local machine and connect to the remote
-    ##
-
-    redis['enable'] = false
-    gitlab_rails['redis_host'] = '10.1.2.1'
-    gitlab_rails['redis_password'] = 'Redis password'
-
-
-    ##
-    ## Enable the geo secondary role and configure the
-    ## geo tracking database
-    ##
-
-    geo_secondary_role['enable'] = true
-    geo_secondary['db_host'] = '10.1.4.1'
-    geo_secondary['db_password'] = 'Geo tracking DB password'
-    geo_postgresql['enable'] = false
-    ```
-
-
-After making these changes [Reconfigure GitLab][] so that they take effect.
-
-On the primary the following GitLab frontend services will be enabled:
-
-* gitlab-pages
-* gitlab-workhorse
-* logrotate
-* nginx
-* registry
-* remote-syslog
-* sidekiq
-* unicorn
-
-On the secondary the following GitLab frontend services will be enabled:
-
-* geo-logcursor
-* gitlab-pages
-* gitlab-workhorse
-* logrotate
-* nginx
-* registry
-* remote-syslog
-* sidekiq
-* unicorn
-
-Verify these services by running `sudo gitlab-ctl status` on the frontend
-application servers.
-
-[reconfigure GitLab]: ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart GitLab]: ../administration/restart_gitlab.md#omnibus-gitlab-restart
+This document was moved to [another location](../administration/geo/high_availability.md).

doc/gitlab-geo/object_storage.md

-# Geo with Object storage
-
-Geo can be used in combination with Object Storage (AWS S3, or
-other compatible object storage).
-
-## Configuration
-
-At this time it is required that if object storage is enabled on the
-primary, it must also be enabled on the secondary.
-
-The secondary nodes can use the same storage bucket as the primary, or
-they can use a replicated storage bucket. At this time GitLab does not
-take care of content replication in object storage.
-
-For LFS, follow the documentation to
-[set up LFS object storage](../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
-
-For CI job artifacts, there is similar documentation to configure
-[jobs artifact object storage](../administration/job_artifacts.md#using-object-storage)
-
-Complete these steps on all nodes, primary **and** secondary.
-
-## Replication
-
-When using Amazon S3, you can use
-[CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to
-have automatic replication between the bucket used by the primary and
-the bucket used by the secondary.
-
-If you are using Google Cloud Storage, consider using
-[Multi-Regional Storage](https://cloud.google.com/storage/docs/storage-classes#multi-regional).
-Or you can use the [Storage Transfer Service](https://cloud.google.com/storage/transfer/),
-although this only supports daily synchronization.
-
-For manual synchronization, or scheduled by `cron`, please have a look at:
-
-- [`s3cmd sync`](http://s3tools.org/s3cmd-sync)
-- [`gsutil rsync`](https://cloud.google.com/storage/docs/gsutil/commands/rsync)
+This document was moved to [another location](../administration/geo/object_storage.md).

doc/gitlab-geo/troubleshooting.md

-# Geo Troubleshooting
-
->**Note:**
-This list is an attempt to document all the moving parts that can go wrong.
-We are working into getting all this steps verified automatically in a
-rake task in the future.
-
-Setting up Geo requires careful attention to details and sometimes it's easy to
-miss a step. Here is a list of questions you should ask to try to detect
-what you need to fix (all commands and path locations are for Omnibus installs):
-
-#### First check the health of the secondary
-
-Visit the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`) in
-your browser. We perform the following health checks on each secondary node
-to help identify if something is wrong:
-
-- Is the node running?
-- Is the node's secondary database configured for streaming replication?
-- Is the node's secondary tracking database configured?
-- Is the node's secondary tracking database connected?
-- Is the node's secondary tracking database up-to-date?
-
-![Geo health check](img/geo-node-healthcheck.png)
-
-There is also an option to check the status of the secondary node by running a special rake task:
-
-```
-sudo gitlab-rake geo:status
-```
-
-#### Is Postgres replication working?
-
-#### Are my nodes pointing to the correct database instance?
-
-You should make sure your primary Geo node points to the instance with
-writing permissions.
-
-Any secondary nodes should point only to read-only instances.
-
-#### Can Geo detect my current node correctly?
-
-Geo uses the defined node from the `Admin ➔ Geo` screen, and tries to match
-it with the value defined in the `/etc/gitlab/gitlab.rb` configuration file.
-The relevant line looks like: `external_url "http://gitlab.example.com"`.
-
-To check if the node on the current machine is correctly detected type:
-
-```bash
-sudo gitlab-rails runner "puts Gitlab::Geo.current_node.inspect"
-```
-
-and expect something like:
-
-```
-#<GeoNode id: 2, schema: "https", host: "gitlab.example.com", port: 443, relative_url_root: "", primary: false, ...>
-```
-
-By running the command above, `primary` should be `true` when executed in
-the primary node, and `false` on any secondary.
-
-#### How do I fix 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 Geo
-secondary nodes. Be sure to restart PostgreSQL for this to take
-effect. See the [PostgreSQL replication
-setup](database.md#postgresql-replication) guide for more details.
-
-#### How do I fix the message, "FATAL:  could not start WAL streaming: ERROR:  replication slot "geo_secondary_my_domain_com" does not exist"?
-
-This occurs when PostgreSQL does not have a replication slot for the
-secondary by that name. You may want to rerun the [replication
-process](database.md) on the secondary.
-
-#### How do I fix the message, "Command exceeded allowed execution time" when setting up replication?
-
-This may happen while [initiating the replication process](database.md#step-4-initiate-the-replication-process) on the Geo secondary, and indicates that your
-initial dataset is too large to be replicated in the default timeout (30 minutes).
-
-Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
-`--backup-timeout`:
-
-```bash
-sudo gitlab-ctl replicate-geo-database --host=primary.geo.example.com --slot-name=secondary_geo_example_com --backup-timeout=21600
-```
-
-This will give the initial replication up to six hours to complete, rather than
-the default thirty minutes. Adjust as required for your installation.
-
-#### How do I fix the message, "PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device"
-
-Determine if you have any unused replication slots in the primary database.  This can cause large amounts of log data to build up in `pg_xlog`.
-Removing the unused slots can reduce the amount of space used in the `pg_xlog`.
-
-1. Start a PostgreSQL console session:
-
-    ```bash
-    sudo gitlab-psql gitlabhq_production
-    ```
-
-    Note that using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
-
-2. View your replication slots with
-
-     ```sql
-     SELECT * FROM pg_replication_slots;
-     ```
-
-Slots where `active` is `f` are not active.
-
-- When this slot should be active, because you have a secondary configured using that slot,
-log in to that secondary and check the PostgreSQL logs why the replication is not running.
-
-- If you are no longer using the slot (e.g. you no longer have Geo enabled), you can remove it with in the PostgreSQL console session:
-
-    ```sql
-    SELECT pg_drop_replication_slot('name_of_extra_slot');
-    ```
-
-#### Very large repositories never successfully synchronize on the secondary
-
-GitLab places a timeout on all repository clones, including project imports
-and Geo synchronization operations. If a fresh `git clone` of a repository
-on the primary takes more than a few minutes, you may be affected by this.
-To increase the timeout, add the following line to `/etc/gitlab/gitlab.rb`
-on the secondary:
-
-```ruby
-gitlab_rails['gitlab_shell_git_timeout'] = 10800
-```
-
-Then reconfigure GitLab:
-
-```bash
-sudo gitlab-ctl reconfigure
-```
-
-This will increase the timeout to three hours (10800 seconds). Choose a time
-long enough to accomodate a full clone of your largest repositories.
+This document was moved to [another location](../administration/geo/troubleshooting.md).

doc/gitlab-geo/tuning.md

-# Tuning Geo
-
-## Changing the sync capacity values
-
-In the Geo admin page (`/admin/geo_nodes`), there are several variables that
-can be tuned to improve performance of Geo:
-
-* Repository sync capacity
-* File sync capacity
-
-Increasing these values will increase the number of jobs that are scheduled,
-but this may not lead to a more downloads in parallel unless the number of
-available Sidekiq threads is also increased. For example, if repository sync
-capacity is increased from 25 to 50, you may also want to increase the number
-of Sidekiq threads from 25 to 50. See the [Sidekiq concurrency
-documentation](../administration/operations/extra_sidekiq_processes.html#concurrency)
-for more details.
+This document was moved to [another location](../administration/geo/tuning.md).

doc/gitlab-geo/using_a_geo_server.md

-[//]: # (Please update EE::GitLab::GeoGitAccess::GEO_SERVER_DOCS_URL if this file is moved)
-
-# Using a Geo Server
-
-After you set up the [database replication and configure the Geo nodes][req],
-there are a few things to consider:
-
-1. Users need an extra step to be able to fetch code from the secondary and push
-   to primary:
-
-     1. Clone the repository as you would normally do, but from the secondary node:
-
-         ```bash
-         git clone git@secondary.gitlab.example.com:user/repo.git
-         ```
-
-     1. Change the remote push URL to always push to primary, following this example:
-
-         ```bash
-         git remote set-url --push origin git@primary.gitlab.example.com:user/repo.git
-         ```
-
-[req]: README.md#setup-instructions
+This document was moved to [another location](../administration/geo/using_a_geo_server.md).

ee/lib/ee/gitlab/geo_git_access.rb

@@ -4,7 +4,7 @@ module EE
       include ::Gitlab::ConfigHelper
       include ::EE::GitlabRoutingHelper
 
-      GEO_SERVER_DOCS_URL = 'https://docs.gitlab.com/ee/gitlab-geo/using_a_geo_server.html'.freeze
+      GEO_SERVER_DOCS_URL = 'https://docs.gitlab.com/ee/administration/geo/using_a_geo_server.html'.freeze
 
       protected