Details
-
Story
-
Status: Complete
-
Medium
-
Resolution: Done
-
None
-
None
-
None
-
None
-
Sprint 18.05, 18.06
Description
Taken into account our agreement about refactoring with breaking changes, I believe we have a good time for migration from LevelDB to RocksDB because of the following:
- Migration to RocksDB requires migration (modification) of the ledger. We are going to migrate the ledger in any case (hopefully the last time) for refactoring, so we can combine it with RocksDB support, so no more migrations are needed in future.
- I thing migration to RocksDB should not take much time, since Dmitry did a PoC, and everything worked. We just need to merge the old branch rocksdb-integration.
- We have new resources for this work.
- It will fix bugs like
INDY-1182, since it's possible to access RocksDB from other process in read only mode (it's not possible for Leveldb, that's why read_ledger script has to create a tmp copy of the ledger which is ugly, will not work for big ledgers, and has some problems for NFS mounted systems). - RocksDB has snapshots support, which can help us in more efficient ledger catch-up.
- RocksDB works well on Windows
What needs to be done:
- Implement RocksDB implementation of key-value storage
- Integrate RocksDB into CI and CD
- Create migration script from leveldb to rocksdb
- Adapt `read_ledger` script to work with RocksDB and avoid creation of the ledger's copy
Attachments
Issue Links
- blocks
-
INDY-1219 validator-info and read_ledger give inconsistent responses in node on provisional
-
- Complete
-
-
INDY-1138 [Revocation] Support getting state root by timestamp
-
- Complete
-
-
INDY-1182 read_ledger exception on NFS mounted file system
-
- Complete
-
- relates to
-
INDY-1243 Read-ledger without storage copy in case of RocksDB (RocksDB read-only mode support)
-
- Complete
-
-
INDY-1244 Migration from LevelDB to RocksDB
-
- Complete
-
-
INDY-1245 Tune RocksDB options for the best performance
-
- Complete
-