You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
107145: backupccl: add RESTORE job to wait for background downloads r=dt a=dt
After an online restore completes its initial data mounting phase, we
actually go download the data in the background, both so that it will be
faster to access once it is stored locally but also to make it
permanently owned by the cluster, rather than remaining linked to the
backup, which could be moved, expire, etc.
Users need to be able to see, observe and control this process, in
particular they need to know when it completes or will complete, so that
they know when to expect normal performance or when they can lift
modification/expiration blocks on their backups.
This change introduces new RESTORE job, created by the initial restore
job after it has linked in the external sstables, which polls the stores
to determine how much data remains to be downloaded, and completes when
this number reaches zero.
A future change will likely extend this job to also explicitly invoke a
compaction specifically configured to download these files, to make this
happen more immediately and to make it controllable by the job, but for
now this initial implementation only waits and polls to track the state
of the compaction, rather than actively compacting itself.
Release note: none.
Epic: none.
107187: cloud: fix incorrect rebase of ResumingReader open at size patch r=rhu713 a=rhu713
Recently cockroachdb#103462 was merged after incorrectly rebasing and did not correctly incorporate the addition of the NoFileSize read option for external storages. This patch fixes the rebase in GCS storage and in cloud unit tests.
Fixes: cockroachdb#107136Fixes: cockroachdb#107138
Cloud Unit Test Manual Run: https://teamcity.cockroachdb.com/buildConfiguration/Cockroach_Nightlies_CloudUnitTests/10977689
Release note: None
107203: kvserver: enable `raft.Config.StepDownOnRemoval` r=erikgrinaker a=erikgrinaker
**kvserver: tweak `TestRaftLeaderRemovesItself`**
**kvserver: campaign when leader is demoted to learner**
This patch campaigns when the leader demotes itself to a learner during an atomic conf change, instead of waiting until it is completely removed from the range. Relying on the old leader to commit the final conf change while it's a learner appears unfortunate, and is not compatible with an upcoming etcd/raft change that makes the learner step down in this case.
This is backwards compatible with 23.1, because the same follower replica is responsible for campaigning, and it does not matter if it campaigns during the demotion or removal -- in particular because it forces an immediate election via `forceCampaignLocked()` which immediately bumps the term.
**kvserver: enable `raft.Config.StepDownOnRemoval`**
This causes the Raft leader to step down when it removes itself from the range or demotes itself to a learner. This doesn't make any difference functionally, since we're careful to no longer tick the replica or otherwise use it, but in principle it could cause a leader that was no longer part of the range to continue to assert leadership, stalling the range since it wouldn't be able to propose anything. Stepping down appears safer and cleaner.
Epic: none
Release note: None
107240: upgrade/upgrades: skip TestJSONForwardingIndexes r=mgartner a=DrewKimball
Refs: cockroachdb#107169
Reason: flaky test
Generated by bin/skip-test.
Release justification: non-production code changes
Release note: None
Epic: None
Co-authored-by: David Taylor <[email protected]>
Co-authored-by: Rui Hu <[email protected]>
Co-authored-by: Erik Grinaker <[email protected]>
Co-authored-by: Drew Kimball <[email protected]>
0 commit comments