ID | IEP-45 | ||||||||
Author | |||||||||
Sponsor | |||||||||
Created |
| ||||||||
Status |
|
Table of Contents |
---|
// Define the problem to be solved.
The main goal is to have a cache operation's latency less than 500 ms on node fail/left.
Currently, latency can be increased to seconds or even dozens of seconds.
The task can be split into the following threads:
The Switch is a process that allows performing cluster-wide operations that lead to a new cluster state (eg. cache creation/destroy, node join/left/fail, snapshot creation/restore, etc).
Historically, Switch performs PME (Partition Map Exchange) even in case partition distribution was_not/will_not_be changed.
It's possible to avoid PME on node left if partition distribution is fixed (eg. baseline node left on a fully rebalanced cluster).
This optimization will allow us to continue operations (not affected by primary node failure) during or after the switch.
In case nodes combined into virtual cells where, for each partition, backups located at the same cell with primaries, it's possible to finish the Switch outside the affected cell before tx recovery finish.
This optimization will allow us to start and even finish new operations without waiting for cluster-wide Switch finish.
Code should be analyzed for useless sleeps, recovery start priority, possible code optimizations, etc.
Already found that some constants used at failure detection are hardcoded and large.
Also, code responsible for this feature performs a lot of re-checks and re-waits and you may have detection time close to failureDetectionTimeout x2 or even x3.
Another problem is GC, and it may increase failure detection dramatically, so, watchdog started from another JVM or from native code can help here.
Ring-based topology does not allow to perform the fast switch.
Zookeeper or similar coordinator should be used// Provide the design of the solution.
// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.
...
// Links to various reference documents, if applicable.
Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|