TiDB 6.0 Placement Rules In SQL 使用实践

原创

于 2022-08-04 11:39:13 发布 · 564 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#sql #数据库 #服务器

本文介绍了TiDB 6.0版本中的PlacementRulesinSQL，允许用户通过SQL配置数据在TiKV集群的位置，优化数据分布、降低成本并增强数据可用性。通过创建和应用placement policy，用户可以灵活控制副本数、角色和存储位置，适用于多中心部署、成本优化和本地数据访问等场景。

本文作者：吴永健 https://tidb.net/u/banana_jian

简介

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