-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Use local segment fieldInfos to lookup tsdb merge stats #132597
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
Conversation
05076f2 to
2d5f28c
Compare
|
Hi @dnhatn, I've created a changelog YAML for you. |
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
martijnvg
left a comment
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.
Thanks Nhat, very good find here. LGTM 👍
| for (int i = 0; i < mergeState.docValuesProducers.length; i++) { | ||
| final FieldInfo fieldInfo = mergeState.fieldInfos[i].fieldInfo(mergedFieldInfo.name); | ||
| if (fieldInfo == null) { | ||
| continue; |
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.
This is similar to this if statement:
var wrapped = perFieldReader.getDocValuesProducer(fieldInfo);
if (wrapped == null) {
continue;
}
and so it is safe to continue here? (and we don't have to fallback to UNSUPPORTED)
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.
Yes, it should be safe to continue with the merge optimization. If the FieldInfo is null in some segments, it is safe to skip those and use the merge stats from segments that have values.
|
Thanks Martijn! |
💔 Backport failed
You can use sqren/backport to manually backport by running |
Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates elastic#125403
…32612) Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates #125403
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates elastic#125403
…32613) Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates #125403
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via #132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
Adding #132597 as known issue for 9.1.0-9.1.1
Adding #132597 as known issue for 8.19.0. Placing it at the very bottom just to be consistent with other release notes in the 8-series (though known issues are better positioned towards the top of the release notes -- after breaking changes).
Adding #132597 as known issue for 8.19.1. Placing it at the very bottom just to be consistent with other release notes in the 8-series (though known issues are better positioned towards the top of the release notes -- after breaking changes).
Reverting change based on the [comment](#132683 (comment)). Due to a PR CI issue, the [optimization](#125403) introduced in 8.19.0 that would have caused the [bug](#132597) didn't actually get enabled in 8.19.x versions. Therefore, 8.19.0 and 8.19.1 do not have either the optimization or the bug. The optimization will be enabled in 8.19.2 and the bug will be fixed by then.
Reverting change based on the [comment](#132683 (comment)). Due to a PR CI issue, the [optimization](#125403) introduced in 8.19.0 that would have caused the [bug](#132597) didn't actually get enabled in 8.19.x versions. Therefore, 8.19.0 and 8.19.1 do not have either the optimization or the bug. The optimization will be enabled in 8.19.2 and the bug will be fixed by then.
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via elastic#132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via elastic#132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via #132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via #132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+.
When shrinking an index to a single shard, we use addIndexes, which can
add Lucene segments directly. In this case, FieldInfos can differ
between shards and the new segment. We should use the FieldInfos from
each segment to retrieve the merge stats, instead of the FieldInfos of
the merged segment.
Relates #125403