[
https://issues.apache.org/jira/browse/IGNITE-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634303#comment-17634303
]
Aleksandr Polovtcev commented on IGNITE-18070:
----------------------------------------------
When implementing option 2, we have the following challenges:
# A node that hosts both a follower and a learner gets split, e.g. a learner
gets assigned to a different Ignite node. This case is pretty straightforward:
we can simply start the learner on the second node (data will be transferred to
it via Raft), but we need to destroy the old storage from the first node. Looks
like it can be done after the rebalance procedure completes, after Stable
Assignments Metastorage key gets updated and Raft groups are stopped.
# A node that hosts a follower and a node that hosts a learner get merged into
one. This is a tricky case, because we need to request a snapshot from the
leader (however, a leaner may copy the data from the follower it gets merge
into, but that is out of scope now), while buffering the incoming update and
avoiding corrupting the already existing raft log. I currently have no idea how
to do that, it requires additional investigation.
> Design the process of having a single storage for a follower and a learner on
> the same node
> -------------------------------------------------------------------------------------------
>
> Key: IGNITE-18070
> URL: https://issues.apache.org/jira/browse/IGNITE-18070
> Project: Ignite
> Issue Type: Task
> Reporter: Aleksandr Polovtcev
> Assignee: Aleksandr Polovtcev
> Priority: Major
> Labels: ignite-3
>
> Secondary Storage consistency is going to be implemented through the Raft
> Learners. However, there exists a challenge: what if a partition's Primary
> Storage will be assigned to the same node as its Secondary Storage? This
> means that both a follower and learner for the same partition will be hosted
> on a single node with the same consistent ID. Currently JRaft is not able to
> distinguish two nodes with the same consistent ID. There are two ways to
> solve this problem:
> # Use {{PeerId#idx}} functionality. This is a built-in JRaft mechanism to
> have multiple Raft nodes on a single physical nodes.
> # Use a single Raft node that will write into multiple storages.
> While option 1 is easy and straightforward to implement, this ticket focuses
> on investigation of the option 2. The second option has a priority because it
> is potentially more effective: since there will be less Raft nodes, there
> will be less network traffic. The main problem with this approach is when a
> learner or a follower hosted on such physical node gets moved to a different
> physical node (or two nodes get merged into one). We should check if this is
> technically possible to implement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
