This repository has been archived by the owner on Feb 6, 2024. It is now read-only.
Allow creating table again if the table create failed before #228
Labels
enhancement
New feature or request
Description
Currently, another table creation is disallowed if it fails to create the table firstly, which is unfriendly for use.
Proposal
The reason to disallow the retry to create the same table again is that the failure of creation may result from the
ceresdb-server
, that is to say, the inconsistency may already exist after the first create failure, andCeresMeta
can't do more about the such inconsistent state.Here is the current procedure to create a table:
ceresdb-server
;ceresdb-server
sends it toCeresMeta
;CeresMeta
picks some shard for this table;CeresMeta
tries to allocate a table id for the table name, and it fails if the table name has been used;CeresMeta
demands theceresdb-server
owning the shard to create the table, and waits for the response, it fails if the creation byceresdb-server
fails;CeresMeta
persists the update about the shard topology (mapping between shards and tables);And in most cases, the step 5 may fail, and it will lead to the following create requests' failure at the step 4;
Here is a proposal to address this problem:
Let's persist the create table params in the meta data (in etcd, with the table name as the key), and the following table creation should utilize this information and ensure the table always lie at the same shard.
Here is the new procedure to create a table:
In the flow graph, it can be found that:
In the new procedure, another create table will be allowed because it is ensured to be created at the same shard. However, some other cases should be taken into considerations. Let's discuss these problems in the following section.
Concurrent Creation
The current procedure avoids the concurrent creation when allocating the table id for the table name (it fails if the table name is already allocated to an ID).
And in the new procedure, it won't fail if it is found that the table name has been allocated to an ID. However, it doesn't lead to any harm because it is idempotent.
The text was updated successfully, but these errors were encountered: