[
https://issues.apache.org/jira/browse/IGNITE-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-16488:
----------------------------------
Description:
Look at the property
{code:java}
IgniteImpl#METADATA_DIFFERENCE
{code}
It means the metadata revision on start should differ from distributed revision
for less than this value, and the node should apply metastorage changes on
recovery before joining logical topology, trying to catch this difference.
For now, this property is just a hardcoded constant.
Actually, its optimal value depends on a pressure of metastorage changes that
are being applied to the cluster while the node is recovering. If there are no
changes happening, seems the best way is to catch the exact metastorage
revision before joining, and in the opposite case, if there are too many
changes and the node is failing to keep up, or the node is just too slow, it
might make sense to allow greater difference, to speed up the node join.
We can think about the dynamic heuristics for this value that could be a
derivative of metastorage changes count per period of time.
Also there should be periodic log messaging during recovery to let users know
what is happening to the node, and make decisions about further waiting for
join or killing the node if it has no chance to catch up.
was:
Look at the property
{code}
IgniteImpl#METADATA_DIFFERENCE
{code}
It means the metadata revision on start should be difference from distributed
revision less than this value.
This value should be moved to the node configuration, because it might be used
for tuning.
> Make property of revision deviation adjustable
> ----------------------------------------------
>
> Key: IGNITE-16488
> URL: https://issues.apache.org/jira/browse/IGNITE-16488
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
>
> Look at the property
> {code:java}
> IgniteImpl#METADATA_DIFFERENCE
> {code}
> It means the metadata revision on start should differ from distributed
> revision for less than this value, and the node should apply metastorage
> changes on recovery before joining logical topology, trying to catch this
> difference.
> For now, this property is just a hardcoded constant.
> Actually, its optimal value depends on a pressure of metastorage changes that
> are being applied to the cluster while the node is recovering. If there are
> no changes happening, seems the best way is to catch the exact metastorage
> revision before joining, and in the opposite case, if there are too many
> changes and the node is failing to keep up, or the node is just too slow, it
> might make sense to allow greater difference, to speed up the node join.
> We can think about the dynamic heuristics for this value that could be a
> derivative of metastorage changes count per period of time.
> Also there should be periodic log messaging during recovery to let users know
> what is happening to the node, and make decisions about further waiting for
> join or killing the node if it has no chance to catch up.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
