Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upProtect against data loss by OS crash #591
Comments
beorn7
added
the
enhancement
label
Mar 11, 2015
beorn7
self-assigned this
Mar 11, 2015
This comment has been minimized.
This comment has been minimized.
|
This is implemented now. I couldn't find a good way for an equivalent of running the |
beorn7
closed this
Mar 19, 2015
swsnider
referenced this issue
Aug 13, 2015
Closed
Prometheus storage considered dirty on every startup #985
simonpasquier
pushed a commit
to simonpasquier/prometheus
that referenced
this issue
Oct 12, 2017
This comment has been minimized.
This comment has been minimized.
lock
bot
commented
Mar 24, 2019
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
lock
bot
locked and limited conversation to collaborators
Mar 24, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
beorn7 commentedMar 11, 2015
Inspired by @matthiasr and in the spirit of #590 , I was thinking about sync'ing series files, too.
In general, that would just kill performance, but with the newly designed persistence strategy #589 , the number of series file operations is reduced. We could at least offer a flag to sync after each write to a series file. (And the order should be sync (optional) - close - rename, not rename - close, as it is now.) One idea of mine (as a third option for the flag): An adaptive strategy, sync as long as the persist queue is mostly empty. once a certain watermark is reached, switch to non-sync'd writes. (Similar to what we do already with checkpointing.)
Independent from the above, we could/should just sync everything upon shutdown (
man 2 sync). Not sure if there is a platform indpendent way to do that with Go.