Skip to content

pd not applying placement to partitions of new table #4467

@kolbe

Description

@kolbe

Bug Report

What did you do?

I deployed a cluster of 9 TiKV stores in 3 geographical regions and gave each store a "region" label to match the cloud region it's deployed to.

MySQL [test]> select store_id, address, label from information_schema.tikv_store_status order by store_id;
+----------+------------------+-------------------------------------------------+
| store_id | address          | label                                           |
+----------+------------------+-------------------------------------------------+
|        1 | 10.138.0.7:20160 | [{"key": "region", "value": "us-west1"}]        |
|        4 | 10.138.0.5:20160 | [{"key": "region", "value": "us-west1"}]        |
|        7 | 10.138.0.6:20160 | [{"key": "region", "value": "us-west1"}]        |
|        8 | 10.156.0.4:20160 | [{"key": "region", "value": "europe-west3"}]    |
|        9 | 10.156.0.2:20160 | [{"key": "region", "value": "europe-west3"}]    |
|       10 | 10.156.0.3:20160 | [{"key": "region", "value": "europe-west3"}]    |
|       11 | 10.148.0.4:20160 | [{"key": "region", "value": "asia-southeast1"}] |
|       12 | 10.148.0.3:20160 | [{"key": "region", "value": "asia-southeast1"}] |
|       13 | 10.148.0.2:20160 | [{"key": "region", "value": "asia-southeast1"}] |
+----------+------------------+-------------------------------------------------+
9 rows in set (0.00 sec)

I created 3 placement policies, one for each of the regions where TiKV stores are deployed.

MySQL [test]> show placement;
+-----------------+------------------------------------------------------------+------------------+
| Target          | Placement                                                  | Scheduling_State |
+-----------------+------------------------------------------------------------+------------------+
| POLICY americas | PRIMARY_REGION="us-west1" REGIONS="us-west1"               | NULL             |
| POLICY asia     | PRIMARY_REGION="asia-southeast1" REGIONS="asia-southeast1" | NULL             |
| POLICY europe   | PRIMARY_REGION="europe-west3" REGIONS="europe-west3"       | NULL             |
+-----------------+------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

I created a table with 3 partitions, each of which uses a different placement policy.

MySQL [test]> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `country` char(2) NOT NULL,
  `userdata` varchar(2056) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
PARTITION BY LIST COLUMNS(country) (
  PARTITION `europe` VALUES IN ("DE","FR","GB") /*T![placement] PLACEMENT POLICY=`europe` */,
  PARTITION `americas` VALUES IN ("US","CA","MX") /*T![placement] PLACEMENT POLICY=`americas` */,
  PARTITION `asia` VALUES IN ("SG","CN","JP") /*T![placement] PLACEMENT POLICY=`asia` */
)

MySQL [test]> show placement;
+----------------------------------+------------------------------------------------------------+------------------+
| Target                           | Placement                                                  | Scheduling_State |
+----------------------------------+------------------------------------------------------------+------------------+
| POLICY americas                  | PRIMARY_REGION="us-west1" REGIONS="us-west1"               | NULL             |
| POLICY asia                      | PRIMARY_REGION="asia-southeast1" REGIONS="asia-southeast1" | NULL             |
| POLICY europe                    | PRIMARY_REGION="europe-west3" REGIONS="europe-west3"       | NULL             |
| TABLE test.t1 PARTITION europe   | PRIMARY_REGION="europe-west3" REGIONS="europe-west3"       | INPROGRESS       |
| TABLE test.t1 PARTITION americas | PRIMARY_REGION="us-west1" REGIONS="us-west1"               | INPROGRESS       |
| TABLE test.t1 PARTITION asia     | PRIMARY_REGION="asia-southeast1" REGIONS="asia-southeast1" | INPROGRESS       |
+----------------------------------+------------------------------------------------------------+------------------+
6 rows in set (0.01 sec)
MySQL [test]> select region_id, group_concat(store_id order by store_id) store_id, group_concat(json_extract(label, '$[0].value') order by label) label from information_schema.tikv_region_status join information_schema.tikv_region_peers using (region_id) join information_schema.tikv_store_status using (store_id) where table_name='t1' group by region_id order by region_id;
+-----------+-----------+---------------------------------------------------------------+
| region_id | store_id  | label                                                         |
+-----------+-----------+---------------------------------------------------------------+
|       216 | 8,12,13   | "asia-southeast1","asia-southeast1","europe-west3"            |
|       220 | 1,8,12,13 | "asia-southeast1","asia-southeast1","europe-west3","us-west1" |
|       240 | 10,12,13  | "asia-southeast1","asia-southeast1","europe-west3"            |
+-----------+-----------+---------------------------------------------------------------+
3 rows in set (0.00 sec)

What did you expect to see?

After creating the new table, I expected all replicas for each of the partitions to be placed in the region designated in the associated placement policy.

What did you see instead?

PD does not seem to follow the placement policy.

pd.log

What version of PD are you using (pd-server -V)?

Release Version: v5.3.0
Edition: Community
Git Commit Hash: fe6fab9268d2d6fd34cd22edd1cf31a302e8dc5c
Git Branch: heads/refs/tags/v5.3.0
UTC Build Time:  2021-11-22 01:51:40

Metadata

Metadata

Assignees

No one assigned

    Labels

    type/bugThe issue is confirmed as a bug.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions