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)