[
https://issues.apache.org/jira/browse/IGNITE-19955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19955:
---------------------------------
Description:
Currently we have the logic for initialisation of newly created zone that it
writes keys
{noformat}
zoneDataNodesKey(zoneId), zoneScaleUpChangeTriggerKey(zoneId),
zoneScaleDownChangeTriggerKey(zoneId), zonesChangeTriggerKey(zoneId)
{noformat}
to metastorage, and condition is
{noformat}
static CompoundCondition triggerKeyConditionForZonesChanges(long revision,
int zoneId) {
return or(
notExists(zonesChangeTriggerKey(zoneId)),
value(zonesChangeTriggerKey(zoneId)).lt(ByteUtils.longToBytes(revision))
);
{noformat}
Recovery process implies that the create zone event will be processed again,
but with the higher revision, so data nodes will be rewritten.
We need to handle this situation, so data nodes will be consistent after
restart.
Possible solution is to change condition to
{noformat}
static SimpleCondition triggerKeyConditionForZonesCreation(long revision,
int zoneId) {
return notExists(zonesChangeTriggerKey(zoneId));
}
static SimpleCondition triggerKeyConditionForZonesDelete(int zoneId) {
return exists(zonesChangeTriggerKey(zoneId));
}
{noformat}
so we could not rely on revision and check only existence of the key, when we
create or remove zone. The problem in this solution is that reordering of the
create and remove on some node could lead to not consistent state for zones key
in metastorage
*UPD*:
This problem will be resolves once we implement
https://issues.apache.org/jira/browse/IGNITE-20561
In this ticket we need to unmute all tickets that were muted by this ticket
was:
Currently we have the logic for initialisation of newly created zone that it
writes keys
{noformat}
zoneDataNodesKey(zoneId), zoneScaleUpChangeTriggerKey(zoneId),
zoneScaleDownChangeTriggerKey(zoneId), zonesChangeTriggerKey(zoneId)
{noformat}
to metastorage, and condition is
{noformat}
static CompoundCondition triggerKeyConditionForZonesChanges(long revision,
int zoneId) {
return or(
notExists(zonesChangeTriggerKey(zoneId)),
value(zonesChangeTriggerKey(zoneId)).lt(ByteUtils.longToBytes(revision))
);
{noformat}
Recovery process implies that the create zone event will be processed again,
but with the higher revision, so data nodes will be rewritten.
We need to handle this situation, so data nodes will be consistent after
restart.
Possible solution is to change condition to
{noformat}
static SimpleCondition triggerKeyConditionForZonesCreation(long revision,
int zoneId) {
return notExists(zonesChangeTriggerKey(zoneId));
}
static SimpleCondition triggerKeyConditionForZonesDelete(int zoneId) {
return exists(zonesChangeTriggerKey(zoneId));
}
{noformat}
so we could not rely on revision and check only existence of the key, when we
create or remove zone. The problem in this solution is that reordering of the
create and remove on some node could lead to not consistent state for zones key
in metastorage
UPD:
This problem will be resolves once we implement
https://issues.apache.org/jira/browse/IGNITE-20561
In this ticket we need to unmute all tickets that were muted by this ticket
> Fix create zone on restart rewrites existing data nodes because of trigger
> key inconsistnecy
> --------------------------------------------------------------------------------------------
>
> Key: IGNITE-19955
> URL: https://issues.apache.org/jira/browse/IGNITE-19955
> Project: Ignite
> Issue Type: Bug
> Reporter: Mirza Aliev
> Priority: Major
> Labels: ignite-3
>
> Currently we have the logic for initialisation of newly created zone that it
> writes keys
> {noformat}
> zoneDataNodesKey(zoneId), zoneScaleUpChangeTriggerKey(zoneId),
> zoneScaleDownChangeTriggerKey(zoneId), zonesChangeTriggerKey(zoneId)
> {noformat}
> to metastorage, and condition is
> {noformat}
> static CompoundCondition triggerKeyConditionForZonesChanges(long
> revision, int zoneId) {
> return or(
> notExists(zonesChangeTriggerKey(zoneId)),
>
> value(zonesChangeTriggerKey(zoneId)).lt(ByteUtils.longToBytes(revision))
> );
> {noformat}
> Recovery process implies that the create zone event will be processed again,
> but with the higher revision, so data nodes will be rewritten.
> We need to handle this situation, so data nodes will be consistent after
> restart.
> Possible solution is to change condition to
> {noformat}
> static SimpleCondition triggerKeyConditionForZonesCreation(long revision,
> int zoneId) {
> return notExists(zonesChangeTriggerKey(zoneId));
> }
> static SimpleCondition triggerKeyConditionForZonesDelete(int zoneId) {
> return exists(zonesChangeTriggerKey(zoneId));
> }
> {noformat}
>
> so we could not rely on revision and check only existence of the key, when we
> create or remove zone. The problem in this solution is that reordering of the
> create and remove on some node could lead to not consistent state for zones
> key in metastorage
> *UPD*:
> This problem will be resolves once we implement
> https://issues.apache.org/jira/browse/IGNITE-20561
> In this ticket we need to unmute all tickets that were muted by this ticket
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
