-
Notifications
You must be signed in to change notification settings - Fork 89
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
Fix riak dynamic join leave #410
Conversation
Adding/Deleting monitoring:
|
Handoff and leave is a cool feature, but it interferes with the Cure protocol (which assumes a fixed one-to-one mapping of nodes on different DCs). @preguica @marc-shapiro @shamouda Opinions? Should we try to fix the protocol accordingly? How does this relate to partial replication? |
On Mon, Dec 9, 2019 at 8:07 AM Annette Bieniusa ***@***.***> wrote:
Handoff and leave is a cool feature, but it interferes with the Cure
protocol (which assumes a fixed one-to-one mapping of nodes on different
DCs).
You are talking about hadoff and leaving inside a DC?
… @preguica <https://github.com/preguica> @marc-shapiro
<https://github.com/marc-shapiro> @shamouda <https://github.com/shamouda>
Opinions? Should we try to fix the protocol accordingly? How does this
relate to partial replication?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#410?email_source=notifications&email_token=ACLFD4U5MG7C6U5A44ASKPDQXX4CPA5CNFSM4JWZJHMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGIHCCQ#issuecomment-563114250>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACLFD4RFWVHZWEGQDZK5ANTQXX4CPANCNFSM4JWZJHMA>
.
|
Yes, it is about dynamicity of nodes within a DC. |
Currently, to add a node dynamically to not break
Once handoff is implemented correctly, step 4 can be skipped. I'm not sure if 1. and 6. is needed, but added it just in case. An easier approach would be to design Inter-DC communication in such a way that each DC does not know the internal ring structure of another DC. Then changing the structure and replication inside a DC would not affect another DC, reducing complexity of the problem. |
…og messages for ring changes
…umented handoff better
7bd813f
to
233fc2c
Compare
Le 9 déc. 2019 à 14h18, Albert Schimpf ***@***.***> a écrit :
[…] An easier approach would be to design Inter-DC communication in such a way that each DC does not know the internal ring structure of another DC. Then changing the structure and replication inside a DC would not affect another DC, reducing complexity of the problem.
Not easily done.
Long-term, I would suggest the following approach. All DCs are configured with the same relatively high number of logical shards (2048?). We keep the logical relation of one logical log per shard and one logical FIFO inter-DC connection between corresponding shards.
Physically, multiple shards are assigned to some server — this can be different in each DC. However all the shards on the same server share physical resources, e.g., all its logical logs are coalesced to a single physical log. Similarly, redundant inter-DC channels are coalesced.
It’s still possible to move logical shards between physical servers, by de-coalescing and re-coalescing accordingly.
Marc
|
The discussion for that is best left for another issue or meeting, this PR doesn't address the issues of proper join leave mechanics and replication. |
Will merge this once the |
riak_core
side of things.materializer_vnode
handoff
lifecycle can hang indefinitely because the timeout of riak calls isinfinity