You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iotdb.apache.org by lu <cm...@126.com> on 2022/05/16 12:18:26 UTC

Refactor process of DeleteStorageGroups to support rollback

Hi all:
       There are three steps in the current DeleteStorageGroup process, there are three steps that need to go through.
       1. Delete partition informations on the PartitionRegion
       2. Delete metadata informations on schemaRegion based on the partition information and clean up the cache
       3. Delete the data files and directories on dataRegion based on the partition information
       I/O operations in step 3 may take a long time and is prone to exceptions, which is prone to deletion failures.
       Here is a logical deletion plan instead of deleting data files directly. The deletion is divided into logical and physical deletions, the logical deletion simply screens the read and write operations related to storage group, and the physical deletion deletes files and is executed asynchronously.This simplifies the operation of deleting RPCs and reduce the probability of timeouts and exceptions and is able to rollback when exceptions occur.
        Detail Chinese doc is attached. Any idea is welcomed. 


FYI
----
Lu Ming
      

Re: Refactor process of DeleteStorageGroups to support rollback

Posted by Jialin Qiao <qi...@apache.org>.
Hi,

The separation of logical and physical deletion is a good idea.
The dev@list doesn't support attachments...

Thanks,
—————————————————
Jialin Qiao
Apache IoTDB PMC


lu <cm...@126.com> 于2022年5月16日周一 20:18写道:

> Hi all:
>        There are three steps in the current DeleteStorageGroup process,
> there are three steps that need to go through.
>        1. Delete partition informations on the PartitionRegion
>        2. Delete metadata informations on schemaRegion based on the
> partition information and clean up the cache
>        3. Delete the data files and directories on dataRegion based on the
> partition information
>        I/O operations in step 3 may take a long time and is prone to
> exceptions, which is prone to deletion failures.
>        Here is a logical deletion plan instead of deleting data files
> directly. The deletion is divided into logical and physical deletions, the
> logical deletion simply screens the read and write operations related to
> storage group, and the physical deletion deletes files and is executed
> asynchronously.This simplifies the operation of deleting RPCs and reduce
> the probability of timeouts and exceptions and is able to rollback when
> exceptions occur.
>         Detail Chinese doc is attached. Any idea is welcomed.
>
> FYI
> ----
> Lu Ming
>
>
>
>
>