-
Notifications
You must be signed in to change notification settings - Fork 907
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
Make RrocksDB checksum type configurable #3793
Make RrocksDB checksum type configurable #3793
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3793 +/- ##
============================================
+ Coverage 60.40% 68.25% +7.85%
- Complexity 5856 6751 +895
============================================
Files 473 473
Lines 40906 40910 +4
Branches 5232 5232
============================================
+ Hits 24711 27925 +3214
+ Misses 13981 10727 -3254
- Partials 2214 2258 +44
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@Test | ||
public void testReadChecksumTypeFromBookieConfiguration() throws Exception { | ||
ServerConfiguration configuration = new ServerConfiguration(); | ||
configuration.setProperty("dbStorage_rocksDB_checksum_type", "kxxHash"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove configuration.setProperty("dbStorage_rocksDB_checksum_type", "kxxHash");
to verify the default value is kxxHash
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
558ae30
to
830d57f
Compare
### Motivation Fix apache#3734 (comment) We have two rocksDB tables, one for the ledger index, and another for the entry log location. - ledger index RocksDB table: Use the default table option, and the checksum is `kCRC32c` - entry log location RocksDb table: Use configured table option, and the checksum is `kxxHash` When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from `kCRC32c` to `kXXH3`, and `kXXH3` only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support the `kXXH3` checksum type. ### Modifications In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default `kCRC32c` to `kxxHash`. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine. After setting the two RocksDB table's checksum type to `kxxHash`, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine. ### More to discuss When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297 The related PR: facebook/rocksdb#10826 It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file. If this issue exists, we do **NOT** recommend users configure RocksDB configurations through configuration files. @merlimat @eolivelli @dlg99 Please help take a look, thanks. (cherry picked from commit 3844bf1)
### Motivation Fix apache#3734 (comment) We have two rocksDB tables, one for the ledger index, and another for the entry log location. - ledger index RocksDB table: Use the default table option, and the checksum is `kCRC32c` - entry log location RocksDb table: Use configured table option, and the checksum is `kxxHash` When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from `kCRC32c` to `kXXH3`, and `kXXH3` only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support the `kXXH3` checksum type. ### Modifications In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default `kCRC32c` to `kxxHash`. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine. After setting the two RocksDB table's checksum type to `kxxHash`, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine. ### More to discuss When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297 The related PR: facebook/rocksdb#10826 It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file. If this issue exists, we do **NOT** recommend users configure RocksDB configurations through configuration files. @merlimat @eolivelli @dlg99 Please help take a look, thanks. (cherry picked from commit 3844bf1)
### Motivation Fix apache#3734 (comment) We have two rocksDB tables, one for the ledger index, and another for the entry log location. - ledger index RocksDB table: Use the default table option, and the checksum is `kCRC32c` - entry log location RocksDb table: Use configured table option, and the checksum is `kxxHash` When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from `kCRC32c` to `kXXH3`, and `kXXH3` only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support the `kXXH3` checksum type. ### Modifications In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default `kCRC32c` to `kxxHash`. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine. After setting the two RocksDB table's checksum type to `kxxHash`, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine. ### More to discuss When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297 The related PR: facebook/rocksdb#10826 It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file. If this issue exists, we do **NOT** recommend users configure RocksDB configurations through configuration files. @merlimat @eolivelli @dlg99 Please help take a look, thanks.
Motivation
Fix #3734 (comment)
We have two rocksDB tables, one for the ledger index, and another for the entry log location.
kCRC32c
kxxHash
When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from
kCRC32c
tokXXH3
, andkXXH3
only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support thekXXH3
checksum type.Modifications
In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default
kCRC32c
tokxxHash
. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine.After setting the two RocksDB table's checksum type to
kxxHash
, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine.More to discuss
When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297
The related PR: facebook/rocksdb#10826
It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file.
If this issue exists, we do NOT recommend users configure RocksDB configurations through configuration files.
@merlimat @eolivelli @dlg99 Please help take a look, thanks.