Skip to content

Allow a tsdb data stream to rolled over to a logsdb data stream #126640

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

Merged
merged 5 commits into from
Apr 11, 2025

Conversation

martijnvg
Copy link
Member

and the other way around.

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to #126637

and the other way around.

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to elastic#126637
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-storage-engine (Team:StorageEngine)

@@ -610,6 +610,10 @@ public DataStream unsafeRollover(
} else if (dsIndexMode == IndexMode.LOGSDB && (indexModeFromTemplate == null || indexModeFromTemplate == IndexMode.STANDARD)) {
// Allow downgrading a time series data stream to a regular data stream
dsIndexMode = null;
} else if (dsIndexMode == IndexMode.TIME_SERIES && indexModeFromTemplate == IndexMode.LOGSDB) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is dsIndexMode the index mode of the write index?

Copy link
Member Author

Choose a reason for hiding this comment

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

It indicates whether a data stream is a tsdb data stream or a logsdb data stream. It isn't always the index mode of the most recent backing index, because the standard and lookup mode are never set as index mode of a data stream (there is no such thing as a lookup data stream). There is logic that checks the index mode (all checks are for time series iirc) of the data stream without having the to lookup the most recent IndexMetadata.

But if a data stream's index mode is logsdb or time series, then the most recent backing index's index mode should also be time series of logsdb.

} else if (dsIndexMode == IndexMode.TIME_SERIES && indexModeFromTemplate == IndexMode.LOGSDB) {
dsIndexMode = IndexMode.LOGSDB;
} else if (dsIndexMode == IndexMode.LOGSDB && indexModeFromTemplate == IndexMode.TIME_SERIES) {
dsIndexMode = IndexMode.TIME_SERIES;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we be adding a warning too? Just in case this is done by mistake..

@martijnvg martijnvg added the auto-backport Automatically create backport pull requests when merged label Apr 11, 2025
@martijnvg martijnvg enabled auto-merge (squash) April 11, 2025 12:25
@martijnvg martijnvg merged commit f658af6 into elastic:main Apr 11, 2025
17 of 18 checks passed
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.18 Commit could not be cherrypicked due to conflicts
8.x Commit could not be cherrypicked due to conflicts
9.0 Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 126640

martijnvg added a commit to martijnvg/elasticsearch that referenced this pull request Apr 11, 2025
and the other way around.

Backporting elastic#126640

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to elastic#126637
martijnvg added a commit to martijnvg/elasticsearch that referenced this pull request Apr 11, 2025
and the other way around.

Backporting elastic#126640

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to elastic#126637
martijnvg added a commit to martijnvg/elasticsearch that referenced this pull request Apr 11, 2025
and the other way around.

Backporting elastic#126640 to 8.18 branch.

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to elastic#126637
elasticsearchmachine pushed a commit that referenced this pull request Apr 11, 2025
#126714)

* [8.18] Allow a tsdb data stream to rolled over to a logsdb data stream
and the other way around.

Backporting #126640 to 8.18 branch.

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to #126637

* fix test compile issue
martijnvg added a commit that referenced this pull request Apr 12, 2025
…#126712)

Backporting #126640 to 9.0 branch.

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to #126637

* fix test compile issue
martijnvg added a commit that referenced this pull request Apr 12, 2025
…#126713)

Backporting #126640 to 8.x branch.

This doesn't make much sense. However, if a data stream's index mode differs from the index mode of most recent backing index, then this can cause confusion. Typically, misconfiguration is a reason this can happen.

Related to #126637
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Automatically create backport pull requests when merged >non-issue :StorageEngine/TSDB You know, for Metrics Team:StorageEngine v8.18.1 v8.19.0 v9.0.1 v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants