Skip to content

Use Cluster State to Track Repository Generation (#49729)#49976

Merged
original-brownbear merged 1 commit intoelastic:7.xfrom
original-brownbear:49729-7.x
Dec 9, 2019
Merged

Use Cluster State to Track Repository Generation (#49729)#49976
original-brownbear merged 1 commit intoelastic:7.xfrom
original-brownbear:49729-7.x

Conversation

@original-brownbear
Copy link
Copy Markdown
Contributor

Step on the road to #49060.

This commit adds the logic to keep track of a repository's generation
across repository operations. See changes to package level Javadoc for the concrete changes in the distributed state machine.

It updates the write side of new repository generations to be fully consistent via the cluster state. With this change, no index-N will be overwritten for the same repository ever. So eventual consistency issues around conflicting updates to the same index-N are not a possibility any longer.

With this change the read side will still use listing of repository contents instead of relying solely on the cluster state contents.
The logic for that will be introduced in #49060. This retains the ability to externally delete the contents of a repository and continue using it afterwards for the time being. In #49060 the use of listing to determine the repository generation will be removed in all cases (except for full-cluster restart) as the last step in this effort.

backport of #49729

Step on the road to #49060.

This commit adds the logic to keep track of a repository's generation
across repository operations. See changes to package level Javadoc for the concrete changes in the distributed state machine.

It updates the write side of new repository generations to be fully consistent via the cluster state. With this change, no `index-N` will be overwritten for the same repository ever. So eventual consistency issues around conflicting updates to the same `index-N` are not a possibility any longer.

With this change the read side will still use listing of repository contents instead of relying solely on the cluster state contents.
The logic for that will be introduced in #49060. This retains the ability to externally delete the contents of a repository and continue using it afterwards for the time being. In #49060 the use of listing to determine the repository generation will be removed in all cases (except for full-cluster restart) as the last step in this effort.
@original-brownbear original-brownbear added :Distributed/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs backport labels Dec 9, 2019
@elasticmachine
Copy link
Copy Markdown
Collaborator

Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore)

original-brownbear added a commit that referenced this pull request Dec 9, 2019
Disabling BwC tests so #49976 can be merged.
@original-brownbear original-brownbear merged commit ac2774c into elastic:7.x Dec 9, 2019
original-brownbear added a commit that referenced this pull request Dec 9, 2019
With #49976 merged we can reenable BwC tests.
jpountz added a commit to jpountz/elasticsearch that referenced this pull request Jan 8, 2020
jpountz added a commit that referenced this pull request Jan 8, 2020
SivagurunathanV pushed a commit to SivagurunathanV/elasticsearch that referenced this pull request Jan 23, 2020
SivagurunathanV pushed a commit to SivagurunathanV/elasticsearch that referenced this pull request Jan 23, 2020
SivagurunathanV pushed a commit to SivagurunathanV/elasticsearch that referenced this pull request Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport :Distributed/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants