Commit b215c59d authored by Stan Hu's avatar Stan Hu

Add upgrade notes for Geo in GitLab 10.0

[ci skip]
parent ad98fb1f
...@@ -71,6 +71,19 @@ internally by the secondary node to record what data has been replicated. ...@@ -71,6 +71,19 @@ internally by the secondary node to record what data has been replicated.
In the secondary nodes there is an additional daemon: Geo Log Cursor. In the secondary nodes there is an additional daemon: Geo Log Cursor.
## Geo Requirements
We highly recommend that you install Geo on an operating system that supports
OpenSSH 6.9 or higher. The following operating systems are known to ship with a
current version of OpenSSH:
* CentOS 7.4
* Ubuntu 16.04
Note that CentOS 6 and 7.0 ship with an old version of OpenSSH that do not
support a feature that Geo requires. See the [documentation on GitLab Geo SSH
access](ssh.md) for more details.
### LDAP ### LDAP
We recommend that if you use LDAP on your primary that you also set up a We recommend that if you use LDAP on your primary that you also set up a
......
...@@ -300,12 +300,25 @@ not create them manually. ...@@ -300,12 +300,25 @@ not create them manually.
### Upgrading Geo ### Upgrading Geo
To avoid having to maintain consistency of the `authorized_keys` file for SSH access, #### Upgrading to GitLab 10.0
we encourage all **Geo** users to
[switch to SSH key lookups via the database](ssh.md). Since GitLab 10.0, we require all **Geo** systems to [use SSH key lookups via
This will be necessary once Geo system hooks are removed. the database](ssh.md) to avoid having to maintain consistency of the
`authorized_keys` file for SSH access. Failing to do this will prevent users
from being able to clone via SSH.
#### Upgrading from GitLab 9.3 or older
If you started running Geo on GitLab 9.3 or older, we recommend that you
resync your secondary PostgreSQL databases to use replication slots. If you
started using Geo with GitLab 9.4 or 10.x, no further action should be
required because replication slots are used by default. However, if you
started with GitLab 9.3 and upgraded later, you should still follow the
instructions below.
When in doubt, it does not hurt to do a resync. The easiest way to do this in
Omnibus is the following:
We highly recommend using replication slots. The easiest way to do this in Omnibus is the following:
1. Install GitLab on the primary server 1. Install GitLab on the primary server
1. Run `gitlab-ctl reconfigure` and `gitlab-ctl restart postgresql`. This will enable replication slots on the primary database. 1. Run `gitlab-ctl reconfigure` and `gitlab-ctl restart postgresql`. This will enable replication slots on the primary database.
1. Install GitLab on the secondary server. 1. Install GitLab on the secondary server.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment