-
Notifications
You must be signed in to change notification settings - Fork 3.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
fix(tsdb): never use an inmem index #20313
Conversation
@stuartcarnie could you take a look at this one? I'm pretty confident the existing gotests cover the logic (many were failing when I still had bugs in |
Other note from Zoom review: try to add an integration test to check that index files are (re)generated if missing, and that query results are the same. |
10b9413
to
192c178
Compare
c68e769
to
0e58f48
Compare
0e58f48
to
a7ecd1b
Compare
if pw, ok := e.pointsWriter.(*coordinator.PointsWriter); ok { | ||
pw.Logger = e.logger | ||
pw.WithLogger(e.logger) |
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.
Drive-by fix for engine logging setup
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.
Great work, @danxmoran – removing this will simplify future maintenance of the TSDB engine. 🥇 👏 🧹
Closes #20257
2.x was never meant to use an inmem index, but there was a fallback code path to handle cases when
influxd upgrade
didn't convert an inmem index into TSI. All code for the inmem index is now deleted, and the fallback is replaced by a one-time reindex operation run on shards w/o a TSI directory.The reindex logic is inspired by the
influx inspect
implementation, but uses methods onEngine
to read TSM / WAL data instead of listing and reading files directly from the file system.