Why does truncate also create regions?

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.

| username: xfworld | Original post link

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.

| username: Zhoutzzz | Original post link

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?

| username: xfworld | Original post link

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.

  1. Whether cross-table merging is allowed

  2. Whether the merge switch is turned on…

  3. 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.)

| username: ShawnYan | Original post link

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.

| username: ablewang_xiaobo | Original post link

The table_id really changes.

| username: ablewang_xiaobo | Original post link

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.

| username: ddhe9527 | Original post link

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. :joy:

| username: Zhoutzzz | Original post link

Can an empty region be considered a placeholder that occupies a range of keys, and keys within this range cannot be stored?

| username: xfworld | Original post link

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.

| username: ShawnYan | Original post link

Recover and flashback are essentially similar, with recover being used for more distant points in time.

| username: Zhoutzzz | Original post link

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?

| username: xfworld | Original post link

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.

| username: Zhoutzzz | Original post link

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?

| username: 啦啦啦啦啦 | Original post link

If the PD is completely down, it will be impossible to connect, and it won’t be able to provide read and write operations.

| username: Zhoutzzz | Original post link

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.

| username: 啦啦啦啦啦 | Original post link

I just tried it, and it can indeed connect, but read and write operations on the table should not work.

| username: xfworld | Original post link

Without TSO support, TiDB is basically unusable.

Even bare TiKV requires PD for support…

| username: Zhoutzzz | Original post link

In our stress testing scenario, we shut down all the PDs midway, and the TPS of the entire TiKV actually increased.

| username: system | Original post link

This topic was automatically closed 1 minute after the last reply. No new replies are allowed.