[jira] [Updated] (IGNITE-21084) Account for differences of logical part of now() on different nodes when waiting after a DDL

2023-12-15 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-21084:
---
Reviewer: Konstantin Orlov

> Account for differences of logical part of now() on different nodes when 
> waiting after a DDL
> 
>
> Key: IGNITE-21084
> URL: https://issues.apache.org/jira/browse/IGNITE-21084
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Client must see the results of a DDL they just executed, no matter through 
> which node of the cluster a subsequent request is made. To maintain this, we 
> must make sure that ActivationTimestamp(DDL) becomes non-future on all nodes 
> of the cluster and only then can we complete the DDL future. As nodes' 
> physical clocks might have some skew relatively to each other, we add 
> MaxClockSkew to the timestamp till which we wait to compensate for this 
> difference.
> Analogously to HLC.now() being different because its physical part differs on 
> different nodes, it might be different because *logical* parts are different 
> on different nodes.
> Let's assume we don't have any physical clock skew, and MaxClockSkew is 0. 
> ActivationTimestamp(DDL) is (100, 5); (100 is physical part, 5 is logical 
> part). We wait on node 1 (through which the DDL was executed) till its 
> HLC.now() reaches (100, 5), then we complete the DDL future. The user goes to 
> node 2 at which HLC.now() is (100, 2). The user executes a query at 'now', 
> and the query sees the state before the DDL was executed, which breaks our 
> requirement.
> We can fix this by 'rounding' the timestamp-to-wait-for up in the following 
> way:
>  # If logical part is not 0, increment the physical part and set the logical 
> part to 0
>  # If the logical part is 0, leave the timestamp as is
> As a result, for (100, 0) we will wait for (100, 0), and at node 1 HLC is at 
> least (100, 0), so it cannot see the previous schema. For (100, 5) we would 
> wait till (101, 0), which would also guarantee that a query executed after 
> waiting sees the new schema version.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-21084) Account for differences of logical part of now() on different nodes when waiting after a DDL

2023-12-14 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-21084:
---
Description: 
Client must see the results of a DDL they just executed, no matter through 
which node of the cluster a subsequent request is made. To maintain this, we 
must make sure that ActivationTimestamp(DDL) becomes non-future on all nodes of 
the cluster and only then can we complete the DDL future. As nodes' physical 
clocks might have some skew relatively to each other, we add MaxClockSkew to 
the timestamp till which we wait to compensate for this difference.

Analogously to HLC.now() being different because its physical part differs on 
different nodes, it might be different because *logical* parts are different on 
different nodes.

Let's assume we don't have any physical clock skew, and MaxClockSkew is 0. 
ActivationTimestamp(DDL) is (100, 5); (100 is physical part, 5 is logical 
part). We wait on node 1 (through which the DDL was executed) till its 
HLC.now() reaches (100, 5), then we complete the DDL future. The user goes to 
node 2 at which HLC.now() is (100, 2). The user executes a query at 'now', and 
the query sees the state before the DDL was executed, which breaks our 
requirement.

We can fix this by 'rounding' the timestamp-to-wait-for up in the following way:
 # If logical part is not 0, increment the physical part and set the logical 
part to 0
 # If the logical part is 0, leave the timestamp as is

As a result, for (100, 0) we will wait for (100, 0), and at node 1 HLC is at 
least (100, 0), so it cannot see the previous schema. For (100, 5) we would 
wait till (101, 0), which would also guarantee that a query executed after 
waiting sees the new schema version.

> Account for differences of logical part of now() on different nodes when 
> waiting after a DDL
> 
>
> Key: IGNITE-21084
> URL: https://issues.apache.org/jira/browse/IGNITE-21084
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Client must see the results of a DDL they just executed, no matter through 
> which node of the cluster a subsequent request is made. To maintain this, we 
> must make sure that ActivationTimestamp(DDL) becomes non-future on all nodes 
> of the cluster and only then can we complete the DDL future. As nodes' 
> physical clocks might have some skew relatively to each other, we add 
> MaxClockSkew to the timestamp till which we wait to compensate for this 
> difference.
> Analogously to HLC.now() being different because its physical part differs on 
> different nodes, it might be different because *logical* parts are different 
> on different nodes.
> Let's assume we don't have any physical clock skew, and MaxClockSkew is 0. 
> ActivationTimestamp(DDL) is (100, 5); (100 is physical part, 5 is logical 
> part). We wait on node 1 (through which the DDL was executed) till its 
> HLC.now() reaches (100, 5), then we complete the DDL future. The user goes to 
> node 2 at which HLC.now() is (100, 2). The user executes a query at 'now', 
> and the query sees the state before the DDL was executed, which breaks our 
> requirement.
> We can fix this by 'rounding' the timestamp-to-wait-for up in the following 
> way:
>  # If logical part is not 0, increment the physical part and set the logical 
> part to 0
>  # If the logical part is 0, leave the timestamp as is
> As a result, for (100, 0) we will wait for (100, 0), and at node 1 HLC is at 
> least (100, 0), so it cannot see the previous schema. For (100, 5) we would 
> wait till (101, 0), which would also guarantee that a query executed after 
> waiting sees the new schema version.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-21084) Account for differences of logical part of now() on different nodes when waiting after a DDL

2023-12-14 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-21084:
---
Epic Link: IGNITE-20800

> Account for differences of logical part of now() on different nodes when 
> waiting after a DDL
> 
>
> Key: IGNITE-21084
> URL: https://issues.apache.org/jira/browse/IGNITE-21084
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)