The command "config set label-property reject-leader host xxx" can be executed, but it does not take effect

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

Original topic: config set label-property reject-leader host xxx能执行,但是无法生效

| username: terry0219

The command config set label-property reject-leader is no longer supported in version 7.5. Although it executes successfully, testing shows it does not take effect.

| username: TiDBer_小阿飞 | Original post link

TiDB 5.2 and above versions do not support the label-property configuration by default. To set replica policies, please use Placement Rules.

| username: terry0219 | Original post link

Thank you for your reply. Which one is more recommended to use now between Placement Rules and Placement Rules in SQL, or which one is more mature now?

| username: TiDBer_小阿飞 | Original post link

I don’t know which one is more mature, but the official documentation recommends using Placement Rules in SQL, which makes it easier for you to set the placement of tables and partitions. However, the underlying implementation of Placement Rules in SQL depends on the placement rules functionality provided by PD. So, according to this logic, the existing Placement Rules came first, followed by Placement Rules in SQL.

| username: tidb菜鸟一只 | Original post link

It’s the same. Placement Rules in SQL also uses Placement Rules at the underlying level. Placement Rules in SQL just makes the operation simpler and easier to understand.

| username: DBAER | Original post link

Noted, label-property is no longer recommended.

| username: terry0219 | Original post link

Let me ask again, I created two policies, and the result of show placement is as follows:


The statuses of the two policies are different, one is scheduler and the other is pending. Is this pending status normal?

| username: TiDBer_小阿飞 | Original post link

PENDING: PD did not perform scheduling. One possible reason is that although the placement rules are syntactically correct, the cluster topology does not meet the requirements.
SCHEDULED: PD scheduling completed.
INPROGRESS: PD is currently performing scheduling.

| username: terry0219 | Original post link

Okay, I’ll take another look. Thank you.

| username: terry0219 | Original post link

Let me ask, I have now created this policy: CREATE PLACEMENT POLICY testp2 LEADER_CONSTRAINTS="[+region=cn-beijing-a]" FOLLOWER_CONSTRAINTS='{"+region=cn-beijing-a": 1, "+region=cn-beijing-b": 2, "+region=cn-beijing4-1: 1}';. This policy restricts the leader node to only be placed in cn-beijing-a. If I want to allow the leader node to be placed in either cn-beijing-a or cn-beijing-b, is this achievable?

| username: Jellybean | Original post link

It is recommended to use Placement Rules in SQL.

| username: Jellybean | Original post link

LEADER_CONSTRAINTS can only be set to one label at the same level, otherwise, it will cause conflicts. Therefore, you cannot place the leader in two data centers based on the data center-level label.

However, you can achieve this indirectly. Your issue can be transformed into a scenario where, in the event of a failure in the cn-beijing-a region, you want the new leader to be placed only in cn-beijing-b and not in other regions like cn-beijing4-1. In this case, you can configure a special evict-leader attribute to evict the leader from cn-beijing4-1, ensuring that the leader can only be placed in cn-beijing-b.

So, the conclusion is, you can refer to and try this solution:
CREATE PLACEMENT POLICY testp2 LEADER_CONSTRAINTS=“[+region=cn-beijing-a]” FOLLOWER_CONSTRAINTS=‘{" +region=cn-beijing-a": 1, “+region=cn-beijing-b”: 2, “+region=cn-beijing4-1,#evict-leader”: 1}’;

| username: TiDBer_小阿飞 | Original post link

The solution has already been provided upstairs.
Use evict-leader-{store-id}: evict all Leaders from a specific node.

| username: 这里介绍不了我 | Original post link

Learned a lot, thank you for sharing.

| username: system | Original post link

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