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 <
>[email protected] > 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 < [email protected] > 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 Айсина Роза Мунеровна <
>[email protected] > 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 <
>[email protected] > wrote:
> Внимание: Внешний отправитель!
>Если вы не знаете отправителя - не открывайте вложения, не переходите по
>ссылкам, не пересылайте письмо!
> What are the CREATE TABLE commands for those tables?
> On 16 Dec 2022, at 09:39, Айсина Роза Мунеровна < [email protected]
>> 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: [email protected]
>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: [email protected]
>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: [email protected]
>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: [email protected]
>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.
