Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(no)StoreV2 (Part 2): Prepare to read membership information from backend #12820

Merged
merged 6 commits into from
Apr 28, 2021

Conversation

ptabor
Copy link
Contributor

@ptabor ptabor commented Mar 30, 2021

Preparation work to read membership information from backend instead of v2store.

This change fixes:

  • 2 issues with etcdctl snapshot restore that was not properly updating membership information in backend.
  • the fact that we were testing upgrade against 3.3 (instead of 3.4)
  • the fact that V2 etcdctl backup was produciong internally inconsistent membership information between v2 & v2 backend.

This change does not impacts behavior of etcd binary itself, and the membership information is still read for v2store.
Separate PR that changes this will follow.

@ptabor ptabor force-pushed the 20210326-membership-from-be branch 2 times, most recently from 4843d3e to d3fa68f Compare April 2, 2021 20:39
@ptabor ptabor requested a review from hexfusion April 2, 2021 20:41
@ptabor ptabor force-pushed the 20210326-membership-from-be branch 3 times, most recently from 962d0e3 to e9f6cd6 Compare April 3, 2021 10:27
@codecov-io
Copy link

codecov-io commented Apr 3, 2021

Codecov Report

Merging #12820 (c61c97d) into master (a40a6e9) will decrease coverage by 0.85%.
The diff coverage is 65.53%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #12820      +/-   ##
==========================================
- Coverage   66.43%   65.57%   -0.86%     
==========================================
  Files         410      424      +14     
  Lines       32739    33226     +487     
