-
Notifications
You must be signed in to change notification settings - Fork 46
What's new for release 3.6 #5538
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
base: latest
Are you sure you want to change the base?
Conversation
sergepetrenko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarifications in the 2DC synchro section!
Please find a couple more comments below.
doc/release/3.6.0.rst
Outdated
|
|
||
| However, there are some limitations. | ||
| An important thing is that while data storages can be located in just 2 DCs, | ||
| the configuration storage (based on etcd or Tarantool) must be located in yet another DC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I can parse this sentence correctly. Does it mean configuration storage has to be located in 3 datacenters or just in another DC, separate from the 2 used for storing data?
AFAIU, we should set up configuration storage in 3 DCs, the easiest way to do so is by using 2 existing "data" DCs + 1 extra "quorum" DC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, I deduced this from Alex Klenov's feedback: "Чтобы всё устойчиво работало, нужно чтобы хранилище конфигурации располагалось на трёх площадках. То есть данные мы храним в двух ЦОДах. Но при этом у нас есть третяя площадка для принятия решений."
So, I've guessed it wrong that we need only 1 configuration storage here -- the one located in DC #3.
Re-iterated it with Alex. Indeed, we need 3 config storages. Thanks for spotting!
| to 1. The cluster keeps serving the clients. | ||
| b. DC #1 goes up and starts obtaining missed data from DC #2. The quorum size is still 1. | ||
| c. The data enrichment process for DC #1 is still in progress, but DC #2 goes down now. | ||
| In this case, the cluster becomes unavailable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about case 1, let's ask @georgiy-belyanin for clarifications. Is this really what's going to happen?
No description provided.