TiDB Placement Rule 实战总结
作者： dba-kit 原文来源：https://tidb.net/blog/82b0b4e5
一、背景
Placement Rule in SQL从 v6.1 开始正式 GA，但是还是有很多小伙伴对其并不熟悉。具体原理和隔离效果，本篇文章就不做过多介绍了，TUG 社区中已经有很多类似的文章介绍，我重点介绍一下在实践中的实战方案，给大家参考一下，让大家少走一些弯路。这里先列一下在实际中遇到的一些问题：
1. 什么是Placement Rule in SQL？
想知道什么是Placement Rule in SQL，首先要了解什么是Placement Rule？Placement Rule是 TiDB 4.0 就有的一个特性，它是一套副本规则系统，用于指导 PD 针对不同类型的数据生成对应的调度。通过组合不同的调度规则，用户可以精细地控制任何一段连续数据的副本数量、存放位置、主机类型、是否参与 Raft 投票、是否可以担任 Raft leader 等属性 (偷懒摘自官方文档)。但是Placement Rule必须先通过 tidb-ctl 获取对应表的 StartKey 和 EndKey，再通过 pd-ctl 来设置具体的规则，很不方便，当对表执行 DDL 时 StartKey 和 EndKey 还可能会发生变化，需要手动调整规则很容易踩坑，所以使用的人很少。而Placement Rule in SQL则是可以通过 SQL 来设置Placement Rule，更便捷灵活，适应性更强。
2. 什么场景下才需要使用Placement Rule in SQL？
这个问题，其实在官方 Placement Rule in SQL 文档里有列举：
合并多个不同业务的数据库，大幅减少数据库常规运维管理的成本
增加重要数据的副本数，提高业务可用性和数据可靠性
将最新数据存入 NVMe，历史数据存入 SSD，降低归档数据存储成本
把热点数据的 leader 放到高性能的 TiKV 实例上
将冷数据分离到不同的存储中以提高可用性
支持物理隔离不同用户之间的计算资源，满足实例内部不同用户的隔离需求，以及不同混合负载 CPU、I/O、内存等资源隔离的需求
对我而言，主要功能有两点：
隔离 TP 和 AP 的数据：线上 TiDB 集群是个混合集群，既汇总了多个 MySQL 产生的数据，又存在数仓团队的分析数据，数仓团队在计算时候，经常会导致整个 TiDB 集群负载很高。
冷热分离：有多个大表的历史数据基本不会被查询，但是占用了大量空间，每个月增量数据有 1T 左右，必须经常扩容 TiKV 节点，集群成本很高。
而这两种需求都可以通过Placement Rule in SQL来实现。
二、配置指南
1. TiKV 设置合适的 Labels 值
不管是资源隔离、还是冷热分离，都是要将 TiKV 节点分成不同组，所以必须要提前规划好。有两种方法可以修改 TiKV 的 Label：
通过 TiKV 的配置参数：在初始化时候就设置好
server.labels通过 pd-ctl 来设置：初始化后，可以通过
pd-ctl store label命令来修改
注意： store 的 label 更新方法使用的是合并策略。如果修改了 TiKV 配置文件中的 store label，进程重启之后，PD 会将自身存储的 store label 与其进行合并更新，并持久化合并后的结果。
2. PD 设置location-labels
具体可以参考： 设置 PD 的 location-labels 配置，这个参数的值要和 TiKV 设置的 Label 对应，其次需要注意的是，TiDB 会按照设置的数组的层级来尽可能平均的分布数据，也就是说要尽可能保证机器在每个层都是平均分布的，如果机器分布不平均，就可能会有这个帖子一样的疑问，发现不同区的 TiKV 磁盘使用率不一样。
3. TiDB 执行Placement Rule in SQL制定合适的规则
现在假定集群有 9 台 TiKV 节点 (6 台高性能 NVMe-SSD 分为 TP、AP 两组，3 台大容量 HDD 存冷数据)，配置设置如下：
location-labels:"zone,dc,host,disk"。TP 组的 TiKV 节点的
server.labels中增加:"disk": "tp-ssd"AP 组的 TiKV 节点的
server.labels中增加:"disk": "ap-ssd"冷数据 TiKV 节点的
server.labels中增加:"disk": "hdd"之后，就可以在通过Placement Rule in SQL创建对应的三个规则：
之后就可以对分区、表、库级别来设置相应的规则，将对应的 region 限制到特定 TiKV 节点，例子如下：
这里需要注意的是PLACEMENT POLICY和CHARSET比较类似，只有建表时没有指定放置策略的时候，表才会从数据库继承放置策略，一旦表创建之后再改变数据库的PLACEMENT POLICY，只会对新表有效，对旧表是无效的。同样分区表也和 CHARSET 类似，改变表的放置策略，也会让分区应用新的放置策略。
三、实战
3.1 如何保证只有冷数据才会放到 HDD 节点中？
在冷热分离这个场景下，在引入 HDD 节点之前，必须要考虑一个问题：如何保证不影响正常数据的写入？也就是如何保证只有冷数据才会放到 HDD 节点中？举个例子：
现在有一套 TiDB 汇总了线上 20 套 MySQL 的表，并通过白名单方式对所有 database 都执行了ALTER DATABASE test PLACEMENT POLICY=`on_tp_ssd`，保证现有 database 的数据只放到 TP SSD 节点上。但是如果后续有新业务上线，在某个 MySQL 上创建了一个新的 database，而 TiDB 上因为疏忽，并没有修改PLACEMENT POLICY=`on_tp_ssd` 会发生什么事情呢？这个 database 下面所有的表，数据都均匀分布在所有节点中，既可能是 AP SSD 节点、也可能是 HDD 节点，完全没办法达到资源隔离的牡蛎，肯定会影响 TP 数据的写入效率的。
可能细心的同学在上面就已经发现，在 TiDB 是可以通过将PLACEMENT POLICY设置为default的方式，让表使用默认的规则，那么我们可以修改名为default的PLACEMENT POLICY么？
答案是不可以的，不过可以通过其他方式实现类似的需求，以下是我梳理的操作步骤：
注意：此处为了突出黑名单功能，对场景做了简化，假定 disk 这个 label 只包含[“hdd”, “ssd”]两个值，我们只想保证热数据不放入 HDD。我们线上其实是通过白名单方式，让默认数据值放在 disk=on_tp_ssd 的磁盘上，配置文件会略有区别，不过原理不变。
7.5 之前：通 pd-ctl 设置
7.5 之前 default 的 placement-rule 没办法通过Placement rule in SQL的方式来直接修改，只能通过原始的 pd-ctl 来修改。原理可以参考下面官方文章。详细的执行步骤如下：
查看当前的 default 规则
正常来说，rules.json里的内容应该是
只需要手动修改
rules.json，在 json 中增加一个基于 lable 的label_constraints，排除掉 HDD 节点的 label(这里假定每个 HDD 节点，lables 里都有disk: hdd这个参数)，这种情下配置如下：将配置应用到 pd 中
7.5 之后：通过 SQL 来设置
7.5 之后，TiDB 新增了一个ALTER RANGE的语法，现在 ALTER RANGE 能起作用的有 global 和 meta 两个参数：
global：表示集群内全域数据的范围；meta：表示 TiDB 内部存储的元信息的数据范围。
操作步骤如下：
创建放置规则，并将其设置为
global级别其实原理和我们手动设置的类似，也是设置了
group_id=TiDB_GLOBAL一个全局的放置规则，具体内容如下：
3.2 在使用冷热后，如何兼顾查询历史数据的效率？
如果某个大表十分重要，有很多业务都会使用到，在某些场景下还需要使用历史数据进行分析，在预算充足的情况下，这种情况处理起来也简单，申请资源扩容 TiKV 节点就可以了。不过当你申请资源时候，大多数情况下老板的回答是，既要想办法降低存储成本，又要不影响分析查询的性能，降本和增效一个都不能少。不过这也是为数不多，我们 DBA 能刷存在感的时机了，能提出合理的解决方案，才能体现我们不是吃干饭的。常见的历史数据查询场景是，大多数业务只会查询最近几个月的数据，只有少数的报表才需要查询历史数据，根据这种场景：
最简单处理方式就是只把历史分区放置在 HDD 节点中，最近几个月数据放在 SSD 节点中，不过这种架构会导致一些分析类查询变得非常慢。如果老板希望看最近几年的业务增长曲线，结果在 Tableau 页面点击查询后，半天没有响应甚至查询失败后，显然会置疑 TiDB 的能力，不是说 TiDB 是 HTAP 全能数据库么，怎么查一年的业务增量需要时间这么长，比 MySQL 还慢。这必然会影响你在老板心中解决问题的能力。
更好的解决方案需要利用 Tiflash 列式存储引擎，将历史数据放到 HDD 节点中减少 SSD 储存数据量，对整表增加 Tiflash 副本 (单副本 / 多副本均可，副本个数的提升对查询性能影响不大更多是可用性的提升)。由于 TiFlash 对高并发支持并不友好，这种方案的前提是只有少量 AP 类查询会查询历史数据，不会有高并发查询历史数据的场景。
PS：
记得要开启分区动态裁剪功能，这个可以让分区表的查询变快。(6.5 之后，默认开启)
由于 7.1 之前 TiFlash 并不会将 WHERE 条件下推，导致即便只需要查询部分数据 (例如某一年 / 月数据)， TiFlash 也会从磁盘扫描某几列全部数据到内存中，在内存中完成过滤，所以即便是 API 类查询，性能也可能比 TiKV 还慢。7.1 之后
TiFlash延迟物化功能GA，默认会开启tidb_opt_enable_late_materialization，上述场景的查询会有较大的性能提升，TiFlash 适应的场景会更广泛。延迟物化是指：TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。PPS: 7.4.0 之后TiFlash 存储计算资源分离和 S3 共享存储 (GA)，TiFlash 支持存储和计算资源分离，提升 HTAP 资源的弹性能力，可以将全量数据基于 S3 的存储引擎，以更低的成本提供共享存储，给所有表都增加 TiFlash 副本的成本变的很低很低。PPPS: 现在 7.5.0 LTS 也已经在 2023-12-01 发布了，强烈建议大家在测试环境验证验证新版本，在观望一段时候后，将重要性没那么强的集群先升级到 7.5.0。当然关键的正式集群，最好至少等到 7.5.2 之后再考虑升级，别做小白鼠。
3.3 如何快速将非分区表改造为分区表？
线上有一套 TiDB 集群汇总了所有 MySQL 表，由于不是所有业务在上线前，都会根据表的预期数据增量来考虑是否需要对表进行分区，导致往往是排查空间问题时，才发现是某个上游 MySQL 上出现新的数据量特别大的表，且没有提前周知给我们。在这种情况下，如何高效的将非分区表改造为分区表呢？
6.1 之后 7.5 之前：通过EXCHANGE PARTITION间接改造
由于 TiDB 6.1 之后支持了EXCHANGE PARTITION操作，可以基于EXCHANGE PARTITION，来将快速的将非分区表改造为分区表。我总结出来的操作步骤是：
基于当前表创建对应的分区表。(第一个分区的上界要大于表的当前最大值)
使用
EXCHANGE PARTITION操作，将非分区表数据交换到分区表第一个分区中交换非分区表和分区表的表名
最后，别忘记第二步还有个 warning，经过 EXCANGE 之后，需要对新表进行
analyze table操作，才会生成全局的动态裁剪统计信息。
需要注意的是：
这种场景下，在 EXCHANGE PARTITION 后，RENAME TABLE 之前，这期间可能会有几秒中业务查询 t1 表会是个空表，需要提前跟业务沟通好，找个业务低峰期处理。
TiDB 在开启聚簇索引后是不支持修改主键的，而开启冷热分离一般来说是将某个时间字段加到主键中，根据时间字段来分区，也就是需要更改表的主键，所以强烈建议汇总类的 TiDB 集群的
tidb_enable_clustered_index参数最好设置为OFF，这样 MySQL 上新增的表默认才会是NONCLUSTERED的，可以方便的修改大表的主键。(6.5 之前默认值是INT_ONLY，6.5 之后默认值是ON，在默认情况下，基本上 90% 的表是不能直接进行分区化改造的)
7.5 之后：官方支持非分区表和分区表之间的相互转换
详细内容可以看：官方文档，直接一条 SQL 就能更改。
不过，别忘记官方文档里说的：该语句在执行时，将根据新的分区定义复制表中的所有行，并在线重新创建索引。这是一个非常非常重的操作，如果表已经非常大了，还是建议按照手动操作步骤来变更，可以减少行的复制操作。
总结
本篇文章，总结了一下通过Placement Rule完成业务隔离、冷热隔离放的实战经验，通过上述描述，大家也能看到 7.5 的新功能可以规避很多非常规的骚操作。其实不仅如此，7.5 在资源管控、DDL 等后台任务控制、TiFlash 等其他方面也对用户更加友好了，希望大家在测试环境多多验证，尽量早上生产。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/52b50888f2b75089bd93a4f21】。文章转载请联系作者。
TiDB 社区官网:https://tidb.net/ 2021-12-15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论