Supported Geo data types

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 distinguish between the following different data types:

• Git repositories
• Container repositories
• Blobs
• Databases

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

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.
• With multiple disks mounted as a single mount-point (like with a RAID array).
• Using LVM.

GitLab does not require a special file system and can work with a mounted Storage Appliance. However, there can be performance limitations and consistency issues when using a remote file system.

Geo triggers garbage collection in Gitaly to deduplicate forked repositories on Geo secondary sites.

The Gitaly gRPC API does the communication, with three possible ways of synchronization:

• Using regular Git clone/fetch from one Geo site to another (with special authentication).
• Using repository snapshots (for when the first method fails or the repository is corrupt).
• Manual trigger from the Admin area (combines the other listed possible ways).

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.

Besides that, there are snippet repositories. They can be connected to a project or to some specific user. Both types are synced to a secondary site.

Container repositories

Container repositories are stored in the container registry. They are a GitLab-specific concept built on top of a container registry as the datastore.

Blobs

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

• The file system in a specific location.
• An Object Storage solution. Object Storage solutions can be:
  • Cloud based like Amazon S3 and Google Cloud Storage.
  • Self-hosted S3-compatible object storage.
  • A Storage Appliance that exposes an Object Storage-compatible API.

When using the file system store instead of Object Storage, use network mounted file systems to run GitLab when using more than one node.

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.

Databases

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 and cached merge request diffs. 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 sites.

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

Elasticsearch is an optional database for advanced search. It can improve search in both source-code level, and user generated content in issues, merge requests, and discussions. Elasticsearch is not supported in Geo.

Replicated data types

Replication for some data types is released behind feature flags that are enabled by default. These feature flags can’t be enabled or disabled per-project, and they’re recommended for production use. GitLab administrators with access to the GitLab Rails console can opt to disable them for your instance. You can find feature flag names of each of those data types in the notes column of the table below.

Enable or disable replication (for some data types)

To disable, such as for package file replication:

Feature.disable(:geo_package_file_replication)

To enable, such as for package file replication:

Feature.enable(:geo_package_file_replication)

Disabling a geo_<replicable>_replication flag stops replication and verification on secondary sites. On the primary site, checksumming continues while the corresponding geo_<replicable>_force_primary_checksumming flag is enabled (the default). To stop checksumming on the primary site as well, disable both flags:

Feature.disable(:geo_package_file_replication)
Feature.disable(:geo_package_file_force_primary_checksumming)