TiDB 6.0 Placement Rules In SQL 使用实践-六虎

本文作者：吴永健 tidb.net/u/banana_ji…

简介

TiDB 6.0 版别正式供给了根据 SQL 接口的数据放置框架（Placement Rules in SQL），特性用于经过 SQL 接口配置数据在 TiKV 集群中的放置方位。经过该功用，用户能够将表和分区指定布置至不同的地域、机房、机柜、主机。适用场景包括低本钱优化数据高可用战略、保证本地的数据副本可用于本地 Stale Read 读取、恪守数据本地要求等。它支撑针对恣意数据供给副本数、角色类型、放置方位等维度的灵活调度办理能力，这使得在多事务同享集群、跨 AZ 布置等场景下，TiDB 得以供给更灵活的数据办理能力，满意多样的事务诉求。

该功用能够完成以下事务场景：

兼并多个不同事务的数据库，大幅削减数据库惯例运维办理的本钱
增加重要数据的副本数，进步事务可用性和数据可靠性
将最新数据存入 SSD，历史数据存入 HDD，下降归档数据存储本钱
把热点数据的 leader 放到高功用的 TiKV 实例上
将冷数据别离到不同的存储中以进步可用性

运用放置规矩时有 2 种方法

(1) 直接放置

直接放置是指在 create table 时或运用 alter table 方法直接在表的 DDL 语句中运用放置选项

create table jian(id int) primary_region='bj' folllowers=4

(2) 放置战略

运用放置战略时首要经过 create placement policy 建立放置战略，然后在 create table 或 alter table 中直接指定放置战略。

create placement policy location_policy primary_region='bj' folllowers=4;
alter table jian placement policy location_policy;

运用时：创立放置战略会使 placement policy 愈加易于办理，经过修正放置战略能够直接更新一切运用该战略的对象。另一方面关于 create table 时运用和 alter table 时指定，这儿也主张我们能留意以下两点：

create 方法主张在项目初期的库表结构规划节点进行设定，那么在初始话项目数据库的时分能够一次成型。不然需求将整个表进行recreate，此处就需求考虑历史数据的问题。
alter 方法因为是运用ALTER进行修正当表数据量大的时分或许会发生大量数据peer的移动，或许会消耗一定的资源，主张在事务低峰进行，可是也较好地弥补了一些即存表没有进行放置规矩的设定后期需求增加，或许版别晋级后需求运用新特性的问题。

Placement Rules in SQL 的运用场景猜测

因为 Placement Rules in SQL 的灵活性，在运用时能够“因地适宜”。以下是几个能够考虑的场景：

当采纳两地三中心或跨地域数据中心布置的时分，因为 tidb 是无状况的运用那么能够运用就近原则将事务接入点进行分块，一起关于数据的散布也能够选用相同的方法。使数据的寄存能够达到“本地数据本地访问”，即一切的数据存储，办理在本地区内完成。削减了数据跨地区仿制推迟，下降流量本钱。
当体系 IO 存在某些瓶颈时能够考虑将某些 tikv 节点的数据盘替换为 SSD，之后经过 Placement Rules 动态调整数据副本的寄存战略，进步 db 的 IO 功用。关于一些历史及记录类的数据能够挑选寄存在一些主要由普通硬盘构成的 tikv 节点上。使硬件资源的配置得到充沛的运用，而又不铺张浪费。
一起也考虑当进行硬件替换时能够运用 Placement Rules 对数据散布进行调整以减小 tikv 节点下线时的 peer 移动所需求的时间，因为经过 Placement Rules 能够将数据移动的动作提前进行涣散在平常的小维护中。
因为数据的重要程度不同关于以往的副本设置或许更偏向于大局，引入 Placement Rules in SQL 后关于数据的副本数就能够进行灵活的限定，对高要求的数据表进行多副本设置，关于不太重要的表尽量的减小副本数，在保证数据的安全性的情况下又能够节省存储资源。
假如事务选用了分库的模式为了削减运维本钱，那么也能够考虑进行数据库整合，将涣散的 mysql 实例迁移到一个 Tidb 集群中以多 schema 的方法存在，一起根据 Placement Rules 原始事务数据库的数据寄存节点仍然能够放置在本来的硬件节点上，可是逻辑上因为整合到了一个数据库集群中晋级、打补丁、备份计划、扩缩容等日常运维办理频率能够大幅减缩，下降办理担负提高效率。
关于经典的热点问题在 Placement Rules in SQL 也增加了更多的解决方案，经过 Placement Rules in SQL 也能够进行热点表的散布调整，并且也愈加的便利与安全。尽管不能准确到 region 的等级，可是在表的粒度上也多供给了一种处理方法。

