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

During relocation, process pending mapping update in phase 2 #6762

Closed
wants to merge 3 commits into from

Conversation

bleskes
Copy link
Contributor

@bleskes bleskes commented Jul 7, 2014

During phase1 we copy over all lucene segments. These make refer to mapping updates that are still queued up to be sent to master. We must make sure those pending updates are sent before completing the relocation.

Relates to #6648

During phase1 we copy over all lucene segments. These make refer to mapping updates that are still queued up to be sent to master. We must make sure those pending updates are sent before completing the relocation.

Relates to elastic#6648
@kimchy
Copy link
Member

kimchy commented Jul 7, 2014

I think that there is a cleaner way to do it, by simply sending an update mapping per type, with a listener, and waiting for the response. This will guarantee that all the mappings have been properly processed by the master node.

@bleskes
Copy link
Contributor Author

bleskes commented Jul 7, 2014

@kimchy pushed another commit based on your suggestion

@@ -251,22 +258,55 @@ public void phase2(Translog.Snapshot snapshot) throws ElasticsearchException {
if (shard.state() == IndexShardState.CLOSED) {
throw new IndexShardClosedException(request.shardId());
}
logger.trace("[{}][{}] recovery [phase2] to {}: start", request.shardId().index().name(), request.shardId().id(), request.targetNode());
logger.trace("{} recovery [phase2] to {}: start", request.shardId().index().name(), request.shardId().id(), request.targetNode());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the change to the logging? now we don't properly log the parameters?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you forgot to change it to request.shardId as a single parameter, instead of the index name and shard id both

@kimchy
Copy link
Member

kimchy commented Jul 7, 2014

left minor comment, LGTM otherwise

@bleskes bleskes closed this in 7f5f4e8 Jul 7, 2014
@bleskes bleskes removed the review label Jul 7, 2014
bleskes added a commit that referenced this pull request Jul 7, 2014
During phase1 we copy over all lucene segments. These may refer to mapping updates that are still queued up to be sent to master. We must make sure those pending updates are processed before completing the relocation.

Relates to #6648

Closes #6762
clintongormley added a commit that referenced this pull request Jul 7, 2014
Delete and update mapping execution order has changed with #6762
clintongormley added a commit that referenced this pull request Jul 7, 2014
Delete and update mapping execution order has changed with #6762
bleskes added a commit to bleskes/elasticsearch that referenced this pull request Jul 7, 2014
The change added in elastic#6762 helps making sure the pending mapping updates are processed on all nodes to prevent moving shards to nodes which are not yet fully aware of the new mapping. However it introduced a racing condition delete_mapping operations, potentially causing a type to be added after it's deletion. This commit solves this by only sending a mapping update if the mapping source has actually changed.
bleskes added a commit that referenced this pull request Jul 7, 2014
The change added in #6762 helps making sure the pending mapping updates are processed on all nodes to prevent moving shards to nodes which are not yet fully aware of the new mapping. However it introduced a racing condition delete_mapping operations, potentially causing a type to be added after it's deletion. This commit solves this by only sending a mapping update if the mapping source has actually changed.

Closes #6772
bleskes added a commit that referenced this pull request Jul 7, 2014
The change added in #6762 helps making sure the pending mapping updates are processed on all nodes to prevent moving shards to nodes which are not yet fully aware of the new mapping. However it introduced a racing condition delete_mapping operations, potentially causing a type to be added after it's deletion. This commit solves this by only sending a mapping update if the mapping source has actually changed.

Closes #6772
@clintongormley clintongormley changed the title [Relocation] process pending mapping update in phase 2 Resiliency: During relocation, process pending mapping update in phase 2 Jul 16, 2014
@clintongormley clintongormley changed the title Resiliency: During relocation, process pending mapping update in phase 2 During relocation, process pending mapping update in phase 2 Jun 7, 2015
@clintongormley clintongormley added :Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. and removed :Cluster labels Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. >enhancement resiliency v1.3.0 v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants