[
https://issues.apache.org/jira/browse/IGNITE-21316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21316:
---------------------------------------
Description:
ItRebalanceDistributedTest creates tables by going directly to the
CatalogManager, so it skips schema sync logic. This has to be fixed.
Also, integration tests are to be written to demonstrate that for DDLs executed
via SQL API, schema sync is executed correctly.
h3. Old version of the description follows, but it's incorrect: schema sync is
already made for every SQL query, including DDL ones
-When executing an DDL operation on one node and then executing another
operation (depending on the first operation to finish) on another node, the
second operation might not see the first operation results.-
-For example, if we create a zone via node A, wait for the DDL future to
complete and then we try to create a table using that new zone via node B, the
table creation might fail because node B does not see the newly-created zone
yet.-
-This is because the zone creation future only makes us wait for all activation
timestamp to become non-future on all clocks on the cluster, but when this
happens, there is no guarantee that all nodes actually received the new catalog
version.-
-To fix this, we need to do a schema sync for timestamp equal to 'now' before
doing any DDL operation.-
-This should probably be done in the DDL handler (but maybe it makes sense to
do it in the `execute()` method of the CatalogManager).-
-An example of a test demonstrating the problem is
ItRebalanceDistributedTest.testOnLeaderElectedRebalanceRestart(). But this test
also has another problem: it interacts with the CatalogManager directly. If we
add the fix above the CatalogManager, the test will have to be fixed to do
schema sync by hand.-
was:
When executing an DDL operation on one node and then executing another
operation (depending on the first operation to finish) on another node, the
second operation might not see the first operation results.
For example, if we create a zone via node A, wait for the DDL future to
complete and then we try to create a table using that new zone via node B, the
table creation might fail because node B does not see the newly-created zone
yet.
This is because the zone creation future only makes us wait for all activation
timestamp to become non-future on all clocks on the cluster, but when this
happens, there is no guarantee that all nodes actually received the new catalog
version.
To fix this, we need to do a schema sync for timestamp equal to 'now' before
doing any DDL operation.
This should probably be done in the DDL handler (but maybe it makes sense to do
it in the `execute()` method of the CatalogManager).
An example of a test demonstrating the problem is
ItRebalanceDistributedTest.testOnLeaderElectedRebalanceRestart(). But this test
also has another problem: it interacts with the CatalogManager directly. If we
add the fix above the CatalogManager, the test will have to be fixed to do
schema sync by hand.
> Do schema sync before executing a DDL operation
> -----------------------------------------------
>
> Key: IGNITE-21316
> URL: https://issues.apache.org/jira/browse/IGNITE-21316
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> ItRebalanceDistributedTest creates tables by going directly to the
> CatalogManager, so it skips schema sync logic. This has to be fixed.
> Also, integration tests are to be written to demonstrate that for DDLs
> executed via SQL API, schema sync is executed correctly.
> h3. Old version of the description follows, but it's incorrect: schema sync
> is already made for every SQL query, including DDL ones
> -When executing an DDL operation on one node and then executing another
> operation (depending on the first operation to finish) on another node, the
> second operation might not see the first operation results.-
> -For example, if we create a zone via node A, wait for the DDL future to
> complete and then we try to create a table using that new zone via node B,
> the table creation might fail because node B does not see the newly-created
> zone yet.-
> -This is because the zone creation future only makes us wait for all
> activation timestamp to become non-future on all clocks on the cluster, but
> when this happens, there is no guarantee that all nodes actually received the
> new catalog version.-
> -To fix this, we need to do a schema sync for timestamp equal to 'now' before
> doing any DDL operation.-
> -This should probably be done in the DDL handler (but maybe it makes sense to
> do it in the `execute()` method of the CatalogManager).-
> -An example of a test demonstrating the problem is
> ItRebalanceDistributedTest.testOnLeaderElectedRebalanceRestart(). But this
> test also has another problem: it interacts with the CatalogManager directly.
> If we add the fix above the CatalogManager, the test will have to be fixed to
> do schema sync by hand.-
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
