[
https://issues.apache.org/jira/browse/IGNITE-18527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18527:
-------------------------------------
Description:
h3. Motivation
In order to have an ability for primary replica not to be collocated with raft
leader it's required to populate primary replica's data storage and indices
with corresponding updates directly, bypassing the replication protocol.
Basically speaking it's required to perform handleUpdateCommand,
handleUpdateAllCommand logic from within handling replica request and not raft
command itself. It's required in order to perform straight non-raft data reads
from primary replica, meaning that if leader ins't collocated with primary
replica it's possible that write will be considered as finished without
populating primary replica's state machine and thus dataStorage with
corresponding write command.
h3. Definition of Done
* It's possible to consistently read data from primary replica event if it's
not collocated with the leader.
* There are no conflicts during re-applying a writeIntent within in-raft
communication on top of the same already existing one that was created during
primary replica caching process.
* Given write intents are cleaned up on tx rollback.
h3. Implementation Notes
It worth to mention that re-applying a write intents may be tricky. The rest
seems to be quite simple.
was:
h3. Motivation
In order to have an ability for primary replica not to be collocated with raft
leader it's required to populate primary replica's data storage and indices
with corresponding updates directly, bypassing the replication protocol.
Basically speaking it's required to perform handleUpdateCommand,
handleUpdateAllCommand logic from within handling replica request and not raft
command itself. It's required in order to perform straight non-raft data reads
from primary replica, meaning that if leader ins't collocated with primary
replica it's possible that write will be considered as finished without
populating primary replica's state machine and thus dataStorage with
corresponding write command.
h3. Definition of Done
* It's possible to consistently read data from primary replica event if it's
not collocated with the leader.
* There are no conflicts during re-applying a writeIntent within in-raft
communication on top of the same already existing one that was created during
primary replica caching process.
* Given write intents are cleaned up on tx rollback.
> Inline writeIntents into data storage on primary replica side
> -------------------------------------------------------------
>
> Key: IGNITE-18527
> URL: https://issues.apache.org/jira/browse/IGNITE-18527
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In order to have an ability for primary replica not to be collocated with
> raft leader it's required to populate primary replica's data storage and
> indices with corresponding updates directly, bypassing the replication
> protocol. Basically speaking it's required to perform handleUpdateCommand,
> handleUpdateAllCommand logic from within handling replica request and not
> raft command itself. It's required in order to perform straight non-raft data
> reads from primary replica, meaning that if leader ins't collocated with
> primary replica it's possible that write will be considered as finished
> without populating primary replica's state machine and thus dataStorage with
> corresponding write command.
> h3. Definition of Done
> * It's possible to consistently read data from primary replica event if it's
> not collocated with the leader.
> * There are no conflicts during re-applying a writeIntent within in-raft
> communication on top of the same already existing one that was created during
> primary replica caching process.
> * Given write intents are cleaned up on tx rollback.
> h3. Implementation Notes
> It worth to mention that re-applying a write intents may be tricky. The rest
> seems to be quite simple.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