下面咱们来详细看看 placement policy 的运用方法：

当时 tikv 节点以及集群的信息如下：

ID                     Role          Host             Ports        OS/Arch       Status   Data Dir                      Deploy Dir
\--                     ----          ----             -----        -------       ------   --------                      ----------
192.168.135.148:9093   alertmanager  192.168.135.148  9093/9094    linux/x86_64  Up       /tidb-data/alertmanager-9093  /tidb-deploy/alertmanager-9093
192.168.135.148:3000   grafana       192.168.135.148  3000         linux/x86_64  Up       -                             /tidb-deploy/grafana-3000
192.168.135.148:2379   pd            192.168.135.148  2379/2380    linux/x86_64  Up|L|UI  /tidb-data/pd-2379            /tidb-deploy/pd-2379
192.168.135.148:9090   prometheus    192.168.135.148  9090/12020   linux/x86_64  Up       /tidb-data/prometheus-9090    /tidb-deploy/prometheus-9090
192.168.135.148:4000   tidb          192.168.135.148  4000/10080   linux/x86_64  Up       -                             /tidb-deploy/tidb-4000
192.168.135.148:20160  tikv          192.168.135.148  20160/20180  linux/x86_64  Up       /tidb-data/tikv-20160         /tidb-deploy/tikv-20160
192.168.135.148:20161  tikv          192.168.135.148  20161/20181  linux/x86_64  Up       /tidb-data/tikv-20161         /tidb-deploy/tikv-20161
192.168.135.148:20162  tikv          192.168.135.148  20162/20182  linux/x86_64  Up       /tidb-data/tikv-20162         /tidb-deploy/tikv-20162

这儿有一点需求我们留意一下：默许的 PLACEMENT POLICY 是需求以 region 来作为区分标签的，所以在创立 tikv 的时分这儿需求明确的指定 tikv 的 region 的标签，不然的话在show placement labels 是无法看到 region lable 的。这儿能够参照官方文档的主张

PLACEMENT RULES的运用

1. 创立 PLACEMENT POLICY，并指定 PLACEMENT POLICY，定制其副本放置的方位

这儿创立一个 PLACEMENT POLICY 使其 PRIMARY_REGION 放置在 region lable 为 bj 的 tikv 节点上，其余副本放置在 region lable 为 dl,sz 的 tikv 节点上

留意：primary region 必须包含在 region 的界说中

此处的 Raft leader 在 4 号 store 上，看之前最初的环境信息能够验证 PLACEMENT POLICY 现已收效


(root\@127.0.0.1) \[test] 12:00:14> CREATE PLACEMENT POLICY jianplacementpolicy PRIMARY_REGION="bj" REGIONS="bj,dl,sz";
Query OK, 0 rows affected (0.10 sec)
(root\@127.0.0.1) \[test] 12:00:32> CREATE TABLE jian1 (id INT) PLACEMENT POLICY=jianplacementpolicy;
Query OK, 0 rows affected (0.10 sec)
(root\@127.0.0.1) \[test] 12:03:36> show table jian1 regions\G
REGION_ID: 135
START_KEY: t_68\_
END_KEY: t_69\_
LEADER_ID: 137
LEADER_STORE_ID: 4    这儿能够看到store_id是4                                
PEERS: 136, 137, 138
SCATTERING: 0
WRITTEN_BYTES: 39
READ_BYTES: 0
APPROXIMATE_SIZE(MB): 1
APPROXIMATE_KEYS: 0
1 row in set (0.00 sec)

