Geo data types support

A Geo data type is a specific class of data that is required by one or more GitLab features to store relevant information.

To replicate data produced by these features with Geo, we use several strategies to access, transfer, and verify them.

Data types

We currently distinguish between three different data types:

See the list below of each feature or component we replicate, its corresponding data type, replication, and verification methods:

TypeFeature / componentReplication methodVerification method
DatabaseApplication data in PostgreSQLNativeNative
DatabaseRedisN/A (1)N/A
DatabaseElasticsearchNativeNative
DatabasePersonal snippetsPostgreSQL ReplicationPostgreSQL Replication
DatabaseProject snippetsPostgreSQL ReplicationPostgreSQL Replication
DatabaseSSH public keysPostgreSQL ReplicationPostgreSQL Replication
GitProject repositoryGeo with GitalyGitaly Checksum
GitProject wiki repositoryGeo with GitalyGitaly Checksum
GitProject designs repositoryGeo with GitalyGitaly Checksum
GitObject pools for forked project deduplicationGeo with GitalyNot implemented
BlobsUser uploads (filesystem)Geo with APINot implemented
BlobsUser uploads (object storage)Geo with API/Managed (2)Not implemented
BlobsLFS objects (filesystem)Geo with APINot implemented
BlobsLFS objects (object storage)Geo with API/Managed (2)Not implemented
BlobsCI job artifacts (filesystem)Geo with APINot implemented
BlobsCI job artifacts (object storage)Geo with API/Managed (2)Not implemented
BlobsArchived CI build traces (filesystem)Geo with APINot implemented
BlobsArchived CI build traces (object storage)Geo with API/Managed (2)Not implemented
BlobsContainer registry (filesystem)Geo with API/Docker APINot implemented
BlobsContainer registry (object storage)Geo with API/Managed/Docker API (2)Not implemented
  • (1): Redis replication can be used as part of HA with Redis sentinel. It’s not used between Geo nodes.
  • (2): Object storage replication can be performed by Geo or by your object storage provider/appliance native replication feature.

Git repositories

A GitLab instance can have one or more repository shards. Each shard has a Gitaly instance that is responsible for allowing access and operations on the locally stored Git repositories. It can run on a machine with a single disk, multiple disks mounted as a single mount-point (like with a RAID array), or using LVM.

It requires no special filesystem and can work with NFS or a mounted Storage Appliance (there may be performance limitations when using a remote filesystem).

Communication is done via Gitaly’s own gRPC API. There are three possible ways of synchronization:

  • Using regular Git clone/fetch from one Geo node to another (with special authentication).
  • Using repository snapshots (for when the first method fails or repository is corrupt).
  • Manual trigger from the Admin UI (a combination of both of the above).

Each project can have at most 3 different repositories:

  • A project repository, where the source code is stored.
  • A wiki repository, where the wiki content is stored.
  • A design repository, where design artifacts are indexed (assets are actually in LFS).

They all live in the same shard and share the same base name with a -wiki and -design suffix for Wiki and Design Repository cases.

Blobs

GitLab stores files and blobs such as Issue attachments or LFS objects into either:

  • The filesystem in a specific location.
  • An Object Storage solution. Object Storage solutions can be:
    • Cloud based like Amazon S3 Google Cloud Storage.
    • Hosted by you (like MinIO).
    • A Storage Appliance that exposes an Object Storage-compatible API.

When using the filesystem store instead of Object Storage, you need to use network mounted filesystems to run GitLab when using more than one server (for example with a High Availability setup).

With respect to replication and verification:

  • We transfer files and blobs using an internal API request.
  • With Object Storage, you can either:
    • Use a cloud provider replication functionality.
    • Have GitLab replicate it for you.

Database

GitLab relies on data stored in multiple databases, for different use-cases. PostgreSQL is the single point of truth for user-generated content in the Web interface, like issues content, comments as well as permissions and credentials.

PostgreSQL can also hold some level of cached data like HTML rendered Markdown, cached merge-requests diff (this can also be configured to be offloaded to object storage).

We use PostgreSQL’s own replication functionality to replicate data from the primary to secondary nodes.

We use Redis both as a cache store and to hold persistent data for our background jobs system. Because both use-cases has data that are exclusive to the same Geo node, we don’t replicate it between nodes.

Elasticsearch is an optional database, that can enable advanced searching capabilities, like improved Global Search in both source-code level and user generated content in Issues / Merge-Requests and discussions. Currently it’s not supported in Geo.

Limitations on replication/verification

The following table lists the GitLab features along with their replication and verification status on a secondary node.

You can keep track of the progress to implement the missing items in these epics/issues:

DANGER Features not on this list, or with No in the Replicated column, are not replicated on the secondary node. Failing over without manually replicating data from those features will cause the data to be lost. If you wish to use those features on a secondary node, or to execute a failover successfully, you must replicate their data using some other means.
FeatureReplicatedVerifiedNotes
Application data in PostgreSQLYesYes 
Project repositoryYesYes 
Project wiki repositoryYesYes 
Project designs repositoryYesNo 
UploadsYesNoVerified only on transfer, or manually (1)
LFS objectsYesNoVerified only on transfer, or manually (1). Unavailable for new LFS objects in 11.11.x and 12.0.x (2).
CI job artifacts (other than traces)YesNoVerified only manually (1)
Archived tracesYesNoVerified only on transfer, or manually (1)
Personal snippetsYesYes 
Project snippetsYesYes 
Object pools for forked project deduplicationYesNo 
Server-side Git HooksNoNo 
Elasticsearch integrationNoNo 
GitLab PagesNoNo 
Container RegistryYesNo 
NPM RegistryNoNo 
Maven RepositoryNoNo 
Conan RepositoryNoNo 
NuGet RepositoryNoNo 
External merge request diffsNoNo 
Content in object storageYesNo