Commit Graph

17 Commits

Author SHA1 Message Date
aa97484166 *: enable goimports in verify-lint
Signed-off-by: Wei Fu <fuweid89@gmail.com>
2023-09-21 21:14:09 +08:00
53cbd81009 Separate Writer interface from BatchTx interfaces
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2023-07-31 10:18:01 +02:00
29769984e6 Remove RLock/RUnlock from BatchTx
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2023-07-28 11:39:50 +02:00
bc97a94564 Follow up https://github.com/etcd-io/etcd/pull/16068#discussion_r1263664700
Replace unnecessary Lock()/Unlock()s with RLock()/RUnlock()s

Signed-off-by: caojiamingalan <alan.c.19971111@gmail.com>
2023-07-14 20:08:25 -05:00
9e1abbab6e Fix goimports in all existing files. Execution of ./scripts/fix.sh
Signed-off-by: Piotr Tabor <ptab@google.com>
2022-12-29 09:41:31 +01:00
5f8cd5bd39 Replace all etcd versions with the centralized definitions
We have already defined all the constant etcd versions in the
centralized place api/version/version.go. So we should replace all
the versions with the centralized definitions.
2022-06-13 14:08:39 +08:00
e155e50886 rename LockWithoutHook to LockOutsideApply and add LockInsideApply 2022-04-07 05:35:13 +08:00
bfd5170f66 add a txPostLockHook into the backend
Previously the SetConsistentIndex() is called during the apply workflow,
but it's outside the db transaction. If a commit happens between SetConsistentIndex
and the following apply workflow, and etcd crashes for whatever reason right
after the commit, then etcd commits an incomplete transaction to db.
Eventually etcd runs into the data inconsistency issue.

In this commit, we move the SetConsistentIndex into a txPostLockHook, so
it will be executed inside the transaction lock.
2022-04-07 05:35:13 +08:00
d578a86a59 fix some log format typos 2022-03-10 03:26:34 +08:00
1ae5aa52de fix some typos related to downgrade 2022-03-09 16:07:18 +08:00
431adc5878 server: Implement storage downgrades
By validating if WAL doesn't include any incompatible entries we can
implement storage downgrades.
2021-10-29 12:47:19 +02:00
79f6faa5c7 Apply suggestions from code review
Co-authored-by: Lili Cosic <cosiclili@gmail.com>
2021-09-10 10:16:48 +02:00
ff3729c4d5 server: Implement storage schema migration to follow cluster version change and panic if unknown storage version is found
Storage version should follow cluster version. During upgrades this
should be immidiate as storage version can be always upgraded as storage
is backward compatible. During downgrades it will be delayed and will
require time for incompatible changes to be snapshotted.

As storage version change can happen long after cluster is running, we
need to add a step during bootstrap to validate if loaded data can be
understood by migrator.
2021-09-10 10:16:48 +02:00
0d15ff57e6 server: Implement schema migrations 2021-09-10 10:16:48 +02:00
b4b50f7852 etcdutl: Implement migrate --force command
Co-authored-by: nic-chen <33000667+nic-chen@users.noreply.github.com>
Co-authored-by: Heisenberg <yuzhiquanlong@gmail.com>
2021-08-04 17:58:18 +02:00
a97e48e08d Cleanup references to bucket module 2021-07-20 17:50:47 +02:00
f6534f1e92 server: Move setting storage version to schema 2021-07-12 15:37:21 +02:00