[
https://issues.apache.org/jira/browse/IGNITE-17302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17302:
-------------------------------------
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-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.
was:
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 -
> 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
> Priority: Major
> Labels: ignite-3, transaction3_rw
>
> 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)
