-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replicated data is not synced to disk #10
Comments
Thanks for the very detailed steps to reproduce. I'll make sure this is fixed and that we have a regression test for it before the |
Just to check though, considering my comment here: #11 (comment) Have you confirmed that setting up one-directional I haven't read through the entire steps to reproduce in this ticket yet, but having only uni-directional links between nodes could potentially explain some issues with partition tolerance I can check this myself a bit later if I haven't heard back from you by then. |
Yes, the links are bidirectional. Adding the links in both directions results in an error: |
I noticed something else as well: The replicated data is being stored on disk after replication and there is a |
When using disk persistence and intentionally causing a partition split, I noticed that data written on one side of the split is not synced to disk on the nodes on the other side of the split after the partition has been repaired and replication has completed. This could cause problems if the nodes on one side of a split are restarted during the split, as they would lose the data they had replicated from the other side of the partition. I have set up an example to reproduce the issue.
Steps To Reproduce
docker-compose.yaml
to a directory:data1
anddata2
to hold the disk persistance data. We'll leavedb3
as in-memory only.Run
docker-compose up -d
to start the cluster.Run
docker-compose run cli1
to connect a CLI todb1
. Note: It helps to open the CLIs in separate terminals.Run the command
MVREG SET foo 1
.Run
docker-compose run cli2
to connect a CLI todb2
.Run the command
MVREG GET foo
, which should return1) "1"
.Comment out all of the
links
and--seed-addrs
fordb2
in the yaml to separate the node from the cluster.Shut down the cluster with
docker-compose down
.Bring the cluster back up with
docker-compose up -d
On
cli1
runMVREG GET foo
. The result is1) "1"
.On
cli2
runMVREG GET foo
. The result is(empty list or set)
, but should be"1"
.The data written to
db1
was not persisted todb2
's diskOn
cli2
runMVREG SET foo 2
.Uncomment the yaml for
db2
so that the node will rejoin the cluster.Shut down the cluster with
docker-compose down
.Bring the cluster back up with
docker-compose up -d
On
cli2
runMVREG GET foo
. This will return1) "2" 2) "1"
.On
cli2
runMVREG SET foo 3
.On
cli1
runMVREG GET foo
. This will return"3"
.Current state: Value
"1"
is persisted to disk ondb1
and"3"
is on disk ondb2
. They both have a value of"3"
in memory.Comment out the
links
and--seed-addrs
fordb2
again.Shut down the cluster with
docker-compose down
.Bring the cluster back up with
docker-compose up -d
On
cli1
runMVREG GET foo
. This will return1) "1"
.On
cli2
runMVREG GET foo
. This will return1) "3"
.This shows that the values synced in the replication process have not been persisted to disk.
The text was updated successfully, but these errors were encountered: