You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexander Lapin (Jira)" <ji...@apache.org> on 2023/01/26 12:17:00 UTC

[jira] [Updated] (IGNITE-18121) Introduce scale up scheduler

     [ https://issues.apache.org/jira/browse/IGNITE-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lapin updated IGNITE-18121:
-------------------------------------
    Fix Version/s: 3.0.0-beta2

> Introduce scale up scheduler
> ----------------------------
>
>                 Key: IGNITE-18121
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18121
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Assignee: Mirza Aliev
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> h3. Motivation
> Within  IGNITE-18115 reaction to the topology events was introduced as an immediate ms.invoke that will try to update zones.<zone>.dataNodes key. In fact, we should defer state recalculation for some time specified by the user in order to accumulate contiguous  topology events. Please check following example for more details:
> |1|start Node A;
> start Node B;
> start Node C;
> CREATE ZONE zone1 WITH   DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300;
> CREATE TABLE Accounts … WITH  PRIMARY_ZONE = zone1 |User starts three Ignite nodes A, B, C and creates table Accounts specifying scale up auto adjust timeout as 300 seconds. Accounts table is created on current topology, meaning that <Transaction>.dataNodes = [A,B,C]|
> |0|start Node D ->
>     Node D join/validation ->
>     D enters logical topology ->
>     logicalTopology.onNodeAdded(Node D) ->
>     scale_up_auto_adjust(300) timer is
>     scheduled for the <Accounts> table.|At time 0 seconds the user starts one more Ignite node D, that joins the cluster. On entering logical topology the onNodeAdded event is fired. This event schedules a timer of 300 seconds for table Accounts after which the dataNodes of that table transitively through the distribution zone will be recalculated from [A,B,C] to [A,B,C,D]
>  
> |
> |250|start Node E -> 
>     scale_up_auto_adjust(300) is
>     {*}re{*}scheduled for the <Accounts> table.|At 250 seconds one more node is added, that action reschedules scale_up_auto_adjust timer for another 300 seconds.|
> |550|scale_up_auto_adjust fired ->
>     set table.<Accounts>.dataNodes = 
>     [NodeA, NodeB, NodeC, Node D, Node E]|At 550 seconds scale_up_time is fired, that leads to <Transaction>dataNodes recalculation by attaching the nodes that were added to logical topology - Nodes D and E in the given example.|
> |600|start Node F ->
>      <Accounts> table schedules   
>      scale_up_auto_adjust(300);|At 600 seconds one more node is added, there are no active scale_up_auto_adjust timers, so given events schedules new one.|
>  
> Thus it's required to modify ms topology handler in a way that it should schedule or re-schedule a timer that will eventually call ms.invoke(dataNodes).
> h3. Definition of Done
>  * DataNodes recalculation transitively triggered by node add event is delayed for dataNodesAutoAdjustScaleUp value.
>  * In case of new scale up toplogy event, existing scale up timers should be re-scheduled.
> h3. Implemention Notes
> As usual, pretty straight forward,  ScheduledExecutorService with proper naming should be introduced. Busy locks and proper scheduler stopping required.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)