*: "--unsafe-overwrite-db" flag to support v2 migration with no previous v3 data #9484
Conversation
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Only allow when explicitly configured to do so. Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
| @@ -212,6 +212,8 @@ See [issue #6336](https://github.com/coreos/etcd/issues/6336) for more contexts. | |||
|
|
|||
| ### Server upgrade checklists | |||
|
|
|||
| **NOTE:** `v3.2.18` added [`etcd --unsafe-overwrite-db`](https://github.com/coreos/etcd/pull/9484) flag, to support [migration from v2 with no v3 data](https://github.com/coreos/etcd/issues/9480). etcd server panics if it tries to restore from existing snapshots but no v3 `ETCD_DATA_DIR/member/snap/db` file. This happens when the server had migrated from v2 with no previous v3 data. This is to prevent accidental v3 data loss (e.g. `db` file might have been moved). With `--unsafe-overwrite-db` enabled, etcd allows to create a fresh `db` file on reboot, when there are existing snapshots. To continue to use etcd without v3 data, keep `--unsafe-overwrite-db` enabled. Or write some test v3 keys (e.g. `ETCDCTL_API=3 etcdctl put foo bar`), and then restart etcd with `--unsafe-overwrite-db` disabled. Use this flag only for v2 migration. Otherwise, previous v3 data could be overwritten with existing snapshots. v4 will deprecate this flag. | |||
There was a problem hiding this comment.
@jlhawn Please let me know if this makes sense. Basically, if you aren't going to write any v3 keys for awhile, keep the --unsafe-overwrite-db flag. Or start with --unsafe-overwrite-db flag once, and write some test v3 keys. And restart with --unsafe-overwrite-db flag disabled. It's complicated, but think it's safer while keeping the fix introduced in #7876 :0
|
2.3.x should only be allowed to upgrade to 3.0 directly. Why do we need to change 3.3 branch? |
|
@xiang90 @jlhawn The extra snapshot recovery check On second thought, this PR doesn't really fix anything. Just confusing users to run unsafe operations. @jlhawn I would just suggest writing some test v3 keys on v3.1 to v3.2 migration path, to work around #9480. Instead, I will make it clear that post v3.1 migration should only happen when you have v3 data. I will update the docs next week. |
|
Documented here #9486. |
Fix #9480.