Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 为什么truncate也会创建region
|
username: Zhoutzzz
As mentioned, with a single PD and single TiKV, after creating a table and then truncating it, the number of regions increases by 2.
Truncate is equivalent to dropping and then creating…
The table ID will change, you can try it.
At this time, the region will definitely be created according to the default configuration.
Under the default configuration, each table has one region. After truncating, a new region is created, and the old region is no longer bound to anything. Even after 10 to 20 minutes, the region has not merged. The original intention of truncate is to delete only the table data without deleting the table structure. If the table has indexes, will the indexes be deleted in this case?
Regions will become empty, and then PD will schedule the merging of empty regions. There is quite a bit of documentation on this, which you can refer to for handling it. The key is whether all configurations are in place.
Whether cross-table merging is allowed
Whether the merge switch is turned on…
Whether there is an appropriate merge interval
There are also some other conditions that can affect merging.
Additionally, indexes are also regions and will be newly created… (If the data is gone, the indexes definitely need to be cleaned up as well.)
The original intention of TRUNCATE is to delete only the table data without deleting the table structure.
The TRUNCATE statement deletes all data from the table in a non-transactional manner. It can be considered semantically equivalent to the combination of DROP TABLE + CREATE TABLE, with the definition being the same as the DROP TABLE statement. In other words, it discards the original region and rebuilds it, and the table ID will also change.
TiDB has a flashback mechanism, so deleted or truncated tables should still exist in the background for a period of time. Using a new table ID seems very reasonable.
So both recover and flashback should be able to restore TRUNCATE operations. TRUNCATE is essentially similar to DROP, not as described in the video course where only flashback can restore truncate. 
Can an empty region be considered a placeholder that occupies a range of keys, and keys within this range cannot be stored?
It’s not about the concept; the range of region keys is defined when created, following the principle of left-closed and right-open.
Only regions that meet this principle can be merged; they cannot merge to the left.
You can find this information in the best practices documentation, which is worth studying carefully.
Recover and flashback are essentially similar, with recover being used for more distant points in time.
In TiKV, regions are not allowed to have gaps, meaning that regardless of whether regions are empty, they are continuous. So, for empty regions caused by operations like truncate, which are no longer related to the table before the truncate, do they still have a range? If subsequent operations produce keys within this range, will they be stored in this empty region and associated with the relevant table?
Once cross-table operations are allowed, regions will no longer have logical constraints (exclusive to a specific table) and will generally be applicable (usable by all tables).
After that, just keep observing. The scheduler will handle merging any regions that can be merged.
Understood, I have another question. If PD goes down, regardless of whether it’s TiKV or TiDB, apart from the missing functionalities provided by PD, are the basic CRUD operations still available?
If the PD is completely down, it will be impossible to connect, and it won’t be able to provide read and write operations.
We tried using TiKV, and probably due to caching, it was still possible to read and write even when PD was down, just without PD’s functionality. However, PD is indeed required during startup.
I just tried it, and it can indeed connect, but read and write operations on the table should not work.
Without TSO support, TiDB is basically unusable.
Even bare TiKV requires PD for support…
In our stress testing scenario, we shut down all the PDs midway, and the TPS of the entire TiKV actually increased.
This topic was automatically closed 1 minute after the last reply. No new replies are allowed.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: