[jira] [Commented] (IGNITE-19955) Fix create zone on restart rewrites existing data nodes because of trigger key inconsistnecy

2023-12-14 Thread Sergey Uttsel (Jira) 


[ 
https://issues.apache.org/jira/browse/IGNITE-19955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796615#comment-17796615
 ] 

Sergey Uttsel commented on IGNITE-19955:


LGTM

> 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
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Outdated, see UPD
> 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)

[jira] [Commented] (IGNITE-19955) Fix create zone on restart rewrites existing data nodes because of trigger key inconsistnecy

2023-12-14 Thread Vladislav Pyatkov (Jira) 


[ 
https://issues.apache.org/jira/browse/IGNITE-19955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796631#comment-17796631
 ] 

Vladislav Pyatkov commented on IGNITE-19955:


Merged ba6cd4dfff0e4bc2eacb437a1331454e030bff84

> 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
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Outdated, see UPD
> 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)