Skip to content
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

Zen2 ClusterState storage #33958

Closed
6 tasks done
andrershov opened this issue Sep 21, 2018 · 0 comments
Closed
6 tasks done

Zen2 ClusterState storage #33958

andrershov opened this issue Sep 21, 2018 · 0 comments
Labels
:Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. >feature Meta

Comments

@andrershov
Copy link
Contributor

andrershov commented Sep 21, 2018

In Zen, ClusterState is stored through GatewayMetaState. There are the following issues with the current approach:

  1. Since GatewayMetaState implements ClusterStateApplier, if there was an IOException during storing the state, ClusterState change still will be applied to in-memory node state.
  2. GatewayMetaState stores global metadata and index metadata for each index in separate files. See MetaDataStateFormatter. MetaDataStateFormatter ensures that global/index metadata is stored atomically. However, if there is a change to the global metadata and index metadata or metadata of several indices, state update could be partial.

Zen2 needs a reliable mechanism to store ClusterState without these drawbacks. Two alternative approaches were discussed:

  1. Instead of storing metadata in separate files, create translog for ClusterState diffs. Once ClusterState.Diff is received, persist it to the translog. There could be a background merging process that merges multiple ClusterState diffs together.
  2. Enhance existing solution, by adding the manifest file that will contain pointers to global state/index metadata files and will ensure atomicity.
    While the 1st approach is preferable in the long run, for now, we decided to go with the 2nd approach.

Below is the list of things that should be done:

Although points 1-3 are relevant for Zen, it's decided to make changes on Zen2 branch.

Relates to #32006

@andrershov andrershov added >feature :Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. labels Sep 21, 2018
ywelsch added a commit that referenced this issue Nov 19, 2018
Zen2 is now feature-complete enough to run most ESIntegTestCase tests. The changes in this PR
are as follows:
- ClusterSettingsIT is adapted to not be Zen1 specific anymore (it was using Zen1 settings).
- Some of the integration tests require persistent storage of the cluster state, which is not fully
implemented yet (see #33958). These tests keep running with Zen1 for now but will be switched
over as soon as that is fully implemented.
- Some very few integration tests are not running yet with Zen2 for other reasons, depending on
some of the other open points in #32006.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. >feature Meta
Projects
None yet
Development

No branches or pull requests

1 participant