Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/architecture/blueprints/cells/cells-feature-backups.md')
-rw-r--r--doc/architecture/blueprints/cells/cells-feature-backups.md62
1 files changed, 62 insertions, 0 deletions
diff --git a/doc/architecture/blueprints/cells/cells-feature-backups.md b/doc/architecture/blueprints/cells/cells-feature-backups.md
new file mode 100644
index 00000000000..d596bdd2078
--- /dev/null
+++ b/doc/architecture/blueprints/cells/cells-feature-backups.md
@@ -0,0 +1,62 @@
+---
+stage: enablement
+group: Tenant Scale
+description: 'Cells: Backups'
+---
+
+<!-- vale gitlab.FutureTense = NO -->
+
+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