Hi guys, I see that the original message and its clarification is hard to consume. The problem is that indexes are identified by their names. So, the situation that Kirill described is a valid one: - you have index X for columns (a, b); - you drop it; - you create index X for columns (a, c).
This is a realistic scenario. If all of that happened during a single checkpoint interval and node failed. Real issue here is the fact that we restore metastorage separately from everything else. This means that DurableBackgroundTask will start deleting X (a, c) if we're not careful. It all depends on the implementation. I'd suggest Alexeys solution with a few tweaks: - I'm not convinced that we need to log indexes creation, this is excessive; - how do you drop index for the metatree: -- pick a unique name; -- acquire checkpoint read lock; -- create DurableBackgroundTask that will delete index with that unique name; -- create logical WAL record "drop index X"; -- "rename" link to the index in meta tree; -- release checkpoint read lock; -- start DurableBackgroundTask. Recovery for "drop index X" should also create another DurableBackgroundTask, this way I think we'll be able to avoid any possible issues. If DurableBackgroundTask has a name of an unexisting index then that's fine, task will be completed as successful, that's a normal flow. I hope everything's clear here, I'm ready to clarify more details about my idea. Thank you! ср, 7 июл. 2021 г. в 17:20, ткаленко кирилл <tkalkir...@yandex.ru>: > I'll try to explain: > > We create indexes through InlineIndexFactory#createIndex, where at the > beginning we create the root page using QueryIndexDefinition#treeName, so > if we create the same index 2 times, then we will refer to the same root. > > In order to make the deletion of the index independent, I propose to > replace the name of the root pages with an arbitrary name (other than > QueryIndexDefinition#treeName, for example UUID.toString()), in order to > avoid the problems of a node crash, I propose to fix this in a logical > record. > > After we change the name of the root page to delete the index, we can > easily delete it and rebuild it (if the user does it) in parallel. > > If we consider your proposal, then the creation and deletion of the index > will go in parallel and they will look at the same roots. > > You can see how the renaming will take place here: > https://github.com/apache/ignite/pull/9223 > > 07.07.2021, 10:28, "Alexei Scherbakov" <alexey.scherbak...@gmail.com>: > > вт, 6 июл. 2021 г. в 15:57, ткаленко кирилл <tkalkir...@yandex.ru>: > > > >> >> Can you clarify what it means to rename root index trees ? > >> Replacing > >> > > org.apache.ignite.internal.processors.cache.persistence.IndexStorageImpl.IndexItem, > >> changing IndexItem#idxName, but keeping fIndexItem#pageId. > > > > Changing to what ? Some temporary name ? Can you give a detailed step by > > step description of the algorithm ? > > > >> Suggested solution is not suitable for the situation: add index -> drop > >> index -> add an index. We can start deleting the last added index. > > > > How can we do that, give me an example ? > > > > From my understanding, the suggested solution should work ok for any > number > > of create/drop sequences. > > > >> 06.07.2021, 14:00, "Alexei Scherbakov" <alexey.scherbak...@gmail.com>: > >> > Can you clarify what it means to rename root index trees ? > >> > > >> > The simple solution which immediately comes to me is > >> > > >> > 1) write logical record on index creation - on reading it create an > index > >> > during logical recovery > >> > 2) write logical record on index deletion - on reading it delete an > index > >> > during logical recovery and start background clearing task with real > root > >> > pages. > >> > > >> > Will it work for you ? > >> > > >> > вт, 6 июл. 2021 г. в 12:27, ткаленко кирилл <tkalkir...@yandex.ru>: > >> > > >> >> Hello everyone! > >> >> > >> >> Currently, dropping indexes consists of the following steps (based > on > >> >> SchemaAbstractDiscoveryMessage's): > >> >> > >> >> Step 1: Removing the index from the SQL engine and starting > >> >> DurableBackgroundCleanupIndexTreeTask, which removes the index trees > >> in the > >> >> background; > >> >> Step 1.1: DurableBackgroundCleanupIndexTreeTask is added to the > >> >> metaStorage and removed after successful completion at the next > >> checkpoint. > >> >> > >> >> Step 2: Removing the index from the cache configuration and persist > it. > >> >> > >> >> Problems: > >> >> > >> >> 1)We add and immediately delete the index, a checkpoint does not > happen > >> >> and the node crashes, after restarting > >> >> DurableBackgroundCleanupIndexTreeTask will not be able to complete > and > >> will > >> >> periodically restart due to the fact that it saves > >> >> DurableBackgroundCleanupIndexTreeTask#rootPages (root pages of index > >> trees) > >> >> that have not appeared; > >> >> > >> >> 2)After adding a DurableBackgroundCleanupIndexTreeTask node crashes, > >> after > >> >> restarting the node, the task will clean the index trees and there > >> will be > >> >> errors when using the index; > >> >> > >> >> 3)etc. > >> >> > >> >> Suggested solution: > >> >> > >> >> Rename the root index trees and write about this with a logical > entry > >> in > >> >> the WAL and do this at the first start of > >> >> DurableBackgroundCleanupIndexTreeTask. > >> >> Thus, if we find the renamed root pages in task 1, we can clear the > >> index > >> >> trees to the end, otherwise the task can be completed. > >> >> Also, if we find that rename pages are present, and the step 2 has > not > >> >> been completed, then we can start rebuilding the indexes. > >> >> > >> >> WDYT? > >> > > >> > -- > >> > > >> > Best regards, > >> > Alexei Scherbakov > > > > -- > > > > Best regards, > > Alexei Scherbakov > -- Sincerely yours, Ivan Bessonov
