Tags: jguay/elasticsearch
Tags
Fail shard marked as relocating but missing in-memory index structures ( elastic#24061) When a shard is marked as relocating in the cluster state but the node that is to be expected to have the shard does not have the corresponding in-memory index structures loaded, then the node does not notify the master of this inconsistency. The cluster can end up in this situation for example when using discovery.zen.no_master_block: all, which makes the data nodes unload in-memory index structures when no master is available. As a result, all indexing / search activity to the supposedly relocating shard will fail, requiring manual intervention from an operator to fix the issue by restarting the data node with the relocating shard.
Always restore the ThreadContext for operations delayed due to a block ( elastic#23349) The IndexShardOperationsLock has a mechanism to delay operations if there is currently a block on the lock. These delayed operations are executed when the block is released and are executed by a different thread. When the different thread executes the operations, the ThreadContext is that of the thread that was blocking operations. In order to preserve the ThreadContext, we need to store it and wrap the listener when the operation is delayed.
Update java.asciidoc (elastic#23035) A couple more minor errors
Update Painless Loop Counter to be Higher (elastic#22560) Updated Painless loop counter to be 1000000 statements instead of 10000 for update queries.
Only update DocumentMapper if field type changes (elastic#22165) Merging mappings ensures that fields are used consistently across mapping types. Disabling norms for a specific field in one mapping type for example also disables norms for the same field in other mapping types of that index. The logic that ensures this while merging mappings currently always creates a fresh document mapper for all existing mapping types, even if no change occurred. Creating such a fresh document mapper does not come for free though as it involves recompressing the source. Making a mapping change to one type of an index with 100 types will thus re-serialize and recompress all 100 types, independent of any changes made to those types. This commit fixes the update logic to only create a new DocumentMapper if a field type actually changes.
PreviousNext