2. 创立表不指定 PLACEMENT POLICY，之后修正 PLACEMENT POLICY 定制其副本放置的方位

leader 的 store 节点由本来的 1 变为了 4，看之前最初的环境信息能够验证 PLACEMENT POLICY 现已收效,可运用这个特性来修正表的leader节点或许当有热点问题时也能够变相的经过这种方法去修正频频访问的表的leader地点的tikv的节点方位

(root\@127.0.0.1) \[test] 12:03:39> create table jian2(id int);
Query OK, 0 rows affected (0.10 sec)
(root\@127.0.0.1) \[test] 12:05:14> show table jian2 regions\G
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
REGION_ID: 2
START_KEY: t_70\_
END_KEY:
LEADER_ID: 3
LEADER_STORE_ID: 1
PEERS: 3, 63, 85
SCATTERING: 0
WRITTEN_BYTES: 0
READ_BYTES: 0
APPROXIMATE_SIZE(MB): 1
APPROXIMATE_KEYS: 0
1 row in set (0.00 sec)
(root\@127.0.0.1) \[test] 12:05:16> alter table jian2  PLACEMENT POLICY=jianplacementpolicy;
Query OK, 0 rows affected (0.09 sec)
(root\@127.0.0.1) \[test] 12:05:50>  show table jian2 regions\G
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
REGION_ID: 143
START_KEY: t_70\_
END_KEY: t_71\_
LEADER_ID: 145
LEADER_STORE_ID: 4                       
PEERS: 144, 145, 146
SCATTERING: 0
WRITTEN_BYTES: 0
READ_BYTES: 0
APPROXIMATE_SIZE(MB): 1
APPROXIMATE_KEYS: 0
1 row in set (0.00 sec)

3. 经过 PLACEMENT POLICY 修正表的副本数

Follower 的数量。例如 FOLLOWERS=2 表明数据有 3 个副本（2 个 follower 和 1 个 leader）。

(root\@127.0.0.1) \[test] 12:10:34> alter  PLACEMENT POLICY jianplacementpolicy FOLLOWERS=1;
Query OK, 0 rows affected (0.11 sec)
(root\@127.0.0.1) \[test] 12:10:40>  show table jian2 regions\G
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
REGION_ID: 143
START_KEY: t_70\_
END_KEY: t_71\_
LEADER_ID: 145
LEADER_STORE_ID: 4
PEERS: 144, 145                    **副本数从 3 个现已调整到了 2 个
**
SCATTERING: 0
WRITTEN_BYTES: 0
READ_BYTES: 0
APPROXIMATE_SIZE(MB): 1
APPROXIMATE_KEYS: 0
1 row in set (0.00 sec)
(root\@127.0.0.1) \[test] 12:10:44> alter  PLACEMENT POLICY jianplacementpolicy FOLLOWERS=2;
Query OK, 0 rows affected (0.09 sec)
(root\@127.0.0.1) \[test] 12:10:59>  show table jian2 regions\G
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
REGION_ID: 143
START_KEY: t_70\_
END_KEY: t_71\_
LEADER_ID: 145
LEADER_STORE_ID: 4
PEERS: 144, 145, 148
SCATTERING: 0
WRITTEN_BYTES: 0
READ_BYTES: 0
APPROXIMATE_SIZE(MB): 1
APPROXIMATE_KEYS: 0
1 row in set (0.02 sec)

4. 修正 PLACEMENT POLICY 界说

留意：修正界说时需求将本来的界说都带上不然会将其掩盖 这一点在官方文档中并没有特殊说明，也是自己在测试这个功用的时分偶然的发现，目前官方也没有直接修正的语法，所以我们在修正放置规矩的时分一定要留意之前的界说避免将之前的界说掩盖。