==========================================
+ Hits        21749    21787      +38     
- Misses       9081     9353     +272     
- Partials     1909     2086     +177     
Flag Coverage Δ
all 65.57% <65.53%> (-0.86%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
server/mvcc/backend/batch_tx.go 59.42% <0.00%> (-3.66%) ⬇️
server/etcdserver/api/membership/cluster.go 67.09% <38.46%> (-13.09%) ⬇️
server/etcdserver/api/membership/store.go 44.31% <46.66%> (-5.69%) ⬇️
etcdctl/snapshot/v3_snapshot.go 61.35% <68.00%> (-1.39%) ⬇️
etcdctl/ctlv2/command/backup_command.go 73.65% <90.19%> (+7.69%) ⬆️
etcdctl/ctlv3/command/migrate_command.go 61.53% <100.00%> (ø)
server/etcdserver/api/membership/member.go 83.33% <100.00%> (-5.31%) ⬇️
server/etcdserver/cluster_util.go 52.57% <100.00%> (-15.81%) ⬇️
server/etcdserver/raft.go 81.08% <100.00%> (-4.30%) ⬇️
server/etcdserver/api/v3compactor/revision.go 0.00% <0.00%> (-76.93%) ⬇️
... and 199 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a40a6e9...c61c97d. Read the comment docs.

@ptabor ptabor force-pushed the 20210326-membership-from-be branch from e9f6cd6 to c61c97d Compare April 7, 2021 18:36
@jingyih
Copy link
Contributor

jingyih commented Apr 7, 2021

Let's be careful about this. IIRC, etcdserver does not use consistent index to guard the apply of config change entries.

case raftpb.EntryConfChange:

If we switch to restore membership from v3 backend, this means we could potentially re-apply the config changes?

@ptabor
Copy link
Contributor Author

ptabor commented Apr 7, 2021

Good catch that we don't have the same shouldApplyV3 guard that we do for regular entries:

shouldApplyV3 = true

Taking in consideration that StoreV2 membership information is written in exact same place where Backend is updated:

if c.v2store != nil {
mustSaveMemberToStore(c.lg, c.v2store, m)
}
if c.be != nil {
mustSaveMemberToBackend(c.lg, c.be, m)
}

If there is a problem, we would have it already. Maybe membership edit operations are re-entrant and for that reason its working ?

@ptabor ptabor requested a review from jingyih April 7, 2021 23:20
@jingyih
Copy link
Contributor

jingyih commented Apr 8, 2021

V2 store is not as persistent as the V3 backend. V2 store is in memory. Upon restart, it is initially recovered from the last snapshot (and then raft will replay the WAL entries since the last snapshot), whereas initially V3 backend has all the data up to the applied index.

@ptabor ptabor force-pushed the 20210326-membership-from-be branch 3 times, most recently from 8e3393d to 8343d16 Compare April 8, 2021 11:27
ptabor added a commit to ptabor/etcd that referenced this pull request Apr 12, 2021
…lied on v2store

ClusterVersionSet, ClusterMemberAttrSet, DowngradeInfoSet functions are
writing both to V2store and backend. Prior this CL there were
in a branch not executed if shouldApplyV3 was false,
e.g. during restore when Backend is up-to-date (has high
consistency-index) while v2store requires replay from WAL log.

The most serious consequence of this bug was that v2store after restore
could have different index (revision) than the same exact store before restore,
so potentially different content between replicas.

Also this change is supressing double-applying of Membership
(ClusterConfig) changes on Backend (store v3) - that lackilly are not
part of MVCC/KeyValue store, so they didn't caused Revisions to be
bumped.

Inspired by jingyih@ comment:
etcd-io#12820 (comment)
@ptabor ptabor changed the title (no)StoreV2: Read membership information from backend (no)StoreV2 (Part 5): Read membership information from backend Apr 12, 2021
@ptabor ptabor changed the title (no)StoreV2 (Part 5): Read membership information from backend (no)StoreV2 (Part 5): Prepare to read membership information from backend Apr 12, 2021
@ptabor ptabor changed the title (no)StoreV2 (Part 5): Prepare to read membership information from backend (no)StoreV2 (Part 2): Prepare to read membership information from backend Apr 12, 2021
@ptabor ptabor force-pushed the 20210326-membership-from-be branch from 8343d16 to 486a3c1 Compare April 12, 2021 16:37
@ptabor
Copy link
Contributor Author

ptabor commented Apr 12, 2021

@jingyih: Thank you for the comments. Based on this I discovered more serious issue: ClusterVersion information was not saved to v2store when restoring with 'recent consistency_index'.

@ptabor ptabor force-pushed the 20210326-membership-from-be branch from 486a3c1 to 16e6aec Compare April 12, 2021 18:46
ptabor added a commit to ptabor/etcd that referenced this pull request Apr 13, 2021
…lied on v2store

ClusterVersionSet, ClusterMemberAttrSet, DowngradeInfoSet functions are
writing both to V2store and backend. Prior this CL there were
in a branch not executed if shouldApplyV3 was false,
e.g. during restore when Backend is up-to-date (has high
consistency-index) while v2store requires replay from WAL log.

The most serious consequence of this bug was that v2store after restore
could have different index (revision) than the same exact store before restore,
so potentially different content between replicas.

Also this change is supressing double-applying of Membership
(ClusterConfig) changes on Backend (store v3) - that lackilly are not
part of MVCC/KeyValue store, so they didn't caused Revisions to be
bumped.

Inspired by jingyih@ comment:
etcd-io#12820 (comment)
@ptabor
Copy link
Contributor Author

ptabor commented Apr 15, 2021

@jingyih @hexfusion: Please take a look.

@ptabor ptabor added this to the etcd-v3.5 milestone Apr 17, 2021
be := backend.NewDefaultBackend(dbpath)
defer be.Close()

ci := cindex.NewConsistentIndex(be.BatchTx())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is setting consistent index removed from this function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good observation. Trying to develop a good test that would catch such inconsistency...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jingyih: PTAL. I fixed this problem and added a test that would detected it. See server/verify/verify.go.

@ptabor ptabor force-pushed the 20210326-membership-from-be branch 3 times, most recently from e1ffa9a to a18e995 Compare April 22, 2021 07:51
correct 'backend' (bbolt) context in aspect of membership.

Prior to this change the 'restored' backend used to still contain:
  - old memberid (mvcc deletion used, why the membership is in bolt
bucket, but not mvcc part):
    ```
	mvs := mvcc.NewStore(s.lg, be, lessor, ci, mvcc.StoreConfig{CompactionBatchLimit: math.MaxInt32})
	defer mvs.Close()
	txn := mvs.Write(traceutil.TODO())
	btx := be.BatchTx()
	del := func(k, v []byte) error {
		txn.DeleteRange(k, nil)
		return nil
	}

	// delete stored members from old cluster since using new members
	btx.UnsafeForEach([]byte("members"), del)
    ```
  - didn't get new members added.
@ptabor ptabor force-pushed the 20210326-membership-from-be branch from a18e995 to ac295e5 Compare April 27, 2021 15:24
@ptabor ptabor requested a review from jingyih April 27, 2021 15:28
@ptabor ptabor force-pushed the 20210326-membership-from-be branch 2 times, most recently from dd73aba to befaf41 Compare April 27, 2021 16:25

// TrimMembershipFromBackend removes all information about members &
// removed_members from the v3 backend.
func TrimMembershipFromBackend(lg *zap.Logger, be backend.Backend) error {
Copy link
Contributor

@gyuho gyuho Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we log some info and errors here? lg is not used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@ptabor ptabor force-pushed the 20210326-membership-from-be branch from 9ef142c to 0675219 Compare April 27, 2021 17:34
Copy link
Contributor

@jingyih jingyih left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ptabor ptabor merged commit d2722ff into etcd-io:master Apr 28, 2021
@ptabor ptabor deleted the 20210326-membership-from-be branch April 28, 2021 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

6 participants