You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Айсина Роза Мунеровна <ro...@sbermarket.ru> on 2022/12/16 09:39:34 UTC
How to handle missed indexes and affinity keys?
Hola!
We've discovered some strange behaviour in Ignite cluster and now we are trying to understand how to recover from this state.
So we have 5 node cluster with persistence and all caches either replicated or partitioned with affinity key.
All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements in one regular job (once per day).
The problem is that we hit Query execution is too long warning.
After some debug we found out that some tables have missed indexes and affinity keys.
More precisely - corrupted tables have indexes not by exact column name but for _KEY column.
And no affinity key at all.
select
TABLE_NAME,
INDEX_NAME,
COLUMNS
from SYS.INDEXES
where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
;
Result:
+--------------------+------------+----------------------------+
|TABLE_NAME |INDEX_NAME |COLUMNS |
+--------------------+------------+----------------------------+
|USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
|USERFEATURESDISCOUNT|__SCAN_ |null |
|USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
|USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
|PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
|PRODUCTFEATURES |__SCAN_ |null |
|PRODUCTFEATURES |_key_PK |"_KEY" ASC |
+--------------------+------------+----------------------------+
Query execution even with simplest statements with filters on primary and affinity keys takes ~20min in best case.
We have 8 tables, 5 out 8 are corrupted.
So the questions are:
1. What can probably cause such state?
2. Is there any way to recover without full delete-refill tables? I see that index can be created via CREATE INDEX, but affinity key can be created only via CREATE TABLE statement?
Thanks in advance!
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru<ma...@sbermarket.ru>
Mob:
Web: sbermarket.ru<https://sbermarket.ru/>
App: iOS<https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android<https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Re: How to handle missed indexes and affinity keys?
Posted by Zhenya Stanilovsky via user <us...@ignite.apache.org>.
I can`t see the whole your problem, but possibly this is your case [1] ? Check it plz.
[1] https://issues.apache.org/jira/browse/IGNITE-18377
>Hi Maksim and Zhenya!
>I think that invalid coaches appeared because of execution of this statement in PyIgnite client:
>
>print(ignite_client.get_or_create_cache("PUBLIC_ProductFeatures").get_size())
>
>... while cache was not yet created by DDL SQL statement.
>There is “ IF NOT EXISTS ” in DDL so I guess that indexes and any properties were not created because the cache was already created by Key-Value API.
>Now we can’t reproduce this :( because we can’t investigate when exactly this python statement was executed.
>And this doesn’t explain why this happened to only 3 caches as statements were executed for all caches.
>
>Another hypothesis is that there was some not-graceful shutdown of the whole cluster.
>
>Debug info:
>1. Ignite version = 2.13.0
>2. CacheConfiguration: CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, TEMPLATE=PARTITIONED, BACKUPS=1 .
>3. Classes specified in KEY_TYPE and VALUE_TYPE are artificial - we build them with Binary Builder (they don’t exist as class definition).
>4. The SQL query you run and the "explain" plan for it:
>EXPLAIN
>SELECT ProductFeatures.product_sku,
>ProductFeatures.total_cnt_orders_with_sku
>FROM ProductFeatures
>WHERE ProductFeatures.product_sku = 52864
>;
>
>And the result:
>
>SELECT
>__Z0.PRODUCT_SKU AS __C0_0,
>__Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1
>FROM PUBLIC.PRODUCTFEATURES __Z0
>/* PUBLIC.PRODUCTFEATURES.__SCAN_ */
>WHERE __Z0.PRODUCT_SKU = 52864
>
>As you can see primary key is not used :(
>
>
>On 20 Dec 2022, at 10:46 AM, Zhenya Stanilovsky via user < user@ignite.apache.org > wrote:
>
>Hi Roza, when did you observe such a problem after restart ? and your caches with persistence mode ?
>
>
> Hi Maksim!
> The problem is that simple SELECT query runs in ~20min - this index does not work.
> More over, other (not corrupted) tables with affinity key == primary key have index by concrete column, not _KEY, and have specified affinity key - see my first message with example.
> We have hypothesis that somehow these corrupted caches were created by Key-Value API, not SQL. Otherwise how specified indexes and affinity keys were skipped in DDL while creating the caches?
> The more important question - is there any way to rebuild index and add affinity key back?
> Thanks!
> On 16 Dec 2022, at 4:30 PM, Maksim Timonin < timoninmaxim@apache.org > wrote:
> Hi Roza,
> In this ddl primary key (product_sku) equals the affinity key (product_sku). In such cases Ignite skips creating an additional index because _key_PK index already covers primary key.
> Thanks,
>Maksim
> On Fri, Dec 16, 2022 at 2:06 PM Айсина Роза Мунеровна < roza.aysina@sbermarket.ru > wrote:
>Hello Stephen!
> This DDL we use:
> CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
>(
> product_sku INT PRIMARY KEY,
> total_cnt_orders_with_sku INT
>)
>WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, TEMPLATE=PARTITIONED, BACKUPS=1
> And all tables are created similarly.
> On 16 Dec 2022, at 1:03 PM, Stephen Darlington < stephen.darlington@gridgain.com > wrote:
> Внимание: Внешний отправитель!
>Если вы не знаете отправителя - не открывайте вложения, не переходите по ссылкам, не пересылайте письмо!
> What are the CREATE TABLE commands for those tables?
> On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна < roza.aysina@sbermarket.ru > wrote:
> Hola!
>
>We've discovered some strange behaviour in Ignite cluster and now we are trying to understand how to recover from this state.
> So we have 5 node cluster with persistence and all caches either replicated or partitioned with affinity key.
>All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements in one regular job (once per day).
> The problem is that we hit Query execution is too long warning.
>After some debug we found out that some tables have missed indexes and affinity keys.
>More precisely - corrupted tables have indexes not by exact column name but for _KEY column.
>And no affinity key at all.
> select
> TABLE_NAME,
> INDEX_NAME,
> COLUMNS
>from SYS.INDEXES
>where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
> or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
>;
>
>Result:
>+--------------------+------------+----------------------------+
>|TABLE_NAME |INDEX_NAME |COLUMNS |
>+--------------------+------------+----------------------------+
>|USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
>|USERFEATURESDISCOUNT|__SCAN_ |null |
>|USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
>|USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
>|PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
>|PRODUCTFEATURES |__SCAN_ |null |
>|PRODUCTFEATURES |_key_PK |"_KEY" ASC |
>+--------------------+------------+----------------------------+
>
>Query execution even with simplest statements with filters on primary and affinity keys takes ~20min in best case.
>We have 8 tables, 5 out 8 are corrupted.
> So the questions are:
>1. What can probably cause such state?
>2. Is there any way to recover without full delete-refill tables? I see that index can be created via CREATE INDEX, but affinity key can be created only via CREATE TABLE statement?
> Thanks in advance!
> --
> Роза Айсина
>Старший разработчик ПО
>СберМаркет | Доставка из любимых магазинов
> Email: roza.aysina@sbermarket.ru
>Mob:
>Web: sbermarket.ru
>App: iOS и Android
> УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
>CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
>--
> Роза Айсина
>Старший разработчик ПО
>СберМаркет | Доставка из любимых магазинов
> Email: roza.aysina@sbermarket.ru
>Mob:
>Web: sbermarket.ru
>App: iOS и Android
> УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
>CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
>--
>
>Роза Айсина
>Старший разработчик ПО
>СберМаркет | Доставка из любимых магазинов
> Email: roza.aysina@sbermarket.ru
>Mob:
>Web: sbermarket.ru
>App: iOS и Android
>
>
>
>
>УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
>CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
>--
>
>Роза Айсина
>Старший разработчик ПО
>СберМаркет | Доставка из любимых магазинов
>
>Email: roza.aysina@sbermarket.ru
>Mob:
>Web: sbermarket.ru
>App: iOS и Android
>
>
>
>
>
>УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
>CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Re: How to handle missed indexes and affinity keys?
Posted by Айсина Роза Мунеровна <ro...@sbermarket.ru>.
Hi Maksim and Zhenya!
I think that invalid coaches appeared because of execution of this statement in PyIgnite client:
print(ignite_client.get_or_create_cache("PUBLIC_ProductFeatures").get_size())
... while cache was not yet created by DDL SQL statement.
There is “IF NOT EXISTS” in DDL so I guess that indexes and any properties were not created because the cache was already created by Key-Value API.
Now we can’t reproduce this :( because we can’t investigate when exactly this python statement was executed.
And this doesn’t explain why this happened to only 3 caches as statements were executed for all caches.
Another hypothesis is that there was some not-graceful shutdown of the whole cluster.
Debug info:
1. Ignite version = 2.13.0
2. CacheConfiguration: CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, TEMPLATE=PARTITIONED, BACKUPS=1.
3. Classes specified in KEY_TYPE and VALUE_TYPE are artificial - we build them with Binary Builder (they don’t exist as class definition).
4. The SQL query you run and the "explain" plan for it:
EXPLAIN
SELECT ProductFeatures.product_sku,
ProductFeatures.total_cnt_orders_with_sku
FROM ProductFeatures
WHERE ProductFeatures.product_sku = 52864
;
And the result:
SELECT
__Z0.PRODUCT_SKU AS __C0_0,
__Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1
FROM PUBLIC.PRODUCTFEATURES __Z0
/* PUBLIC.PRODUCTFEATURES.__SCAN_ */
WHERE __Z0.PRODUCT_SKU = 52864
As you can see primary key is not used :(
On 20 Dec 2022, at 10:46 AM, Zhenya Stanilovsky via user <us...@ignite.apache.org> wrote:
Hi Roza, when did you observe such a problem after restart ? and your caches with persistence mode ?
Hi Maksim!
The problem is that simple SELECT query runs in ~20min - this index does not work.
More over, other (not corrupted) tables with affinity key == primary key have index by concrete column, not _KEY, and have specified affinity key - see my first message with example.
We have hypothesis that somehow these corrupted caches were created by Key-Value API, not SQL. Otherwise how specified indexes and affinity keys were skipped in DDL while creating the caches?
The more important question - is there any way to rebuild index and add affinity key back?
Thanks!
On 16 Dec 2022, at 4:30 PM, Maksim Timonin <ti...@apache.org> wrote:
Hi Roza,
In this ddl primary key (product_sku) equals the affinity key (product_sku). In such cases Ignite skips creating an additional index because _key_PK index already covers primary key.
Thanks,
Maksim
On Fri, Dec 16, 2022 at 2:06 PM Айсина Роза Мунеровна <ro...@sbermarket.ru> wrote:
Hello Stephen!
This DDL we use:
CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
(
product_sku INT PRIMARY KEY,
total_cnt_orders_with_sku INT
)
WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, TEMPLATE=PARTITIONED, BACKUPS=1
And all tables are created similarly.
On 16 Dec 2022, at 1:03 PM, Stephen Darlington <st...@gridgain.com> wrote:
Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по ссылкам, не пересылайте письмо!
What are the CREATE TABLE commands for those tables?
On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна <ro...@sbermarket.ru> wrote:
Hola!
We've discovered some strange behaviour in Ignite cluster and now we are trying to understand how to recover from this state.
So we have 5 node cluster with persistence and all caches either replicated or partitioned with affinity key.
All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements in one regular job (once per day).
The problem is that we hit Query execution is too long warning.
After some debug we found out that some tables have missed indexes and affinity keys.
More precisely - corrupted tables have indexes not by exact column name but for _KEY column.
And no affinity key at all.
select
TABLE_NAME,
INDEX_NAME,
COLUMNS
from SYS.INDEXES
where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
;
Result:
+--------------------+------------+----------------------------+
|TABLE_NAME |INDEX_NAME |COLUMNS |
+--------------------+------------+----------------------------+
|USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
|USERFEATURESDISCOUNT|__SCAN_ |null |
|USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
|USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
|PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
|PRODUCTFEATURES |__SCAN_ |null |
|PRODUCTFEATURES |_key_PK |"_KEY" ASC |
+--------------------+------------+----------------------------+
Query execution even with simplest statements with filters on primary and affinity keys takes ~20min in best case.
We have 8 tables, 5 out 8 are corrupted.
So the questions are:
1. What can probably cause such state?
2. Is there any way to recover without full delete-refill tables? I see that index can be created via CREATE INDEX, but affinity key can be created only via CREATE TABLE statement?
Thanks in advance!
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru
Mob:
Web: sbermarket.ru
App: iOS и Android
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru
Mob:
Web: sbermarket.ru
App: iOS и Android
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru
Mob:
Web: sbermarket.ru
App: iOS и Android
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru<ma...@sbermarket.ru>
Mob:
Web: sbermarket.ru<https://sbermarket.ru/>
App: iOS<https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android<https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Re: How to handle missed indexes and affinity keys?
Posted by Zhenya Stanilovsky via user <us...@ignite.apache.org>.
Hi Roza, when did you observe such a problem after restart ? and your caches with persistence mode ?
>Hi Maksim!
>
>The problem is that simple SELECT query runs in ~20min - this index does not work.
>
>More over, other (not corrupted) tables with affinity key == primary key have index by concrete column, not _KEY , and have specified affinity key - see my first message with example.
>
>We have hypothesis that somehow these corrupted caches were created by Key-Value API, not SQL. Otherwise how specified indexes and affinity keys were skipped in DDL while creating the caches?
>
>The more important question - is there any way to rebuild index and add affinity key back?
>
>Thanks!
>
>>On 16 Dec 2022, at 4:30 PM, Maksim Timonin < timoninmaxim@apache.org > wrote:
>>Hi Roza,
>>
>>In this ddl primary key (product_sku) equals the affinity key (product_sku). In such cases Ignite skips creating an additional index because _key_PK index already covers primary key.
>>
>>Thanks,
>>Maksim
>>On Fri, Dec 16, 2022 at 2:06 PM Айсина Роза Мунеровна < roza.aysina@sbermarket.ru > wrote:
>>>Hello Stephen!
>>>
>>>This DDL we use:
>>>
>>>CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
>>>(
>>> product_sku INT PRIMARY KEY,
>>> total_cnt_orders_with_sku INT
>>>)
>>>WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, TEMPLATE=PARTITIONED, BACKUPS=1
>>>
>>>And all tables are created similarly.
>>>
>>>>On 16 Dec 2022, at 1:03 PM, Stephen Darlington < stephen.darlington@gridgain.com > wrote:
>>>>Внимание: Внешний отправитель!
>>>>Если вы не знаете отправителя - не открывайте вложения, не переходите по ссылкам, не пересылайте письмо!
>>>>What are the CREATE TABLE commands for those tables?
>>>>
>>>>>On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна < roza.aysina@sbermarket.ru > wrote:
>>>>>Hola!
>>>>>
>>>>>We've discovered some strange behaviour in Ignite cluster and now we are trying to understand how to recover from this state.
>>>>>
>>>>>So we have 5 node cluster with persistence and all caches either replicated or partitioned with affinity key.
>>>>>All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements in one regular job (once per day).
>>>>>
>>>>>The problem is that we hit Query execution is too long warning.
>>>>>After some debug we found out that some tables have missed indexes and affinity keys.
>>>>>More precisely - corrupted tables have indexes not by exact column name but for _KEY column.
>>>>>And no affinity key at all.
>>>>>
>>>>>select
>>>>> TABLE_NAME,
>>>>> INDEX_NAME,
>>>>> COLUMNS
>>>>>from SYS.INDEXES
>>>>>where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
>>>>> or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
>>>>>;
>>>>>
>>>>>Result:
>>>>>+--------------------+------------+----------------------------+
>>>>>|TABLE_NAME |INDEX_NAME |COLUMNS |
>>>>>+--------------------+------------+----------------------------+
>>>>>|USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
>>>>>|USERFEATURESDISCOUNT|__SCAN_ |null |
>>>>>|USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
>>>>>|USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
>>>>>|PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
>>>>>|PRODUCTFEATURES |__SCAN_ |null |
>>>>>|PRODUCTFEATURES |_key_PK |"_KEY" ASC |
>>>>>+--------------------+------------+----------------------------+
>>>>>
>>>>>Query execution even with simplest statements with filters on primary and affinity keys takes ~20min in best case.
>>>>>We have 8 tables, 5 out 8 are corrupted.
>>>>>
>>>>>So the questions are:
>>>>>1. What can probably cause such state?
>>>>>2. Is there any way to recover without full delete-refill tables? I see that index can be created via CREATE INDEX, but affinity key can be created only via CREATE TABLE statement?
>>>>>
>>>>>Thanks in advance!
>>>>>
>>>>>--
>>>>>
>>>>>Роза Айсина
>>>>>Старший разработчик ПО
>>>>>СберМаркет | Доставка из любимых магазинов
>>>>>
>>>>>Email: roza.aysina@sbermarket.ru
>>>>>Mob:
>>>>>Web: sbermarket.ru
>>>>>App: iOS и Android
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
>>>>>CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
>>>--
>>>
>>>Роза Айсина
>>>Старший разработчик ПО
>>>СберМаркет | Доставка из любимых магазинов
>>>
>>>Email: roza.aysina@sbermarket.ru
>>>Mob:
>>>Web: sbermarket.ru
>>>App: iOS и Android
>>>
>>>
>>>
>>>
>>>
>>>УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
>>>CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
>--
>
>Роза Айсина
>Старший разработчик ПО
>СберМаркет | Доставка из любимых магазинов
>
>Email: roza.aysina@sbermarket.ru
>Mob:
>Web: sbermarket.ru
>App: iOS и Android
>
>
>
>
>
>УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
>CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Re: How to handle missed indexes and affinity keys?
Posted by Maksim Timonin <ti...@apache.org>.
Hi Roza!
>> We have hypothesis that somehow these corrupted caches were created by
Key-Value API, not SQL.
Am I correct that you first create a cache "PUBLIC_ProductFeatures", and
then create a table over the existing cache by invoking the DDL query?
Could you please share some additional info that can help to reproduce your
case? At least:
1. Ignite version on which cache and table were created.
2. CacheConfiguration for the cache if it was created before.
3. Classes specified in KEY_TYPE and VALUE_TYPE.
4. The SQL query you run and the "explain" plan for it.
>> The more important question - is there any way to rebuild index and add
affinity key back?
Affinity can be set only during cache creation. Please check the docs if
you create a cache before table:
https://ignite.apache.org/docs/2.14.0/data-modeling/affinity-collocation#configuring-affinity-key
Thanks,
Maksim
On Mon, Dec 19, 2022 at 3:55 PM Айсина Роза Мунеровна <
roza.aysina@sbermarket.ru> wrote:
> Hi Maksim!
>
> The problem is that simple SELECT query runs in ~20min - this index does
> not work.
>
> More over, other (not corrupted) tables with affinity key == primary key
> have index by concrete column, not *_KEY*, and have specified affinity
> key - see my first message with example.
>
> We have hypothesis that somehow these corrupted caches were created by
> Key-Value API, not SQL. Otherwise how specified indexes and affinity keys
> were skipped in DDL while creating the caches?
>
> The more important question - is there any way to rebuild index and add
> affinity key back?
>
> Thanks!
>
> On 16 Dec 2022, at 4:30 PM, Maksim Timonin <ti...@apache.org>
> wrote:
>
> Hi Roza,
>
> In this ddl primary key (product_sku) equals the affinity key
> (product_sku). In such cases Ignite skips creating an additional index
> because _key_PK index already covers primary key.
>
> Thanks,
> Maksim
>
> On Fri, Dec 16, 2022 at 2:06 PM Айсина Роза Мунеровна <
> roza.aysina@sbermarket.ru> wrote:
>
>> Hello Stephen!
>>
>> This DDL we use:
>>
>> CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
>> (
>> product_sku INT PRIMARY KEY,
>> total_cnt_orders_with_sku INT
>> )
>> WITH "CACHE_NAME=PUBLIC_ProductFeatures,
>> KEY_TYPE=io.sbmt.ProductFeaturesKey,
>> VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku,
>> TEMPLATE=PARTITIONED, BACKUPS=1
>>
>> And all tables are created similarly.
>>
>> On 16 Dec 2022, at 1:03 PM, Stephen Darlington <
>> stephen.darlington@gridgain.com> wrote:
>>
>> Внимание: Внешний отправитель!
>> Если вы не знаете отправителя - не открывайте вложения, не переходите по
>> ссылкам, не пересылайте письмо!
>>
>> What are the CREATE TABLE commands for those tables?
>>
>> On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна <
>> roza.aysina@sbermarket.ru> wrote:
>>
>> Hola!
>>
>> We've discovered some strange behaviour in Ignite cluster and now we are
>> trying to understand how to recover from this state.
>>
>> So we have 5 node cluster with persistence and all caches either
>> replicated or partitioned with affinity key.
>> All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements
>> in one regular job (once per day).
>>
>> The problem is that we hit Query execution is too long warning.
>> After some debug we found out that some tables have missed indexes and
>> affinity keys.
>> More precisely - corrupted tables have indexes not by exact column name
>> but for _KEY column.
>> And no affinity key at all.
>>
>> select
>> TABLE_NAME,
>> INDEX_NAME,
>> COLUMNS
>> from SYS.INDEXES
>> where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
>> or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
>> ;
>>
>> Result:
>> +--------------------+------------+----------------------------+
>> |TABLE_NAME |INDEX_NAME |COLUMNS |
>> +--------------------+------------+----------------------------+
>> |USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
>> |USERFEATURESDISCOUNT|__SCAN_ |null |
>> |USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
>> |USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
>> |PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
>> |PRODUCTFEATURES |__SCAN_ |null |
>> |PRODUCTFEATURES |_key_PK |"_KEY" ASC |
>> +--------------------+------------+----------------------------+
>>
>>
>> Query execution even with simplest statements with filters on primary
>> and affinity keys takes ~20min in best case.
>> We have 8 tables, 5 out 8 are corrupted.
>>
>> So the questions are:
>> 1. What can probably cause such state?
>> 2. Is there any way to recover without full delete-refill tables? I see
>> that index can be created via CREATE INDEX, but affinity key can be created
>> only via CREATE TABLE statement?
>>
>> Thanks in advance!
>> *--*
>>
>> *Роза Айсина*
>> Старший разработчик ПО
>> *СберМаркет* | Доставка из любимых магазинов
>>
>>
>> Email: roza.aysina@sbermarket.ru
>> Mob:
>> Web: sbermarket.ru
>> App: iOS
>> <https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457>
>> и Android
>> <https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
>>
>>
>>
>>
>>
>>
>> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
>> документы, приложенные к нему, содержат конфиденциальную информацию.
>> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
>> Вам, использование, копирование, распространение информации, содержащейся в
>> настоящем сообщении, а также осуществление любых действий на основе этой
>> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
>> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
>> сообщение.
>> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
>> confidential. If you are not the intended recipient you are notified that
>> using, copying, distributing or taking any action in reliance on the
>> contents of this information is strictly prohibited. If you have received
>> this email in error please notify the sender and delete this email.
>>
>>
>>
>> *--*
>>
>> *Роза Айсина*
>> Старший разработчик ПО
>> *СберМаркет* | Доставка из любимых магазинов
>>
>>
>> Email: roza.aysina@sbermarket.ru
>> Mob:
>> Web: sbermarket.ru
>> App: iOS
>> <https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457>
>> и Android
>> <https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
>>
>>
>>
>>
>>
>>
>> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
>> документы, приложенные к нему, содержат конфиденциальную информацию.
>> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
>> Вам, использование, копирование, распространение информации, содержащейся в
>> настоящем сообщении, а также осуществление любых действий на основе этой
>> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
>> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
>> сообщение.
>> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
>> confidential. If you are not the intended recipient you are notified that
>> using, copying, distributing or taking any action in reliance on the
>> contents of this information is strictly prohibited. If you have received
>> this email in error please notify the sender and delete this email.
>>
>
> *--*
>
> *Роза Айсина*
>
> Старший разработчик ПО
>
> *СберМаркет* | Доставка из любимых магазинов
>
>
>
> Email: roza.aysina@sbermarket.ru
>
> Mob:
>
> Web: sbermarket.ru
>
> App: iOS
> <https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457>
> и Android
> <https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
>
>
>
> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
> документы, приложенные к нему, содержат конфиденциальную информацию.
> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
> Вам, использование, копирование, распространение информации, содержащейся в
> настоящем сообщении, а также осуществление любых действий на основе этой
> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
> сообщение.
> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
> confidential. If you are not the intended recipient you are notified that
> using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>
Re: How to handle missed indexes and affinity keys?
Posted by Айсина Роза Мунеровна <ro...@sbermarket.ru>.
Hi Maksim!
The problem is that simple SELECT query runs in ~20min - this index does not work.
More over, other (not corrupted) tables with affinity key == primary key have index by concrete column, not _KEY, and have specified affinity key - see my first message with example.
We have hypothesis that somehow these corrupted caches were created by Key-Value API, not SQL. Otherwise how specified indexes and affinity keys were skipped in DDL while creating the caches?
The more important question - is there any way to rebuild index and add affinity key back?
Thanks!
On 16 Dec 2022, at 4:30 PM, Maksim Timonin <ti...@apache.org> wrote:
Hi Roza,
In this ddl primary key (product_sku) equals the affinity key (product_sku). In such cases Ignite skips creating an additional index because _key_PK index already covers primary key.
Thanks,
Maksim
On Fri, Dec 16, 2022 at 2:06 PM Айсина Роза Мунеровна <ro...@sbermarket.ru>> wrote:
Hello Stephen!
This DDL we use:
CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
(
product_sku INT PRIMARY KEY,
total_cnt_orders_with_sku INT
)
WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, TEMPLATE=PARTITIONED, BACKUPS=1
And all tables are created similarly.
On 16 Dec 2022, at 1:03 PM, Stephen Darlington <st...@gridgain.com>> wrote:
Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по ссылкам, не пересылайте письмо!
What are the CREATE TABLE commands for those tables?
On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна <ro...@sbermarket.ru>> wrote:
Hola!
We've discovered some strange behaviour in Ignite cluster and now we are trying to understand how to recover from this state.
So we have 5 node cluster with persistence and all caches either replicated or partitioned with affinity key.
All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements in one regular job (once per day).
The problem is that we hit Query execution is too long warning.
After some debug we found out that some tables have missed indexes and affinity keys.
More precisely - corrupted tables have indexes not by exact column name but for _KEY column.
And no affinity key at all.
select
TABLE_NAME,
INDEX_NAME,
COLUMNS
from SYS.INDEXES
where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
;
Result:
+--------------------+------------+----------------------------+
|TABLE_NAME |INDEX_NAME |COLUMNS |
+--------------------+------------+----------------------------+
|USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
|USERFEATURESDISCOUNT|__SCAN_ |null |
|USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
|USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
|PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
|PRODUCTFEATURES |__SCAN_ |null |
|PRODUCTFEATURES |_key_PK |"_KEY" ASC |
+--------------------+------------+----------------------------+
Query execution even with simplest statements with filters on primary and affinity keys takes ~20min in best case.
We have 8 tables, 5 out 8 are corrupted.
So the questions are:
1. What can probably cause such state?
2. Is there any way to recover without full delete-refill tables? I see that index can be created via CREATE INDEX, but affinity key can be created only via CREATE TABLE statement?
Thanks in advance!
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru<ma...@sbermarket.ru>
Mob:
Web: sbermarket.ru<https://sbermarket.ru/>
App: iOS<https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android<https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru<ma...@sbermarket.ru>
Mob:
Web: sbermarket.ru<https://sbermarket.ru/>
App: iOS<https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android<https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru<ma...@sbermarket.ru>
Mob:
Web: sbermarket.ru<https://sbermarket.ru/>
App: iOS<https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android<https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Re: How to handle missed indexes and affinity keys?
Posted by Maksim Timonin <ti...@apache.org>.
Hi Roza,
In this ddl primary key (product_sku) equals the affinity key
(product_sku). In such cases Ignite skips creating an additional index
because _key_PK index already covers primary key.
Thanks,
Maksim
On Fri, Dec 16, 2022 at 2:06 PM Айсина Роза Мунеровна <
roza.aysina@sbermarket.ru> wrote:
> Hello Stephen!
>
> This DDL we use:
>
> CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
> (
> product_sku INT PRIMARY KEY,
> total_cnt_orders_with_sku INT
> )
> WITH "CACHE_NAME=PUBLIC_ProductFeatures,
> KEY_TYPE=io.sbmt.ProductFeaturesKey,
> VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku,
> TEMPLATE=PARTITIONED, BACKUPS=1
>
> And all tables are created similarly.
>
> On 16 Dec 2022, at 1:03 PM, Stephen Darlington <
> stephen.darlington@gridgain.com> wrote:
>
> Внимание: Внешний отправитель!
> Если вы не знаете отправителя - не открывайте вложения, не переходите по
> ссылкам, не пересылайте письмо!
>
> What are the CREATE TABLE commands for those tables?
>
> On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна <ro...@sbermarket.ru>
> wrote:
>
> Hola!
>
> We've discovered some strange behaviour in Ignite cluster and now we are
> trying to understand how to recover from this state.
>
> So we have 5 node cluster with persistence and all caches either
> replicated or partitioned with affinity key.
> All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements
> in one regular job (once per day).
>
> The problem is that we hit Query execution is too long warning.
> After some debug we found out that some tables have missed indexes and
> affinity keys.
> More precisely - corrupted tables have indexes not by exact column name
> but for _KEY column.
> And no affinity key at all.
>
> select
> TABLE_NAME,
> INDEX_NAME,
> COLUMNS
> from SYS.INDEXES
> where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
> or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
> ;
>
> Result:
> +--------------------+------------+----------------------------+
> |TABLE_NAME |INDEX_NAME |COLUMNS |
> +--------------------+------------+----------------------------+
> |USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
> |USERFEATURESDISCOUNT|__SCAN_ |null |
> |USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
> |USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
> |PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
> |PRODUCTFEATURES |__SCAN_ |null |
> |PRODUCTFEATURES |_key_PK |"_KEY" ASC |
> +--------------------+------------+----------------------------+
>
>
> Query execution even with simplest statements with filters on primary
> and affinity keys takes ~20min in best case.
> We have 8 tables, 5 out 8 are corrupted.
>
> So the questions are:
> 1. What can probably cause such state?
> 2. Is there any way to recover without full delete-refill tables? I see
> that index can be created via CREATE INDEX, but affinity key can be created
> only via CREATE TABLE statement?
>
> Thanks in advance!
> *--*
>
> *Роза Айсина*
> Старший разработчик ПО
> *СберМаркет* | Доставка из любимых магазинов
>
>
> Email: roza.aysina@sbermarket.ru
> Mob:
> Web: sbermarket.ru
> App: iOS
> <https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457>
> и Android
> <https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
>
>
>
>
>
>
> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
> документы, приложенные к нему, содержат конфиденциальную информацию.
> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
> Вам, использование, копирование, распространение информации, содержащейся в
> настоящем сообщении, а также осуществление любых действий на основе этой
> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
> сообщение.
> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
> confidential. If you are not the intended recipient you are notified that
> using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>
>
>
> *--*
>
> *Роза Айсина*
>
> Старший разработчик ПО
>
> *СберМаркет* | Доставка из любимых магазинов
>
>
>
> Email: roza.aysina@sbermarket.ru
>
> Mob:
>
> Web: sbermarket.ru
>
> App: iOS
> <https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457>
> и Android
> <https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
>
>
>
> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:* это электронное сообщение и любые
> документы, приложенные к нему, содержат конфиденциальную информацию.
> Настоящим уведомляем Вас о том, что, если это сообщение не предназначено
> Вам, использование, копирование, распространение информации, содержащейся в
> настоящем сообщении, а также осуществление любых действий на основе этой
> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
> сообщение.
> *CONFIDENTIALITY NOTICE:* This email and any files attached to it are
> confidential. If you are not the intended recipient you are notified that
> using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>
Re: How to handle missed indexes and affinity keys?
Posted by Айсина Роза Мунеровна <ro...@sbermarket.ru>.
Hello Stephen!
This DDL we use:
CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
(
product_sku INT PRIMARY KEY,
total_cnt_orders_with_sku INT
)
WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, TEMPLATE=PARTITIONED, BACKUPS=1
And all tables are created similarly.
On 16 Dec 2022, at 1:03 PM, Stephen Darlington <st...@gridgain.com> wrote:
Внимание: Внешний отправитель!
Если вы не знаете отправителя - не открывайте вложения, не переходите по ссылкам, не пересылайте письмо!
What are the CREATE TABLE commands for those tables?
On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна <ro...@sbermarket.ru>> wrote:
Hola!
We've discovered some strange behaviour in Ignite cluster and now we are trying to understand how to recover from this state.
So we have 5 node cluster with persistence and all caches either replicated or partitioned with affinity key.
All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements in one regular job (once per day).
The problem is that we hit Query execution is too long warning.
After some debug we found out that some tables have missed indexes and affinity keys.
More precisely - corrupted tables have indexes not by exact column name but for _KEY column.
And no affinity key at all.
select
TABLE_NAME,
INDEX_NAME,
COLUMNS
from SYS.INDEXES
where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
;
Result:
+--------------------+------------+----------------------------+
|TABLE_NAME |INDEX_NAME |COLUMNS |
+--------------------+------------+----------------------------+
|USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
|USERFEATURESDISCOUNT|__SCAN_ |null |
|USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
|USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
|PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
|PRODUCTFEATURES |__SCAN_ |null |
|PRODUCTFEATURES |_key_PK |"_KEY" ASC |
+--------------------+------------+----------------------------+
Query execution even with simplest statements with filters on primary and affinity keys takes ~20min in best case.
We have 8 tables, 5 out 8 are corrupted.
So the questions are:
1. What can probably cause such state?
2. Is there any way to recover without full delete-refill tables? I see that index can be created via CREATE INDEX, but affinity key can be created only via CREATE TABLE statement?
Thanks in advance!
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru<ma...@sbermarket.ru>
Mob:
Web: sbermarket.ru<https://sbermarket.ru/>
App: iOS<https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android<https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
--
Роза Айсина
Старший разработчик ПО
СберМаркет | Доставка из любимых магазинов
Email: roza.aysina@sbermarket.ru<ma...@sbermarket.ru>
Mob:
Web: sbermarket.ru<https://sbermarket.ru/>
App: iOS<https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android<https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Re: How to handle missed indexes and affinity keys?
Posted by Stephen Darlington <st...@gridgain.com>.
What are the CREATE TABLE commands for those tables?
> On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна <ro...@sbermarket.ru> wrote:
>
> Hola!
>
> We've discovered some strange behaviour in Ignite cluster and now we are trying to understand how to recover from this state.
>
> So we have 5 node cluster with persistence and all caches either replicated or partitioned with affinity key.
> All caches are created via DDL with CREATE TABLE IF NOT EXISTS statements in one regular job (once per day).
>
> The problem is that we hit Query execution is too long warning.
> After some debug we found out that some tables have missed indexes and affinity keys.
> More precisely - corrupted tables have indexes not by exact column name but for _KEY column.
> And no affinity key at all.
>
> select
> TABLE_NAME,
> INDEX_NAME,
> COLUMNS
> from SYS.INDEXES
> where TABLE_NAME = ‘PRODUCTFEATURES’ — broken table
> or TABLE_NAME = ‘USERFEATURESDISCOUNT’ — healthy table
> ;
>
> Result:
> +--------------------+------------+----------------------------+
> |TABLE_NAME |INDEX_NAME |COLUMNS |
> +--------------------+------------+----------------------------+
> |USERFEATURESDISCOUNT|_key_PK_hash|"USER_ID" ASC, "USER_ID" ASC|
> |USERFEATURESDISCOUNT|__SCAN_ |null |
> |USERFEATURESDISCOUNT|_key_PK |"USER_ID" ASC |
> |USERFEATURESDISCOUNT|AFFINITY_KEY|"USER_ID" ASC |
> |PRODUCTFEATURES |_key_PK_hash|"_KEY" ASC |
> |PRODUCTFEATURES |__SCAN_ |null |
> |PRODUCTFEATURES |_key_PK |"_KEY" ASC |
> +--------------------+------------+----------------------------+
>
>
> Query execution even with simplest statements with filters on primary and affinity keys takes ~20min in best case.
> We have 8 tables, 5 out 8 are corrupted.
>
> So the questions are:
> 1. What can probably cause such state?
> 2. Is there any way to recover without full delete-refill tables? I see that index can be created via CREATE INDEX, but affinity key can be created only via CREATE TABLE statement?
>
> Thanks in advance!
> --
>
> Роза Айсина
> Старший разработчик ПО
> СберМаркет | Доставка из любимых магазинов
>
> Email: roza.aysina@sbermarket.ru <ma...@sbermarket.ru>
> Mob:
> Web: sbermarket.ru <https://sbermarket.ru/>
> App: iOS <https://apps.apple.com/ru/app/%D1%81%D0%B1%D0%B5%D1%80%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2/id1166642457> и Android <https://play.google.com/store/apps/details?id=ru.instamart&hl=en&gl=ru>
>
>
>
>
>
> УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что, если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
> CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
>