2023-05-27 22:25:52 +05:30
|
|
|
---
|
|
|
|
|
stage: enablement
|
|
|
|
|
group: Tenant Scale
|
|
|
|
|
description: 'Cells: Backups'
|
|
|
|
|
---
|
|
|
|
|
|
2023-06-20 00:43:36 +05:30
|
|
|
<!-- vale gitlab.FutureTense = NO -->
|
|
|
|
|
|
2023-05-27 22:25:52 +05:30
|
|
|
This document is a work-in-progress and represents a very early state of the
|
|
|
|
|
Cells design. Significant aspects are not documented, though we expect to add
|
|
|
|
|
them in the future. This is one possible architecture for Cells, and we intend to
|
|
|
|
|
contrast this with alternatives before deciding which approach to implement.
|
|
|
|
|
This documentation will be kept even if we decide not to implement this so that
|
|
|
|
|
we can document the reasons for not choosing this approach.
|
|
|
|
|
|
|
|
|
|
# Cells: Backups
|
|
|
|
|
|
|
|
|
|
Each cells will take its own backups, and consequently have its own isolated
|
|
|
|
|
backup / restore procedure.
|
|
|
|
|
|
|
|
|
|
## 1. Definition
|
|
|
|
|
|
|
|
|
|
GitLab Backup takes a backup of the PostgreSQL database used by the application,
|
|
|
|
|
and also Git repository data.
|
|
|
|
|
|
|
|
|
|
## 2. Data flow
|
|
|
|
|
|
|
|
|
|
Each cell has a number of application databases to back up (e.g. `main`, and `ci`).
|
|
|
|
|
|
|
|
|
|
Additionally, there may be cluster-wide metadata tables (e.g. `users` table)
|
|
|
|
|
which is directly accesible via PostgreSQL.
|
|
|
|
|
|
|
|
|
|
## 3. Proposal
|
|
|
|
|
|
|
|
|
|
### 3.1. Cluster-wide metadata
|
|
|
|
|
|
|
|
|
|
It is currently unknown how cluster-wide metadata tables will be accessible. We
|
|
|
|
|
may choose to have cluster-wide metadata tables backed up separately, or have
|
|
|
|
|
each cell back up its copy of cluster-wide metdata tables.
|
|
|
|
|
|
|
|
|
|
### 3.2 Consistency
|
|
|
|
|
|
|
|
|
|
#### 3.2.1 Take backups independently
|
|
|
|
|
|
|
|
|
|
As each cell will communicate with each other via API, and there will be no joins
|
|
|
|
|
to the users table, it should be acceptable for each cell to take a backup
|
|
|
|
|
independently of each other.
|
|
|
|
|
|
|
|
|
|
#### 3.2.2 Enforce snapshots
|
|
|
|
|
|
|
|
|
|
We can require that each cell take a snapshot for the PostgreSQL databases at
|
|
|
|
|
around the same time to allow for a consistent-enough backup.
|
|
|
|
|
|
|
|
|
|
## 4. Evaluation
|
|
|
|
|
|
|
|
|
|
As the number of cells increases, it will likely not be feasible to take a
|
|
|
|
|
snapshot at the same time for all cells. Hence taking backups independently is
|
|
|
|
|
the better option.
|
|
|
|
|
|
|
|
|
|
## 4.1. Pros
|
|
|
|
|
|
|
|
|
|
## 4.2. Cons
|
