Tracking issue for Region Label Feature

[disksing]

Region Label is a system that runs inside PD and is used to identify different types of Regions, based on Region Label we can bind different behaviors to different regions.

For example, by setting labels for different tables of regions, we can control some tables from being merged.

In the first phase, we will support syncing part of the schema from TiDB to PD as region labels, and use region labels to control the behavior of region merge on top of that.

Sub tasks break up:

• Introducing the Region Label framework & Implementing a LabelRule of type KeyRange
  • labeler: add region label #3968
• Implementing the HTTP API interface #3985
• Split region when the key range spans across region label rule boundary #4000
• Support nomerge label to disable merge for some regions #4001
• Support synchronization of table attributes CRUD operations from TiDB to PD
  • Support alter table attributes to add label rules pingcap/tidb#26692
  • Support drop table for label rule pingcap/tidb#26693
  • Support truncate table for label rules pingcap/tidb#26835
  • Update label rules when rename table pingcap/tidb#27019
  • Support recover/flashback table for label rules pingcap/tidb#27065
• Support synchronization of partition attributes CRUD operations from TiDB to PD
  • Support alter table partition attributes to add label rules pingcap/tidb#26704
  • Support drop partition for label rules pingcap/tidb#26794
  • Support truncate partition for label rules pingcap/tidb#26836
  • Support exchange partition for label rules pingcap/tidb#27101
• Support showing the added attributes
  • Support showing label rule through information schema table pingcap/tidb#26694
• Support DDL syntax for adding/resetting attributes
  • Support attributes syntax for alter table/partition operations pingcap/parser#1288
• Support rule override
  • Add index to support label rule override pingcap/tidb#27784
  • Support Region Label Rule override #4031

[tisonkun]

Hi @disksing , thanks for creating this tracking issue. Is there a design for this feature? I'd like to know how region label feature is integrated with region merge on top of that.

[sunxiaoguang]

Could you please help me to understand why region rule better than placement rule? Is it because we want to configure rules at finer granularity? Thanks.

[disksing]

Hi @disksing , thanks for creating this tracking issue. Is there a design for this feature? I'd like to know how region label feature is integrated with region merge on top of that.

The detailed design is in Chinese so not linked. sorry :(

Our plan is to support binding some attributes for table (or database or partition) in SQL, and these attributes will be synchronized to PD in the form of label.

For example, if we define a special label called 'nomerge', after TiDB adds this keyword to the attribute, the label configuration will be synchronized to PD, and then in PD, we will be able to query the region label of nomerge from the region belonging to the corresponding schema. so that we can make the appropriate judgments before PD will merge two regions.

[disksing]

Could you please help me to understand why region rule better than placement rule? Is it because we want to configure rules at finer granularity? Thanks.

The region label is not used to replace the placement rule, but to reinforce it.

A region label is essentially a system for categorizing the data in a cluster. By setting various rules, we can classify regions based on key range / key prefix / region size. This classification information can then be easily used by other modules to handle different types of data in a special way.

A powerful scenario for TiDB is to inject the mapping between key-range and DB schema into PD through region label configration, so that we actually have the ability to specialize the data belonging to different schemas in PD, and PD does not need to understand the concept of schema - -They just arbitrary labels for PD.

Once we have synchronized the mapping of schema and key-range to PD, we can improve the original placement rules by allowing the original key range configuration to be changed to a region label. This way the placement rule does not need to care about the key range binding of the schema, especially when the key range of the table changes, the placement rule configuration does not need to be updated. At the same time, the placement rule will be more powerful due to the diversity of region label configurations - for example, placement policy for prefixes, specialized placement policy for small regions, specialized placement policy for hot regions.

[tisonkun]

@rleungx I can see you create several PR against this issue, which subtask they target to? We can create a subtask issue for each and let the PR close that one. As tikv/tikv#10537