[
https://issues.apache.org/jira/browse/IGNITE-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18121:
-------------------------------------
Description:
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 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.
> Introduce scale up scheduler
> ----------------------------
>
> Key: IGNITE-18121
> URL: https://issues.apache.org/jira/browse/IGNITE-18121
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> 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 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)
