Note: This feature was introduced in GitSwarm 2017.1-1 EE. We recommend you use with at least GitSwarm 2017.2-1 EE.
GitLab Geo allows you to replicate your GitLab instance to other geographical locations as a read-only fully operational version.
If you have two or more teams geographically spread out, but your GitLab instance is in a single location, fetching large repositories can take a long time.
Your Geo instance can be used for cloning and fetching projects, in addition to reading any data. This will make working with large repositories over large distances much faster.
When Geo is enabled, we refer to your original instance as a primary node and the replicated read-only ones as secondaries.
Keep in mind that:
In order to set up one or more GitLab Geo instances, follow the steps below in this exact order:
primary <-> secondary (read-only)topology)
After you set up the database replication and configure the GitLab Geo nodes, there are a few things to consider:
You need an extra step to be able to fetch code from the
secondary and push to
Change the remote push URL following this example:
bash git remote set-url --push origin [email protected]:user/repo.git
Important: The initialization of a new Geo secondary node on versions older than GitSwarm 2017.2-1 requires data to be copied from the primary, as there is no backfill feature bundled with those versions. See more details in the Configure GitLab step.
There are limitations to what we replicate (see What data is replicated to a secondary node?). In an extreme data-loss situation you can make a secondary Geo into your primary, but this is not officially supported yet.
If you still want to proceed, see our step-by-step instructions on how to manually promote a secondary node into primary.
We currently replicate project repositories 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 user generated attachments / avatars or any other file in
public/upload. We also don't replicate LFS / Annex or artifacts data (
No. All writing operations (this includes
git push) must be done in your primary node.
All replication operations are asynchronous and are queued to be dispatched in a batched request every 10 seconds. 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.
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.