tursom/memgraph
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix advanced part in replication feature spec (#75)

Browse Source 
Co-authored-by: jseljan <josip.seljan@memgraph.io>
This commit is contained in:
Josip Seljan 2021-01-12 19:07:21 +01:00 committed by Antonio Andelic
parent 8fc9298832
commit b19cd4f5d1
1 changed files with 36 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
docs/feature_spec/replication.md
View File

@ -122,21 +122,6 @@ assumed to be the default one (we specify it to be 10000).
Each Memgraph instance will remember what the configuration was set to and will
automatically resume with its role when restarted.
### How to Setup an Advanced Replication Scenario?
The configuration allows for a more advanced scenario like this:
```plaintext
main -[asynchronous]-> replica 1 -[semi-synchronous]-> replica 2
```
To configure the above scenario, issue the following commands:
```plaintext
SET REPLICATION ROLE TO REPLICA; # on replica 1
SET REPLICATION ROLE TO REPLICA; # on replica 2
REGISTER REPLICA replica1 ASYNC TO <replica1_sa>; # on main
REGISTER REPLICA replica2 SYNC WITH TIMEOUT 0.5 TO <replica2_sa>; # on replica 1
```
### How to See the Current Replication Status?
@ -157,7 +142,7 @@ SHOW REPLICAS;
To delete a replica, issue the following query:
```plaintext
DELETE REPLICA 'name';
DROP REPLICA 'name';
```
### How to Promote a New Main?
@ -174,6 +159,41 @@ able to replicate its data to the replica (the new main) anymore and will enter
an error state. You must ensure that at any given point in time there aren't
two mains in the cluster.
## Limitations and Potential Features
Currently, we do not support chained replicas, i.e. a replica can't have its
own replica. When this feature becomes available, the user will be able to
configure scenarios such as the following one:
```plaintext
main -[asynchronous]-> replica 1 -[semi-synchronous]-> replica 2
```
To configure the above scenario, the user will be able to issue the following
commands:
```plaintext
SET REPLICATION ROLE TO REPLICA WITH PORT <port1>; # on replica 1
SET REPLICATION ROLE TO REPLICA WITH PORT <port2>; # on replica 2
REGISTER REPLICA replica1 ASYNC TO "replica1_ip_address:port1"; # on main
REGISTER REPLICA replica2 SYNC WITH TIMEOUT 0.5
TO "replica2_ip_address:port2"; # on replica 1
```
In addition, we do not yet support advanced recovery mechanisms. For example,
if a main crashes, a suitable replica will take its place as the new main. If
the crashed main goes back online, it will not be able to reclaim its previous
role, but will be forced to be a replica of the new main.
In the upcoming releases, we might be adding more advanced recovery mechanisms.
However, users are able to setup their own recovery policies using the basic
recovery mechanisms we currently provide, that can cover a wide range of
real-life scenarios.
Also, we do not yet support the replication of authentication configurations,
rendering access control replication unavailable.
The query and authentication modules, as well as audit logs are not replicated.
## Integration with Memgraph
WAL `Delta`s are replicated between the replication main and replica. With