Version upgrade 0.10 -> 0.13 breaks database

[atombender]

Currently running:

Apr 22 23:46:30 prometheus: prometheus, version 0.10.0 (branch: master, revision: ab55188)

I want to upgrade to:

Apr 22 23:45:08 prometheus: prometheus, version 0.13.1 (branch: master, revision: fa42ed0)

This fails with:

Apr 22 23:45:08 prometheus: E0422 23:45:08.968471    3120 main.go:127] Error opening memory series storage: could not detect storage version on disk, assuming version 0, need version 1 - please wipe storage or run a version of Prometheus compatible with storage version 0

I can't find any information in the docs about migrating data. How do I upgrade without losing my data?

[atombender]

Found this in the changelog, for anyone reading:

All metrics stored with previous versions of Prometheus cannot be used anymore. A version guard will protect you from accidentally running the Prometheus server with an incompatible storage. Implementing a conversion tool would be a lot of work (but if somebody wants to do it, be our guest...), so there is no other solution right now but wiping the storage or stick with v0.11.1.

This really does not build confidence.

[fabxc]

The frustration is understandable but as we are in version 0.x breaking changes may happen even though they are avoided when possible.

As the project matures the likelihood of such wipes will drastically decrease. The change involved here reduces Prometheus's storage requirements by 40% - since Prometheus is not a long-term storage this can be considered a good reason to break things.

If there should be another mandatory storage wipe, we will do our best to have something ready that lets you reimport your old data.

[juliusv]

Sorry for the breaking change. Yes, occasional breakages can still happen in 0.x-land when there are very good reasons. They will always be pointed out in the changelog. See also the FAQ section about that.

That said, we currently don't anticipate any more breaking storage changes, unless something completely unexpected happens.

[atombender]

Breaking changes are perfectly fine and to be expected. But the lack of an upgrade path is not.

[juliusv]

@atombender It's an open-source project in 0.x state, and for a short-term storage time series database we do not have that expectation currently - PRs are welcome though. One migration path that's always available to you in lieu of a migration tool: bring up a new identical instance, let it collect enough (identical) data, then switch to the new one. Again, we expect fewer and fewer breaking changes down the line.

[lock]

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.