[
https://issues.apache.org/jira/browse/IGNITE-26798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-26798:
-------------------------------------
Description:
*Description*
In IGNITE-26425 there was a change that made default zone created lazily. This
will lead to better cluster start experience, but still the issues arise: let's
assume a user created one or more zones for it's production database, but
forgot to set any as default. Then if user will execute standard SQL create
table statement without zone specification then cluster will create excessive
default zone and will place table and probably data in this wrong (implicit)
zone.
*Motivation*
There are 2 user mistakes: at first user forgot to do {{alter zone .. set
default}}, and the last is {{create table .. }} without zone. Let's consider
both issues separately.
What we can do with forgotten {{alter zone}} without any default zone set
(means there no table that was created without specified zone and there no more
zone in cluster)? We may mark the first created zone as default. This solution
contains 2 caveats:
# It's implicit action that is the type of behavior we're trying to remove:
assume that user created several zone and didn't noticed/forgot of this
implicit rule; user script will throw no exception, but all tables without
specified zone will be created in the first created zone with it's data that
highly likely will be unwanted as behavior and all process will be redone by
user that may didn't notice about the fact that all data will be placed on the
first zone (no exception is thrown!).
# This workaround doesn't defend us from empty default zone: if later user will
remove the first created zone, then without explicit alteration of the existed
ones we will have no default zone; also this behavior is presented right now
with pre-created default zone too.
So, looks like we shouldn't do this action implicit, also we may consider to
add an option to set default property with {{create zone}} DDL statement, but
this is out of scope.
Then, the last mistake is {{create table ..}} without zone while there are set
of already created zone. Now we'll create a special fully default zone just to
comply standard DDL statement for table creation and in implicit way. Instead
of failure with suggestion message about both kind of mistake like: {{There are
several existing zones, specify any as table's zone or alter any zone as
default zone [zones=[us_zone, eu_zone, apac_zone]].}}. We don't create a zone
with default options for {{create table ... zone unexisted_zone}}, we warn user
about a potential mistake. It's explicit way to solve this type of user input
mistake.
And the last but not least we may compare user's effort to solve this scenarios
with both solutions (implicit vs explicit).
Let's assume that user expects implicit behavior with {{create table new_table;
insert into new_table (id, val) values ...;}} script. Then user will fail with
the message and will do any of one action: {{alter zone eu_zone set default}}
or add zone in the script {{create table new_table zone eu_zone; insert into
new_table (id, val) values ...;}} or will create explicitly new zone with
defaults and alter it as default {{create zone default_zone storage profiles
['default']; alter zone default_zone set default;}} and the script will works
as expected. Notice that user had been warned and shouldn't do any undo actions
like zone/table drop or something.
Otherwise let's assume that user expects explicit behavior with the same
script. The script will be executed successfully, but after a time user will
find that instead of any warning the new table will be created in newly created
{{Default}} zone without any filter applied and user's customers in EU zone
struggles with data access. Then user have to create in parallel with wrongly
allocated resources new table (name collision should be solved), migrate data
from wrong table, drop the wrong table and unnecessary {{Default}} zone. Much
more problems just because potentially wrong script passed validation.
Previously started cluster will face no any compatibility issues because there
is already created default zones on catalog initialization or user's custom
zones set is provided. The only change is the behavior on newly started
clusters.
*Definition of Done*
# In case if there no default zone, no specified zone name for create table
catalog command and non empty existing zone set in catalog, the we have to
throw {{CatalogValidationException}} with the message that contains suggestion
how to fix user's create table statement.
# Corresponding tests on catalog create table command and validations should be
provided.
# Broken tests should be fixed, mostly by altering created in test zone as
default.
was:
*Description*
In IGNITE-26425 there was a change that made default zone created lazily. This
will lead to better cluster start experience, but still the issues arise: let's
assume a user created one or more zones for it's production database, but
forgot to set any as default. Then if user will execute standard SQL create
table statement without zone specification then cluster will create excessive
default zone and will place table and probably data in this wrong (implicit)
zone.
*Motivation*
There are 2 user mistakes: at first user forgot to do {{alter zone .. set
default}}, and the last is {{create table .. }} without zone. Let's consider
both issues separately.
What we can do with forgotten {{alter zone}} without any default zone set
(means there no table that was created without specified zone and there no more
zone in cluster)? We may mark the first created zone as default. This solution
contains 2 caveats:
# It's implicit action that is the type of behavior we're trying to remove:
assume that user created several zone and didn't noticed/forgot of this
implicit rule; user script will throw no exception, but all tables without
specified zone will be created in the first created zone with it's data that
highly likely will be unwanted as behavior and all process will be redone by
user that may didn't notice about the fact that all data will be placed on the
first zone (no exception is thrown!).
# This workaround doesn't defend us from empty default zone: if later user will
remove the first created zone, then without explicit alteration of the existed
ones we will have no default zone; also this behavior is presented right now
with pre-created default zone too.
So, looks like we shouldn't do this action implicit, also we may consider to
add an option to set default property with {{create zone}} DDL statement, but
this is out of scope.
Then, the last mistake is {{create table ..}} without zone while there are set
of already created zone. Now we'll create a special fully default zone just to
comply standard DDL statement for table creation and in implicit way. Instead
of failure with suggestion message about both kind of mistake like: {{There are
several existing zones, specify any as table's zone or alter any zone as
default zone [zones=[us_zone, eu_zone, apac_zone]].}}. We don't create a zone
with default options for {{create table ... zone unexisted_zone}}, we warn user
about a potential mistake. It's explicit way to solve this type of user input
mistake.
And the last but not least we may compare user's effort to solve this scenarios
with both solutions (implicit vs explicit).
Let's assume that user expects implicit behavior with {{create table new_table;
insert into new_table (id, val) values ...;}} script. Then user will fail with
the message and will do any of one action: {{alter zone eu_zone set default}}
or add zone in the script {{create table new_table zone eu_zone; insert into
new_table (id, val) values ...;}} or will create explicitly new zone with
defaults and alter it as default {{create zone default_zone storage profiles
['default']; alter zone default_zone set default;}} and the script will works
as expected. Notice that user had been warned and shouldn't do any undo actions
like zone/table drop or something.
Otherwise let's assume that user expects explicit behavior with the same
script. The script will be executed successfully, but after a time user will
find that instead of any warning the new table will be created in newly created
{{Default}} zone without any filter applied and user's customers in EU zone
struggles with data access. Then user have to create in parallel with wrongly
allocated resources new table (name collision should be solved), migrate data
from wrong table, drop the wrong table and unnecessary {{Default}} zone. Much
more problems just because potentially wrong script passed validation.
*Definition of Done*
# In case if there no default zone, no specified zone name for create table
catalog command and non empty existing zone set in catalog, the we have to
throw {{CatalogValidationException}} with the message that contains suggestion
how to fix user's create table statement.
# Corresponding tests on catalog create table command and validations should be
provided.
> Throw validation exception for attempts to create table without specified
> zone nor default zone but there are existing zones
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-26798
> URL: https://issues.apache.org/jira/browse/IGNITE-26798
> Project: Ignite
> Issue Type: Improvement
> Reporter: Mikhail Efremov
> Assignee: Mikhail Efremov
> Priority: Major
> Labels: ignite-3
>
> *Description*
> In IGNITE-26425 there was a change that made default zone created lazily.
> This will lead to better cluster start experience, but still the issues
> arise: let's assume a user created one or more zones for it's production
> database, but forgot to set any as default. Then if user will execute
> standard SQL create table statement without zone specification then cluster
> will create excessive default zone and will place table and probably data in
> this wrong (implicit) zone.
> *Motivation*
> There are 2 user mistakes: at first user forgot to do {{alter zone .. set
> default}}, and the last is {{create table .. }} without zone. Let's consider
> both issues separately.
> What we can do with forgotten {{alter zone}} without any default zone set
> (means there no table that was created without specified zone and there no
> more zone in cluster)? We may mark the first created zone as default. This
> solution contains 2 caveats:
> # It's implicit action that is the type of behavior we're trying to remove:
> assume that user created several zone and didn't noticed/forgot of this
> implicit rule; user script will throw no exception, but all tables without
> specified zone will be created in the first created zone with it's data that
> highly likely will be unwanted as behavior and all process will be redone by
> user that may didn't notice about the fact that all data will be placed on
> the first zone (no exception is thrown!).
> # This workaround doesn't defend us from empty default zone: if later user
> will remove the first created zone, then without explicit alteration of the
> existed ones we will have no default zone; also this behavior is presented
> right now with pre-created default zone too.
> So, looks like we shouldn't do this action implicit, also we may consider to
> add an option to set default property with {{create zone}} DDL statement, but
> this is out of scope.
> Then, the last mistake is {{create table ..}} without zone while there are
> set of already created zone. Now we'll create a special fully default zone
> just to comply standard DDL statement for table creation and in implicit way.
> Instead of failure with suggestion message about both kind of mistake like:
> {{There are several existing zones, specify any as table's zone or alter any
> zone as default zone [zones=[us_zone, eu_zone, apac_zone]].}}. We don't
> create a zone with default options for {{create table ... zone
> unexisted_zone}}, we warn user about a potential mistake. It's explicit way
> to solve this type of user input mistake.
> And the last but not least we may compare user's effort to solve this
> scenarios with both solutions (implicit vs explicit).
> Let's assume that user expects implicit behavior with {{create table
> new_table; insert into new_table (id, val) values ...;}} script. Then user
> will fail with the message and will do any of one action: {{alter zone
> eu_zone set default}} or add zone in the script {{create table new_table zone
> eu_zone; insert into new_table (id, val) values ...;}} or will create
> explicitly new zone with defaults and alter it as default {{create zone
> default_zone storage profiles ['default']; alter zone default_zone set
> default;}} and the script will works as expected. Notice that user had been
> warned and shouldn't do any undo actions like zone/table drop or something.
> Otherwise let's assume that user expects explicit behavior with the same
> script. The script will be executed successfully, but after a time user will
> find that instead of any warning the new table will be created in newly
> created {{Default}} zone without any filter applied and user's customers in
> EU zone struggles with data access. Then user have to create in parallel with
> wrongly allocated resources new table (name collision should be solved),
> migrate data from wrong table, drop the wrong table and unnecessary
> {{Default}} zone. Much more problems just because potentially wrong script
> passed validation.
> Previously started cluster will face no any compatibility issues because
> there is already created default zones on catalog initialization or user's
> custom zones set is provided. The only change is the behavior on newly
> started clusters.
> *Definition of Done*
> # In case if there no default zone, no specified zone name for create table
> catalog command and non empty existing zone set in catalog, the we have to
> throw {{CatalogValidationException}} with the message that contains
> suggestion how to fix user's create table statement.
> # Corresponding tests on catalog create table command and validations should
> be provided.
> # Broken tests should be fixed, mostly by altering created in test zone as
> default.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
