Geo and Disaster Recovery

On this page

The Geo Team

Geo is a Premium feature, built to help speed up the development of distributed teams by providing one or more read-only mirrors of a primary GitLab instance. This mirror (a Geo secondary node) reduces the time to clone or fetch large repositories and projects, can be used to run automated tests, or can be part of a Disaster Recovery solution.

Goals and Priorities

The goal of the Geo Team is to provide an easily configurable read-only mirror of a GitLab installation that is complete, accurate, verifiable and efficient.

In the longer term, our goal is to be able to promote any secondary node to a primary node state to support a Disaster Recovery situation.

We are also considering what a read-write mirror would involve and where this would fit on our roadmap.

To that end, our priorities are:

  1. Hashed Storage GA, alleviating challenges from the legacy storage solution.
  2. To deploy Geo in another GCP region, providing gitlab.com with resilience. (This also promotes our value of collaboration through dogfooding.)
  3. Reduce the effort required to install, configure and maintain Geo secondary nodes.
  4. Clear up any bugs concerning the accuracy of the replicated data, or the reporting on the state of a secondary node.
  5. Ensure that Geo runs efficiently.

Geo's Relationship to Disaster Recovery

Disaster Recovery (DR) is a set of policies, tools and procedures put in place to be able to recover from a disaster.

Geo provides data redundancy. The customer will have a redundant copy of data in a separate location. If anything were to happen to their primary instance, a secondary instance still retains a copy of the data.

However, data redundancy is one part of a complete DR strategy.

High Availability (HA) is also a step towards Disaster Recovery. At the moment Geo does not provide true HA because if the primary instance is not available, certain actions are not possible.

Documentation

Other Resources

Geo Terminology

Term Definition
Geo The product name given to the feature that provides the ability to create one or more read-only mirrors for the main/primary instance
Primary The main, primary instance where read-write operations are allowed
Secondary An instance that synchronizes with the Primary node where only read-only operations are permitted

Planning and Demos

Discussions

Discussions are documented separately.

Planning

We use issue boards to focus on each milestone and a planning board to look further ahead.

Here you can find the Epics for Geo.

We start planning the new milestone around the 15th of each month. During this week we open up the new board and start adding issues.

This link is pasted into our Slack channel and the team start to review the issues added. This way we can prevent starting a milestone with blocked issues.

In the week before the cut-off, the board for the new milestone is finalized. Issues that are not ready for the milestone are removed, and remaining issues are prioritized.

Demos

The demos are recorded and should be stored in Google Drive under "GitLab Videos –> Geo Demos". If you recorded the demo, please make sure the recording ends up in that folder.