[
https://issues.apache.org/jira/browse/IGNITE-23466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921409#comment-17921409
]
Denis Chudov edited comment on IGNITE-23466 at 1/27/25 2:41 PM:
----------------------------------------------------------------
Processing data nodes and managing them properly on topology changes and
distribution zone changes is a significant part of DZM logic. It requires
complete rework according to the ticket description.
was (Author: denis chudov):
Processing data nodes and managing them properly on topology changes and
distribution zone changes is a significant part of DZM logic. It requires
complete rework according the ticket description.
> Rework DZM internals
> --------------------
>
> Key: IGNITE-23466
> URL: https://issues.apache.org/jira/browse/IGNITE-23466
> Project: Ignite
> Issue Type: Task
> Reporter: Alexander Lapin
> Assignee: Denis Chudov
> Priority: Major
> Labels: ignite-3, important
> Fix For: 3.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In order to simply DistributionZone dataNodes processing and meet meta
> storage compaction requirements it's required not to use MG versioning.
> Generally following logic should be implemented.
> * On topology event
> ** Check whether we already have corresponding pending scaleUp/Down timer.
> If not:
> *** Serialised timer is written to MG synchronously. In timer's data bag
> it's expected to have
> **** Awake/DataNodes atomic switch timestamp.
> **** Data nodes to apply.
> *** Else:
> **** Rewrite existing timer by updating Awake/DataNodes timestamp along with
> data nodes to apply. That should be done atomically in a way that calculated
> topology event timestamp is used while comparison with already existing awake
> one.
> ** Timer is scheduled.
> * On timer
> ** Atomically remove the timer and set add new timestamp -> dataNodes entry
> in dataNodes map in MG and DZM volatile cache.
> * On node restart:
> ** restore corresponding volatile state from the MG.
> * On filter change:
> ** Immediately trigger on timer.
> * On timeout adjustments
> ** Rewrite existing timers if exists.
> There's a chance that topology and node attributes should also be internally
> versioned.
> h3. Definition of Done
> * DZM manages dataNodes and related history internally in last MG key like
> Catalog does.
> * New robust mechanic of atomic timers to dataNodes application is used.
> Details are described in Motivation section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
