diff options
| author | Jacob Vosmaer <jacob@gitlab.com> | 2019-02-22 19:34:45 +0300 |
|---|---|---|
| committer | Jacob Vosmaer <jacob@gitlab.com> | 2019-02-22 19:34:45 +0300 |
| commit | c2985e16dc51fe7c4b2ec4bbc3688b131a6341bc (patch) | |
| tree | 9703a8b362ffd040d2b5ef3e8eb176b772ca89d6 | |
| parent | b8ada6528dc71071e13a6539c222a0dff73e2785 (diff) | |
| parent | d2cc579d3da57a3008b91f2087214e6555f71a5c (diff) | |
Merge branch 'zj-define-praefect-alpha' into 'master'
Define Praefect Beta
See merge request gitlab-org/gitaly!1080
| -rw-r--r-- | doc/design_ha.md | 21 |
1 files changed, 20 insertions, 1 deletions
diff --git a/doc/design_ha.md b/doc/design_ha.md index da3210ecb..e446dc85e 100644 --- a/doc/design_ha.md +++ b/doc/design_ha.md @@ -1,7 +1,8 @@ # Gitaly High Availability (HA) Design Gitaly HA is an active-active cluster configuration for resilient git operations. [Refer to our specific requirements](https://gitlab.com/gitlab-org/gitaly/issues/1332). -Refer to epic &289 for current issues and discussions revolving around HA MVC development. +Refer to [epic &289][epic] for current issues and discussions revolving around +HA MVC development. ## Terminology The following terminology may be used within the context of the Gitaly HA project: @@ -92,6 +93,22 @@ sequenceDiagram *Note: Once Node-A propagates changes to a peer, Node-A is no longer the critical path for subsequent propagations. If Node-A fails after a second peer is propagated, that second peer can become the new leader and resume replications.* +## Stages until v1.0 + +Rome wasn't built in a day, nor will Praefect be build in one. To iterate towards +a true HA system some properties will not be met until v1.0. Before that +milestone, an beta stage will worked towards. + +The beta stage will consist of only a few required building blocks to iterate +on towards the envisioned HA system. The first of those building blocks is +creating and maintaining repository replica's. By maintaining a replica, there's +no requirement for the replica to be up to date right after each mutation on the +repository. Detecting that a repository is mutated, and bringing replicas up to +date in a consistent matter is the primary goal. Implicit in this goal is a way +to perform leader election. + +When the beta nears completion further stages will be defined. + ## Notes * Existing discussions * Requirements: https://gitlab.com/gitlab-org/gitaly/issues/1332 @@ -133,3 +150,5 @@ sequenceDiagram * While Git is distributed in nature, some write operations need to be serialized to avoid race conditions. This includes ref updates. * How do we coordinate proxies when applying ref updates? Do we need to? + +[epic]: https://gitlab.com/groups/gitlab-org/-/epics/289 |