-
Notifications
You must be signed in to change notification settings - Fork 24.6k
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
Wait for mapping updates during local recovery #6666
Conversation
when the primary shard is recovering its translog, make sure to wait for new mapping introductions till the mappings have been updated on the master before finalizing the recovery itself also, this change performs the mapping updates in a more optimized manner by batching the types to change into a single set and sending after the translog has been replayed closes elastic#6666
} | ||
} | ||
} | ||
} |
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.
Can these classes be static?
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.
they can't at their current placement, because they are in non static inner class. they can be moved to outside, and be made static, but then, at least for the value class, we will need to pass the logger as well. I like it like this, feels more encapsulated, and the perf overhead of non static classes should be insignificant in the context of this operation (mapping updates)
Just left a question. Otherwise it looks good to me but I'm not familiar with this code so I might have missed obvious bugs. |
LGTM... would be nice to have the option for |
@uboness yea, that would be nice, but it would be a bigger change, will push this for now |
sure |
when the primary shard is recovering its translog, make sure to wait for new mapping introductions till the mappings have been updated on the master before finalizing the recovery itself also, this change performs the mapping updates in a more optimized manner by batching the types to change into a single set and sending after the translog has been replayed also, remove the wait for mapping on master in the local state tests since this new behavior covers it closes #6666 remove waiting for mapping on master since we do it in recovery
when the primary shard is recovering its translog, make sure to wait for new mapping introductions till the mappings have been updated on the master before finalizing the recovery itself
also, this change performs the mapping updates in a more optimized manner by batching the types to change into a single set and sending after the translog has been replayed