##########################################################
之前的 PRIMARY_REGION="bj" REGIONS="bj,dl,sz" 界说现已被掩盖了
##########################################################

5. PRIMARY_REGION 节点宕机

假如 PRIMARY_REGION 的 tikv 节点宕机，那么 leader 节点也会搬运到非 PRIMARY_REGION 节点，当 tikv 节点康复正常后 leader 节点也会随之搬运回来

以下的进程

leader 节点：store4– 停止 store 的 tikv —》store1 — 康复 tikv 节点– 》store4

6. 更改 PRIMARY_REGION

假如更改表当时 palcement policy 界说的 primary region 那么表的 leader 也会随 PRIMARY_REGION 的改动而改动

下图 jian1 表一开始的 region 1005 的 leader 是在 store4（bj）上边,之后修正其 PRIMARY_REGION 为 dl(store 1),能够看到 region 1005 的 leader 也确实随之发生了改动

7. PLACEMENT POLICY 相同适用与分区表

以下样例中咱们手动指定了每一个分区的 PLACEMENT POLICY，使其每个分区的 leader 都寄存于不同的 store 上。

CREATE PLACEMENT POLICY policy_table FOLLOWERS=3;
CREATE PLACEMENT POLICY policy_dl PRIMARY_REGION="dl" REGIONS="dl,bj,sz";
CREATE PLACEMENT POLICY policy_bj PRIMARY_REGION="bj" REGIONS="dl,bj,sz";
CREATE PLACEMENT POLICY policy_sz PRIMARY_REGION="sz" REGIONS="dl,bj,sz" FOLLOWERS=1;
SET tidb_enable_list_partition = 1;
CREATE TABLE t1 (
location VARCHAR(10) NOT NULL,
userdata VARCHAR(100) NOT NULL
) PLACEMENT POLICY=policy_table PARTITION BY LIST COLUMNS (location) (
PARTITION p_dl VALUES IN ('dl') PLACEMENT POLICY=policy_dl,
PARTITION p_bj VALUES IN ('bj') PLACEMENT POLICY=policy_bj,
PARTITION p_sz VALUES IN ('sz') PLACEMENT POLICY=policy_sz
);

下图可一看到t1的region分别寄存在store 1(dl),4(bj),5(sz)上边

8. 检查数据库中现有的 PLACEMENT POLICY

9. 设置数据库等级的 PLACEMENT POLICY

更改默许的放置选项，但更改不影响已有的表

创立新表会主动承继当时数据的放置规矩

表等级的放置规矩要优先于数据库等级的放置规矩

10. 高档放置规矩

留意：PRIMARY_REGION、REGIONS 和 SCHEDULE 选项不可与 CONSTRAINTS 选项一起指定，不然会报错

以下 placement policy 的解读为：

运用该规矩的表的 region 只能够放置在含有 rack 标签且等于 rack1 的 tikv 节点上

运用该规矩的表的 leader region 只能够放置在含有 dc 标签且等于 bja 的 tikv 节点上

运用该规矩的表的 follower region 只能够放置在含有 dc 标签且等于 dla 的 tikv 节点上


(root\@127.0.0.1) \[(none)] 16:34:28>  create placement policy localtion_policy CONSTRAINTS="\[+rack=rack1]" LEADER_CONSTRAINTS="\[+dc=bja]" FOLLOWER_CONSTRAINTS="{+dc=dla: 1}";
Query OK, 0 rows affected (0.10 sec)
(root\@127.0.0.1) \[(none)] 16:35:41> create table testdb.jian2(id int) placement policy=localtion_policy;
Query OK, 0 rows affected (0.19 sec)
(root\@127.0.0.1) \[(none)] 16:35:49> show table testdb.jian2 regions\G
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
REGION_ID: 1127
START_KEY: t_167\_
END_KEY: t_168\_
LEADER_ID: 1129
LEADER_STORE_ID: 4
PEERS: 1128, 1129
SCATTERING: 0
WRITTEN_BYTES: 0
READ_BYTES: 0
APPROXIMATE_SIZE(MB): 1
APPROXIMATE_KEYS: 0
1 row in set (0.01 sec)

