ddl, store: Remove placement rules when the GC worker removes partitions

[djshow832]

What problem does this PR solve?

Issue Number: close #18411

Problem Summary:
When the user drops a partitioned table, the placement rules on the partitions should be dropped. But this cannot be done immediately, because the user may recover it by flashback or recover statements.
So the placement rules should be kept until the GC worker removes the corresponding ranges.

What is changed and how it works?

What's Changed:
Remove the placement rules when the GC worker runs GC job.
Note that truncating table doesn't work well, because there's a bug in truncating partitioned table: the partitions become less after truncating.

mysql> create table t1(id int primary key) partition by hash(id) partitions 2;
Query OK, 0 rows affected (0.08 sec)

mysql> show table t1 regions;
+-----------+-----------+---------+-----------+-----------------+-------+------------+---------------+------------+----------------------+------------------+
| REGION_ID | START_KEY | END_KEY | LEADER_ID | LEADER_STORE_ID | PEERS | SCATTERING | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE(MB) | APPROXIMATE_KEYS |
+-----------+-----------+---------+-----------+-----------------+-------+------------+---------------+------------+----------------------+------------------+
|        50 | t_50_     | t_51_   |        51 |               1 | 51    |          0 |        103770 |          0 |                    1 |                0 |
|         2 | t_51_     |         |         3 |               1 | 3     |          0 |           870 |          0 |                    1 |                0 |
+-----------+-----------+---------+-----------+-----------------+-------+------------+---------------+------------+----------------------+------------------+
2 rows in set (0.00 sec)

mysql> truncate table t1;
Query OK, 0 rows affected (0.07 sec)

mysql> show table t1 regions;
+-----------+-----------+---------+-----------+-----------------+-------+------------+---------------+------------+----------------------+------------------+
| REGION_ID | START_KEY | END_KEY | LEADER_ID | LEADER_STORE_ID | PEERS | SCATTERING | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE(MB) | APPROXIMATE_KEYS |
+-----------+-----------+---------+-----------+-----------------+-------+------------+---------------+------------+----------------------+------------------+
|         2 | t_51_     |         |         3 |               1 | 3     |          0 |           870 |          0 |                    1 |                0 |
+-----------+-----------+---------+-----------+-----------------+-------+------------+---------------+------------+----------------------+------------------+
1 row in set (0.02 sec)

Furthermore, rule cache doesn't change in this PR. It will be implemented in the next PR.

How it Works:

1. Get the job from job history.
2. If the job is not drop table or truncate table job, or the dropped table is not a partitioned table, skip it.
3. Get the partition id from the delete task.
4. Generate a drop task, and notifies the PD to remove it.

Related changes

• N/A

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)

mysql> create table t1(id int primary key) partition by hash(id) partitions 2;
Query OK, 0 rows affected (0.08 sec)

mysql> alter table t1 alter partition p0 alter placement policy constraints='["+zone=bj"]' role=voter replicas=3;
Query OK, 0 rows affected (0.09 sec)

Check out the placement rules:

curl http://127.1:2379/pd/api/v1/config/placement-rule
[
  {
    "group_id": "pd",
    "group_index": 0,
    "group_override": false,
    "rules": [
      {
        "group_id": "pd",
        "id": "default",
        "start_key": "",
        "end_key": "",
        "role": "voter",
        "count": 3
      }
    ]
  },
  {
    "group_id": "TIDB_DDL_50",
    "group_index": 3,
    "group_override": true,
    "rules": [
      {
        "group_id": "TIDB_DDL_50",
        "id": "0",
        "start_key": "7480000000000000ff3200000000000000f8",
        "end_key": "7480000000000000ff3300000000000000f8",
        "role": "voter",
        "count": 3,
        "label_constraints": [
          {
            "key": "zone",
            "op": "in",
            "values": [
              "bj"
            ]
          }
        ]
      }
    ]
  }
]

mysql> drop table t1;
Query OK, 0 rows affected (0.22 sec)

Check the placement rule immediately, we found it doesn't change:

curl http://127.1:2379/pd/api/v1/config/placement-rule
[
  {
    "group_id": "pd",
    "group_index": 0,
    "group_override": false,
    "rules": [
      {
        "group_id": "pd",
        "id": "default",
        "start_key": "",
        "end_key": "",
        "role": "voter",
        "count": 3
      }
    ]
  },
  {
    "group_id": "TIDB_DDL_50",
    "group_index": 3,
    "group_override": true,
    "rules": [
      {
        "group_id": "TIDB_DDL_50",
        "id": "0",
        "start_key": "7480000000000000ff3200000000000000f8",
        "end_key": "7480000000000000ff3300000000000000f8",
        "role": "voter",
        "count": 3,
        "label_constraints": [
          {
            "key": "zone",
            "op": "in",
            "values": [
              "bj"
            ]
          }
        ]
      }
    ]
  }
]

After 10 minutes:

curl http://127.1:2379/pd/api/v1/config/placement-rule
[
  {
    "group_id": "pd",
    "group_index": 0,
    "group_override": false,
    "rules": [
      {
        "group_id": "pd",
        "id": "default",
        "start_key": "",
        "end_key": "",
        "role": "voter",
        "count": 3
      }
    ]
  }
]

We can see that the placement rule is deleted.

Side effects

• N/A

Release note

• Remove placement rules when the GC worker removes partitions.

[tangenta]

LGTM

[AilinKid]

LGTM

[AilinKid]

/run-all-tests

[AilinKid]

/merge

[ti-srebot]

/run-all-tests

[ti-srebot]

@djshow832 merge failed.