how to patch (3.6.12 > 3.6.14) ?

[dulhaver]

there is a chapter on upgrading, operation, and maintenance in the docs, but it was forgotten to mention how the patch process (3.6.12 > 3.6.14 in my conrete case) should be done.

can anybody help me out? I would guess ...

1. stop etcd-3.6.12
2. replace the binaries
3. start etcd-3.6.14

[latent-9]

Your three steps are basically correct. A patch bump inside the same minor (3.6.x to 3.6.y) is the easy case: the on-disk data format and the cluster protocol don't change, so there's no migration and no downgrade dance, you just swap the binary. You can also go straight from 3.6.12 to 3.6.14 (skipping .13); patch releases within a minor are compatible in both directions.

Single node: stop etcd, replace the binary, start it. Done.

Cluster: do it as a rolling restart, one member at a time, to keep quorum:

1. (Recommended) snapshot first: etcdctl snapshot save backup.db.
2. Confirm health: etcdctl endpoint health --cluster and etcdctl endpoint status --cluster -w table.
3. On one member: stop the process, replace the 3.6.12 binary with 3.6.14, start it with the same config/flags/data-dir.
4. Wait for it to rejoin and the cluster to report healthy again, then move to the next member. Repeat for all.

Because it's a patch bump, running mixed 3.6.12/3.6.14 members during the rollout is fine, and you can roll back to the old binary if needed (unlike a completed minor upgrade). No data conversion / etcdutl migrate step is required.

Reference: etcd upgrade guide (https://etcd.io/docs/v3.6/upgrades/upgrade_3_6/). The same "stop a member, restart with the new binary and same config, repeat" flow applies, and it's simpler for a patch since the protocol version is unchanged.

[gitsult4n]

Your three steps are the whole process
add only "one member at a time" and "wait for health before the next one"

why a patch bump needs nothing else
the storage schema is tracked at minor granularity only

server/storage/schema/schema.go:46-49

func localBinaryVersion() semver.Version {
	v := semver.MustParse(version.Version)
	return *semver.New(v.Major(), v.Minor(), 0, "", "")
}

and the change table is keyed the same way — schemaChanges has entries for V3_6 V3_7 V3_8 and nothing per patch :130-136
so 3.6.12 and 3.6.14 are the same schema
no migration step and no downgrade job

rolling restart

etcdctl endpoint status -w table --cluster   # note the leader
etcdctl move-leader <other-member-id>        # only when you reach the leader

# then per member one at a time
systemctl stop etcd
install -m 0755 etcd etcdctl etcdutl /usr/local/bin/
systemctl start etcd
etcdctl endpoint health --cluster            # all healthy before the next member

the data dir stays as it is and the member rejoins on its own so --initial-cluster needs no edit

take etcdctl snapshot save first anyway

rollback is symmetric — drop the old binary back in and start
the on disk format did not move so it comes up on the same data dir

3.6.13 and 3.6.14 are bugfix and security only per CHANGELOG/CHANGELOG-3.6.md
worth reading before you go since one of them is the watch permission leak GHSA-xg4h-6gfc-h4m8