Hi Andrey, > Max would you please assist and validate the test ResumeCreateIndexTest. testIncompleteIndexDroppedOnCacheDestroy, maybe I've missed smth.
Sure, I'll check it and other issues you mentioned on Monday. Thank you for investigating these things. Maksim On Friday, January 28, 2022, Andrey Mashenkov <andrey.mashen...@gmail.com> wrote: > Hi Igniters, > > I've created a ticket [1] with the PR [2] where wrote 3 tests for some > scenarios that lead to index corruption. > The scenarios are described in detail in the PR, so, you may look at a > code for better understanding. > > Please, feel free to create a separate ticket for fixing any of the next > scenarios. > The first scenario is quite simple, but others impact compatibility, and > the proper fix has to be discussed first. > > 1. The first scenario. > The user has a cache with the data in some cache group and creates an > index. > While the index is building in the background, the user drops the cache. > The user expects the index building will be canceled and the incomplete > index tree will be dropped. > Then the user creates an empty cache with the same name and the first put > operation fails with a corrupted tree exception. > At first glance, we forgot to drop the index tree. > > Actually, in GridGain we faced this issue and the fix is trivial. > However, I've add this fix to the PR without success. Most likely, there > is another bug or code much different, > because we don't have the IndexQuery feature in GG that was added by Maxim > Timonin recently. > > Max would you please assist and validate the test ResumeCreateIndexTest. > testIncompleteIndexDroppedOnCacheDestroy, > maybe I've missed smth. > > 2. The second scenario. > I've found that Ignite creates a system index "Affinity_Key" if the > affinity key is configured, > but it can be shadowed by a user index that starts with the affinity > column (composite or not). > > Seems, Ignite assumes that it can save memory and omit the system affinity > index if it can be replaced with the user one. > That was ok for older Ignite versions, which had no support for dynamic > indices, but now this 'feature' is painful. > > If a user creates such an index on the cache with existed data, and later > drop the index, > the affinity index tree will be inconsistent because it missed all the > operations between creating-dropping the custom affinity index. > > 3. The third scenario. > Similar to the second one. > If a user drops the cache with the custom affinity index and then creates > a new cache with the same name, > the newly created cache will use 'outdated' system affinity tree from the > previous cache. > This happens, because Ignite does NOT register the system index (with > tree) if there is a custom affinity index, and forgets to clean up the > index tree on cache drop. > > The fix for 2 and 3 is not trivial. > 1. If we will register the system affinity index unconditionally, then > users with the custom index will get corrupted tree on node start after the > upgrade. > 2. if we decided to drop affinity cache, this will affect UX. > Some old users may experience a slowdown for some queries (very common > case) where affinity index is involved and will have to create index on > affinity index manually. > New users may have poor performance out-of-the-box. > 3. I'm not sure if we can detect if the affinity index should be dropped > or rebuilt at node start. And correctly substitute system index with custom > one (and vice versa) on-fly. > > > I lay to the second option. > WDYT? > Any ideas? > > > [1] https://issues.apache.org/jira/browse/IGNITE-16426 > [2] https://github.com/apache/ignite/pull/9780 > -- > Best regards, > Andrey V. Mashenkov >
