Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
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.
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.
Implementation Notes
It worth to mention that :
- Re-applying a write intents may be tricky.
- And besides that we must ensure that adding writeIntent initiated by replication message is linearized with tx cleanup on rollback.
the rest seems to be quite simple.
Attachments
Issue Links
- links to
