forked from cockroachdb/cockroach
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
roachtest/cdc-mixed-versions: add multi-step upgrade test
This change adds a new roachtest "cdc/mixed-versions-multiple-upgrades" which starts a changefeed and ensures that it keeps running through multiple cluster upgrades and rollbacks. This test is an extension of a previous test "cdc/mixed-versions" which only tests upgrading from one previous version to the present version. "cdc/mixed-versions" is now renamed to "cdc/mixed-versions-single-upgrade". "cdc/mixed-versions-multiple-upgrades" performs 4 upgrades starting from 4 versions in the past. As seen in cockroachdb#107293, changefeeds running on versions prior to 22.2 can be very brittle, mainly due to them not retrying transient errors. To address this problem, this new roachtest will ensure that 22.2 is the minimum binary version. So if this test is running on 23.1, it will only test the upgrade path from 22.2-23.1. Once 23.2 releases, it will test the upgrade path from 22.2 -> 23.1 -> 23.2 and so on, keeping a running window of size 4. More notes: Can we remove the restriction of starting at version 22.2? In [cockroachdb#107293](cockroachdb#107293), we added some code to restart the changefeed in case it fails to reduce flakes when running 22.1. It does defeat the purpose of the test to do so, so it would not make sense to do something similar in this change. It also does not make sense to change 22.1 because it is EOL'd. Why perform the upgrade through multiple versions? As seen in cockroachdb#107451, there are cases where, for example, a 22.1 changefeed survives an upgrade to 22.2 and a 22.2 changefeed survives and upgrade to 23.1, but a 22.1 does NOT survive an upgrade from 22.1 -> 22.2 -> 23.1. This non-transitive relationship is the reason that I added this new test. We (and our users) expect that arbitrarily old jobs can be resumed in new versions without error (unless we explicitly add code to fail these jobs in certain cases). Because of this expectation, we should have a test which asserts a changefeed stays running through multiple version upgrades. Why limit the test at 4 versions? We do not want the test to run for an unbounded number of upgrades as we have many more releases in the future. Closes: cockroachdb#107451 Epic: None Release note: None
- Loading branch information
1 parent
05ad3c4
commit 65a10e5
Showing
3 changed files
with
146 additions
and
52 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters