[jira] [Commented] (IGNITE-18070) Design the process of having a single storage for a follower and a learner on the same node

["Aleksandr Polovtcev (Jira)" <ji...@apache.org>]

    [ 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)