[
https://issues.apache.org/jira/browse/HDDS-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng updated HDDS-15937:
------------------------------
Attachment: HDDS-15937-rocksdb-rollback-validation.patch
> Verify RocksDB 7.7.3 in 2.2.0 can reopen the database after RocksDB 10.10.1.1
> wrote and compacted SSTs
> ------------------------------------------------------------------------------------------------------
>
> Key: HDDS-15937
> URL: https://issues.apache.org/jira/browse/HDDS-15937
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: test
> Reporter: Siyao Meng
> Assignee: Siyao Meng
> Priority: Major
> Attachments: HDDS-15937-rocksdb-rollback-validation.patch
>
>
> h3. Goal
> Verify that Ozone 2.2.0 with RocksDB 7.7.3 can reopen and read the same OM
> database after Ozone 2.3.0 with RocksDB 10.10.1.1 has written and compacted
> new SST files. The new SSTs must remain at block-based table format_version 5
> so rollback to 2.2.0 remains compatible.
> h3. Test command
> {code}
> run_test ha non-rolling-upgrade 2.2.0 2.3.0
> {code}
> h3. Test scenario
> # Start the HA cluster on Ozone 2.2.0, verify it is finalized, and create the
> baseline upgrade dataset.
> # Restart the same cluster and data directories on Ozone 2.3.0 with
> --upgrade. Do not invoke the explicit finalization step before downgrade.
> Since 2.3.0 introduces no new OM or HDDS layout feature after 2.2.0, OM and
> SCM already report finalized; this exercises rollback across the binary and
> RocksDB version change rather than rollback with a pending layout
> finalization.
> # While running 2.3.0, create a dedicated OBS volume and bucket and perform
> three rounds of writes. Each round writes 2,000 keys and forces keyTable
> compaction on om1, om2, and om3. Inventory newly created SST files, copy them
> to the test results, inspect their table properties, and require
> format_version 5. Require at least one newly created OM SST. Newly observed
> SCM and datanode SSTs are checked opportunistically.
> # Stop 2.3.0 and restart the same data directories on Ozone 2.2.0 with
> --downgrade. Validate the common datasets written under 2.3.0 and read
> format-round-3/0, written during the final 2.3.0 compaction round. Require
> the downloaded key to be non-empty.
> # Restart 2.3.0, run the normal explicit finalization phase, and complete the
> common upgrade validations.
> h3. Success criteria
> * Compaction completes successfully on all three OMs in all three rounds.
> * Every newly observed SST reports format_version 5.
> * At least one new OM SST is observed.
> * Ozone 2.2.0 with RocksDB 7.7.3 starts successfully against the database
> previously used by 2.3.0.
> * The downgraded 2.2.0 cluster reads both the normal upgrade datasets and
> format-round-3/0.
> * The complete HA non-rolling-upgrade test passes.
> h3. Evidence from the ad-hoc validation
> * Nine new OM SST files were observed across three compaction rounds; all
> reported format_version 5.
> * After downgrade, Ozone 2.2.0 successfully read format-round-3/0.
> * The complete Robot Framework run finished with 77 passed, 0 failed.
> h3. Proof boundary
> This is an end-to-end database reopen and data-read test: RocksDB 7.7.3
> starts against the same database after RocksDB 10.10.1.1 wrote and compacted
> SSTs, then serves data written by 2.3.0. The format inspector reads each
> copied SST with RocksDB 10.10.1.1 to verify format_version 5. The test does
> not separately open every copied SST with RocksDB 7.7.3, and it does not map
> format-round-3/0 to one specific inspected SST.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
