[
https://issues.apache.org/jira/browse/IGNITE-17302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625672#comment-17625672
]
Alexander Lapin commented on IGNITE-17302:
------------------------------------------
[~maliev] LGTM from my side.
> Raft listener multi-storage support
> ------------------------------------
>
> Key: IGNITE-17302
> URL: https://issues.apache.org/jira/browse/IGNITE-17302
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Mirza Aliev
> Priority: Major
> Labels: ignite-3, transaction3_rw
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> 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-16907 for 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