留意：尽管 placement policy 高档匹配规矩的默许 followers 是 2（三副本）可是实践的副本数还是要看契合 lable 的 tikv 的数量,假如实践的tikv节点数量无法满意2followers 那么终究也只会有两个副本（也就是只要一个followers和一个leader）上边的查询结果能够看到实践 region 的副本只要两个，可是当查询 localtion_policy 这个规矩界说的时分 followers 为 2

POLICY_ID: 17
CATALOG_NAME: def
POLICY_NAME: localtion_policy
PRIMARY_REGION:
REGIONS:
CONSTRAINTS: \[+rack=rack1]
LEADER_CONSTRAINTS: \[+dc=bja]
FOLLOWER_CONSTRAINTS: {+dc=dla: 1}
LEARNER_CONSTRAINTS:
SCHEDULE:
FOLLOWERS: 2
LEARNERS: 0

11. placement policy 的创立选项

选项名	描绘
PRIMARY_REGION	Raft leader 被放置在有 region 标签的节点上，且这些 region 标签匹配本选项的值。
REGIONS	Raft followers 被放置在有 region 标签的节点上，且这些 region 标签匹配本选项的值。
SCHEDULE	用于调度 follower 放置方位的战略。可选值为 EVEN（默许值）或 MAJORITY_IN_PRIMARY。
FOLLOWERS	Follower 的数量。例如 FOLLOWERS=2 表明数据有 3 个副本（2 个 follower 和 1 个 leader）。
CONSTRAINTS	适用于一切角色 (role) 的束缚列表。例如，CONSTRAINTS=”[+disk=ssd]”。
LEADER_CONSTRAINTS	仅适用于 leader 的束缚列表。
FOLLOWER_CONSTRAINTS	仅适用于 follower 的束缚列表。
LEARNER_CONSTRAINTS	仅适用于 learner 的束缚列表。
LEARNERS	指定 learner 的数量。

12. 删除 placement policy

删除 placement policy 时一定要保证没有任何表在运用当时的 placement policy 不然会报错

(root\@127.0.0.1) \[test] 12:11:43> drop PLACEMENT POLICY jianplacementpolicy;
ERROR 8241 (HY000): Placement policy 'jianplacementpolicy' is still in use
(root\@127.0.0.1) \[test] 12:16:20> alter table jian1 PLACEMENT POLICY=default;
Query OK, 0 rows affected (0.08 sec)

检查某个 placement policy 是否正在被表运用

SELECT table\_schema, table\_name FROM information\_schema.tables WHERE tidb\_placement\_policy\_name='jianplacementpolicy';
SELECT table\_schema, table\_name FROM information\_schema.partitions WHERE tidb\_placement\_policy\_name='jianplacementpolicy';

总结

当时版别在运用 Placement Rules in SQL 时假如运用根本的放置规矩那么只能够运用 PRIMARY_REGION 和 REGIONS 来进行放置规矩的设置，可是假如运用高档放置规矩那么 tikv 的 label 标签不需求必须设置 region 层级的标签，能够灵活运用和界说已存在或许需求的标签。

高档放置规矩的默许 followers 的数量为 2，可是假如在设置规矩 FOLLOWER_CONSTRAINTS 时假如满意的节点不满意 2 时只会在 FOLLOWER_CONSTRAINTS 匹配的节点上创立副本，这一点在创立时一定要规划好自己的集群中的 tikv 节点的标签规划，避免导致 region 的副本数过少。

Placement Rules in SQL 能够经过它对分区 / 表 / 库不同等级的数据进行根据标签的自在放置。

总之 TiDB 6.0 的 Placement Rules In SQL 暴露了以往用户无法控制的内部调度能力，并供给了便利的 SQL 接口，这敞开了许多以往不或许完成的场景，更多的运用方法与运用场景还期待各位的发掘。

TiDB 6.0 Placement Rules In SQL 使用实践

简介