Do not recover db snapshot if index is 0

[jlhawn]

... as that would indicate that the backend is a newly initialized
store rather than an outdated snapshot.

Fixes #9480

cc @gyuho

[jlhawn]

@gyuho I've confirmed that this fixes the issue I was seeing but I'm not 100% certain that it's safe.

[jlhawn]

This code block suggests to me that it may be safe (it logs a warn message instead of returning an error). There's also that TODO comment about removing the check when it no longer supports upgrades from pre-3.0 releases.

[gyuho]

This is unsafe. v3 should still panic on accidental db file deletion. I will add an optional flag to allow boot from empty db file, in case of upgrades from v2.

[gyuho]

when it no longer supports upgrades from pre-3.0 releases.

We still support upgrades from pre-3.0. We might panic in that TODO in v4 (where v2 support is completely dropped).

[gyuho]

This code block suggests to me that it may be safe

That code block only applies when db file initially existed.

[jlhawn]

That code block only applies when db file initially existed.

The member/snap/db file does already exist. In my repro in #9480 (comment) it exists from the time you start etcd v3.0 but you don't hit the crash until v3.2 starts up.

[gyuho]

member/snap/db file does already exist

Then, that file should have been created from v3.0 migrate. Since we only support v3.2 and v3.3, we will provide a way to override that in v3.2. It would be like:

• manually delete db file (given that no v3 data is ever written)
• upgrade to v3.0
• manually delete db file (given that no v3 data is ever written)
• upgrade to v3.1
• manually delete db file (given that no v3 data is ever written)
• upgrade to v3.2 with --unsafe-overwrite-db

[jlhawn]

@gyuho if that is the suggested upgrade process then I wonder if it would just be okay to upgrade directly from v2.3 to v3.2 (with the understanding that this would not be a zero-downtime upgrade) using the --unsafe-overwrite-db flag? That way we could avoid the awkward steps of deleting the db file on those other versions?

Also, what would be the recommended next step? I would guess that you would want to start the server using --unsafe-overwrite-db and then restart the sever ASAP without that flag?

[gyuho]

@jlhawn Yeah... just upgrade directly to v3.2 should be easier (as long as there will be no v3 data). Sorry for confusing steps. I will make sure to document this process.

[gyuho]

Also, what would be the recommended next step? I would guess that you would want to start the server using --unsafe-overwrite-db and then restart the sever ASAP without that flag?

I will document the steps in #9484.

[jlhawn]

I will document the steps in #9484.

Thanks! I'll ask more questions there if I have any.