Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
It's supposed that replication state machine (e.g. RaftGroupListener) will handle multiple storages. For example PartitionListener will use:
- MvPartitionStorage - common multi-version partition storage for core partition data.
- Both volatile and persistent lock storages
IGNITE-15932. - Persistent storage for txn state
IGNITE-15931. - Index storages.
Generally speaking replication logic is decoupled from data-storages, and there are only few intersection points:
- Raft log truncation - in order to safely truncate raft log it's required to take into consideration all checkpointIndexes for all storages of the given state machine and perform min(storage1.checkpointIndex, storage2.checkpointIndex, ... ) truncation. Besides that it's important for storages to skip already applied commands on raft log replay - storage indexes to the rescue. See
IGNITE-16907for more details. Such modifications will also effect PartitionListener.onSnapshotLoad()/onSnapshotSave() methods. - It's required to update local node recovery process a bit: a node must enter the logical topology only after restoring all local raft nodes, including both restoring storages from corresponding snapshot and applying raft log.
Attachments
Issue Links
- is blocked by
-
IGNITE-15931 Implement storage for tx states
- Resolved
-
IGNITE-15932 Implement storage for locks
- Resolved
-
IGNITE-16907 Add ability to use Raft log as storage WAL within the scope of local recovery
- Resolved
- is depended upon by
-
IGNITE-17770 ItIgniteNodeRestartTest.testCfgGap is flaky
- Resolved
- is duplicated by
-
IGNITE-17983 Fix work with the last applied index in RAFT
- Resolved
- links to