-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Zero assigned two Alphas the same Raft index. #5436
Labels
area/operations
Related to operational aspects of the DB, including signals, flags, env vars, etc.
kind/bug
Something is broken.
status/accepted
We accept to investigate/work on it.
Comments
danielmai
added
kind/bug
Something is broken.
status/accepted
We accept to investigate/work on it.
area/operations
Related to operational aspects of the DB, including signals, flags, env vars, etc.
labels
May 13, 2020
I tried to reproduce it multiple time with above instructions. Also tried it with 3 node zero cluster, could not reproduce it. Had a chat with @danielmai, even he saw it only once. Looks like a rarely occurring issue. |
martinmr
added a commit
that referenced
this issue
Jun 8, 2020
Currently, zero uses the MaxRaftId to assign RAFT IDs to new nodes. However, the MaxRaftId value is not immediately updated and the lock is released in between creating the proposal and sending the proposal to the RAFT node. This can lead to situations where more than one new node is assigned the same ID. To solve this, this change introduces a new field to generate the IDs that is updated immediately, thus preventing multiple nodes from being assigned the same ID. Fixes #5436
martinmr
added a commit
that referenced
this issue
Jun 8, 2020
Currently, zero uses the MaxRaftId to assign RAFT IDs to new nodes. However, the MaxRaftId value is not immediately updated and the lock is released in between creating the proposal and sending the proposal to the RAFT node. This can lead to situations where more than one new node is assigned the same ID. To solve this, this change introduces a new field to generate the IDs that is updated immediately, thus preventing multiple nodes from being assigned the same ID. Fixes #5436
martinmr
added a commit
that referenced
this issue
Jun 8, 2020
Currently, zero uses the MaxRaftId to assign RAFT IDs to new nodes. However, the MaxRaftId value is not immediately updated and the lock is released in between creating the proposal and sending the proposal to the RAFT node. This can lead to situations where more than one new node is assigned the same ID. To solve this, this change introduces a new field to generate the IDs that is updated immediately, thus preventing multiple nodes from being assigned the same ID. Fixes #5436
This was referenced Jun 8, 2020
martinmr
added a commit
that referenced
this issue
Jun 9, 2020
Currently, zero uses the MaxRaftId to assign RAFT IDs to new nodes. However, the MaxRaftId value is not immediately updated and the lock is released in between creating the proposal and sending the proposal to the RAFT node. This can lead to situations where more than one new node is assigned the same ID. To solve this, this change introduces a new field to generate the IDs that is updated immediately, thus preventing multiple nodes from being assigned the same ID. Fixes #5436 cherry-picked from c093805
martinmr
added a commit
that referenced
this issue
Jun 9, 2020
Currently, zero uses the MaxRaftId to assign RAFT IDs to new nodes. However, the MaxRaftId value is not immediately updated and the lock is released in between creating the proposal and sending the proposal to the RAFT node. This can lead to situations where more than one new node is assigned the same ID. To solve this, this change introduces a new field to generate the IDs that is updated immediately, thus preventing multiple nodes from being assigned the same ID. Fixes #5436 cherry-picked from c093805
dna2github
pushed a commit
to dna2fork/dgraph
that referenced
this issue
Jul 18, 2020
Currently, zero uses the MaxRaftId to assign RAFT IDs to new nodes. However, the MaxRaftId value is not immediately updated and the lock is released in between creating the proposal and sending the proposal to the RAFT node. This can lead to situations where more than one new node is assigned the same ID. To solve this, this change introduces a new field to generate the IDs that is updated immediately, thus preventing multiple nodes from being assigned the same ID. Fixes hypermodeinc#5436
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/operations
Related to operational aspects of the DB, including signals, flags, env vars, etc.
kind/bug
Something is broken.
status/accepted
We accept to investigate/work on it.
What version of Dgraph are you using?
master (5890a6c)
Have you tried reproducing the issue with the latest release?
No
What is the hardware spec (RAM, OS)?
Ubuntu Linux
Steps to reproduce the issue (command/config used to run Dgraph).
Expected behaviour and actual result.
Two of the Alphas got assigned the same Raft ID:
Both Alpha 2 and Alpha 3 say "Raft Id after connection to Zero: 0x2".
When checking /state, I only see two Alpha members, where member id 2 is sometimes either Alpha when refreshing the /state page multiple times:
I expected the Alpha 1 to have Raft ID 0x1, Alpha 2 to have Raft ID 0x2, and Alpha 3 to have Raft ID 0x3.
Here are the Zero logs:
Checking the wal entries for Zero shows that both instances got assigned id 2:
I noticed this because I ran a drop all and then a data load and only two of the three Alphas showed logs when I ran the operation.
The text was updated successfully, but these errors were encountered: