There is an issue with Region merging in TiDB v4.0.15

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: TIDBv4.0.15存在Region合并的问题

| username: TiDBer_G64jJ9u8

[TiDB Usage Environment] Production Environment
[TiDB Version] 4.0.15
[Reproduction Path] Simulate a production environment with a large amount of read/write and truncate table operations
[Encountered Problem: Phenomenon and Impact] The raft thread of TiKV is very busy, and analysis found that a large number of regions have not merged
[Resource Configuration]
[Attachments: Screenshots/Logs/Monitoring]

mysql> select DB_NAME, TABLE_NAME, count(distinct(REGION_ID)) as num from TIKV_REGION_STATUS group by TABLE_NAME;
±-------------------±--------------------------------------------------±-------+
| DB_NAME | TABLE_NAME | num |
±-------------------±--------------------------------------------------±-------+
| NULL | NULL | 122183 |

mysql> select REGION_ID, TABLE_ID, TABLE_NAME, WRITTEN_BYTES, READ_BYTES from TIKV_REGION_STATUS limit 100;
±----------±---------±----------------------------------±--------------±-----------+
| REGION_ID | TABLE_ID | TABLE_NAME | WRITTEN_BYTES | READ_BYTES |
±----------±---------±----------------------------------±--------------±-----------+
| 200841 | NULL | NULL | 0 | 0 |
| 606145 | NULL | NULL | 0 | 0 |
| 310921 | NULL | NULL | 0 | 0 |
| 161929 | NULL | NULL | 0 | 0 |
| 214477 | NULL | NULL | 0 | 0 |
| 294165 | NULL | NULL | 0 | 0 |
| 310929 | NULL | NULL | 0 | 0 |
| 485429 | NULL | NULL | 0 | 0 |
| 198641 | NULL | NULL | 0 | 0 |

| username: 裤衩儿飞上天 | Original post link

You can enable cross-table merge. In version 4.0, this parameter is disabled by default.

| username: Jellybean | Original post link

Version 4.0 is quite old. If possible, it is recommended to upgrade to version 6 or later, as both performance and stability have significantly improved.

| username: redgame | Original post link

Oh, I learned about enable-cross-table-merge. Impressive.

| username: TiDBer_G64jJ9u8 | Original post link

Set to true via the MySQL client, but how long does this configuration take effect?

mysql> set config pd schedule.enable-cross-table-merge=‘true’;
Query OK, 0 rows affected (0.16 sec)

mysql> show config where name like ‘%enable-cross-table-merge%’;
±-----±----------------------------------------------±----------------------------------±------+
| Type | Instance | Name | Value |
±-----±----------------------------------------------±----------------------------------±------+
| pd | basic-pd-1.basic-pd-peer.maipu-bdwan.svc:2379 | schedule.enable-cross-table-merge | true |
| pd | basic-pd-2.basic-pd-peer.maipu-bdwan.svc:2379 | schedule.enable-cross-table-merge | true |
±-----±----------------------------------------------±----------------------------------±------+
2 rows in set (0.18 sec)

| username: 裤衩儿飞上天 | Original post link

The changes will take effect after a restart.

| username: TiDBer_G64jJ9u8 | Original post link

I didn’t restart after making changes in the production environment, and the number of regions is gradually decreasing. Do I need to restart to confirm?
Where is the configuration stored, in etcd or somewhere else, and will the configuration be lost if I restart?

| username: 裤衩儿飞上天 | Original post link

  1. If it is modified through edit-config, a restart is required.

  2. There is another way to modify it online, which does not require a restart.

  3. PD configuration items that can be modified online will be persisted to etcd after successful modification, but will not be persisted to the configuration file. Subsequent configurations will be based on the ones in etcd.

  4. Not all parameters support online modification.
    You can refer to: Online Cluster Configuration Modification | PingCAP Documentation Center

| username: 胡杨树旁 | Original post link

After modifying this parameter through pd-ctl, there is no need to restart the cluster, right?

| username: 裤衩儿飞上天 | Original post link

Yes.

| username: zhanggame1 | Original post link

The pd parameters modified through set are persisted to etcd and cannot be found in the cluster parameter file. They take effect immediately.

| username: TiDBer_G64jJ9u8 | Original post link

What is the difference in logic between modifying parameters through the MySQL client and modifying parameters through pd-ctl and tikv-ctl? Is it that the MySQL operations are parsed into pd-ctl to complete, or is it the opposite, that pd-ctl commands are executed through MySQL?

| username: zhanggame1 | Original post link

The technical details are unclear, but executing SQL is much more convenient.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.