tidb本周精选 2021年的第 31 周

• TiKV 是一个分布式事务型的键值数据库，提供了满足 ACID 约束的分布式事务接口，并且通过 Raft 协议保证了多副本数据一致性以及高可用。
• TiKV 作为 TiDB 的存储层，为用户写入 TiDB 的数据提供了持久化以及读写服务，同时还存储了 TiDB 的统计信息数据。

TiKV 整体架构：

• 与传统的整节点备份方式不同，TiKV 参考 Spanner 设计了 multi-raft-group 的副本机制。

将数据按照 key 的范围划分成大致相等的切片（下文统称为 Region），每一个切片会有多个副本（通常是 3 个），其中一个副本是 Leader，提供读写服务。

• TiKV 通过 PD 对这些 Region 以及副本进行调度，以保证数据和读写负载都均匀地分散在各个 TiKV 上，这样的设计保证了整个集群资源的充分利用并且可以随着机器数量的增加水平扩展。

点击链接了解更多

【TiKV 参数调整问题】

有关 TiKV 的参数调整方面，你是否存有疑惑，不知道该如何解决？本周我们为你精选多条 TiKV 参数调整相关的优质帖，希望可以帮你答疑解惑。

FQA1-TiKV 底层存储，磁盘的问题

https://asktug.com/t/topic/33057

问：对磁盘进行扩容可用吗？

【问题描述】：你好，我们目前的tidb 集群是3个tikv server 。我们现在遇到一个磁盘扩容和IO的问题。

• 问题一：我们现在的磁盘是1块2T的raid 0 。考虑到后期数据增长超过2T的数据， 我们要扩容，后期继续加一块或者多块盘，数据是否可以支持多块盘存储？不行的话磁盘扩容怎么扩容呢？
• 问题二：关于IO 的问题，io达到瓶颈的话，我在tikv 服务器上增加一块或者多块盘，是否可以缓解，如果无法解决，你们有没有什么方案推荐。

答：

1. 不建议通过加盘方式扩容，TiKV 目前最佳性能应该在 SSD 在 1.5 TB - 2 TB，

如果容量扩容，建议采用 TiKV 扩容方式增加 TiKV 节点，这样存储和计算性能都会有提升；

1. 由于 Region 的副本数与 TiKV 实例数量无关 同城多数据中心部署 TiDB https://docs.pingcap.com/zh/tidb/v4.0/multi-data-centers-in-one-city-deployment

由于 3 副本的 Raft Group 只能容忍 1 副本故障，当集群被扩容到 N 个 TiKV 实例时，这个集群依然只能容忍一个 TiKV 实例的故障。

2 个 TiKV 实例的故障可能会导致某些 Region 丢失多个副本，整个集群的数据也不再完整，访问到这些 Region 上的数据的 SQL 请求将会失败。

而 N 个 TiKV 实例中同时有两个发生故障的概率是远远高于 3 个 TiKV 中同时有两个发生故障的概率的，也就是说 Multi-Raft 系统集群扩容 TiKV 实例越多，其可用性是逐渐降低的。

1. TiDB 默认是 3 副本，如何修改 https://hub.fastgit.org/tikv/pd/blob/v4.0.0-beta/conf/config.toml#L95 [replication]

The number of replicas for each region.

max-replicas = 3

比如集群的拓扑结构分成三层：机房（zone) -> 机架（rack）-> 主机（host），就可以使用这 3 个标签来设置 TiKV 的位置。

假设集群副本数设置为 3（max-replicas=3），因为总共有 3 个 zone，PD 会保证每个 Region 的 3 个副本分别放置在 z1/z2/z3，这样当任何一个数据中心发生故障时，TiDB 集群依然是可用的。

假如集群副本数设置为 5（max-replicas=5），因为总共只有 3 个 zone，在这一层级 PD 无法保证各个副本的隔离，此时 PD 调度器会退而求其次，保证在 host 这一层的隔离。也就是说，会出现一个 Region 的多个副本分布在同一个 zone 的情况，但是不会出现多个副本分布在同一台主机。

https://docs.pingcap.com/zh/tidb/v4.0/multi-data-centers-in-one-city-deployment

FQA2-TiKV 磁盘压满数据，导致 TiKV 宕机

https://asktug.com/t/topic/33962

问题描述：

如题，极限测试时候，将磁盘压满数据，导致tikv宕机，并且无法启动。

删除部分数据(手动在磁盘里删除数据)，tikv依旧无法启动。

重置清零所有数据后，tikv可以启动。

答：

1. 磁盘满了，tikv 启动收到影响是预期的。

4.0 版本 tikv 参数中多了一个 storage.reserver-space 参数，默认是 2G，作为预留空间，会在 {tikv_data} 目录下创建一个 space_placeholder_file 文件，用于提前占用空间，磁盘使用满的时候可以用于释放空间。

1. 手动删除 .sst 文件会破坏 tikv 的数据，不建议这样操作， 可以清理 tikv 中的 old LOG 日志来缓解空间和其他文件来缓解空间。

3 不建议直接删除 LOG 这个文件本身，因为是当前正在写的 file，由于文件句柄的持有，要等 log rotation

1. 删除日志是可以的。我现在明白在磁盘占用100%极端情况下的解决情况，一是删除 {deploy_dir}/log 目录下日志，如果依旧无法启动 再删除{deploy_dir}/data/ 下的log文件。启动后 ，选择性删除部分数据库数据，保证线上正常运行。此外就是扩大磁盘。

画外音：

reserve-space https://www.bookstack.cn/read/TiDB-4.0/tikv-configuration-file.md#3oay5s

TiKV 启动时预占额外空间的临时文件大小。临时文件名为 space_placeholder_file， 位于 storage.data-dir 目录下。

TiKV 磁盘空间耗尽无法正常启动需要紧急干预时，可以删除该文件，并且将 reserve-space 设置为 0MB。

默认值：2GB

单位: MB|GB

FQA3 - TiKV 磁盘 IO 和 压缩数据 问题

问题描述：

http://114.114.114.114:90//login?original_url=MTE0LjExNC4xMTQuMTE0Ojk

【TiDB 版本】：Tikv v3.0.5 【问题描述】：

1、 在测试 Tikv 的时候，和其他KV 类存储对比了下，发现 Tikv 在写入数据的时候， 磁盘 iops 明显高于其他 kv 存储。

所以好奇为什么会高这么多?如下图，第一个峰是 tikv， 第二个峰是小米的Pegasus 。

2、同样的数据，数据本身占用 7.4G，但是存储后，发现 Tikv 的部署目录大小为4.2G，小米的Pegasus 9.1G。想问下，除了 RocksDB 基本的 l4 压缩，Tikv 还额外做了什么，数据占用这么小

答：

1. 我做了一系列的对比实验，发现是 raft log 的问题。如果把 sync_log 改为 false，iops 下降到200。可以推测出来，我这个测试，raft log 的 io 占据了绝大多数。

https://docs.pingcap.com/zh/tidb/v4.0/tune-tikv-memory-performance [raftstore]

默认为 true，表示强制将数据刷到磁盘上。如果是非金融安全级别的业务场景，建议设置成 false，

以便获得更高的性能。

sync-log = true

# RocksDB 每一层数据的压缩方式，可选的值为：no,snappy,zlib,bzip2,lz4,lz4hc,zstd。
# no:no:lz4:lz4:lz4:zstd:zstd 表示 level0 和 level1 不压缩，level2 到 level4 采用 lz4 压缩算法,
# level5 和 level6 采用 zstd 压缩算法,。
# no 表示没有压缩，lz4 是速度和压缩比较为中庸的压缩算法，zlib 的压缩比很高，对存储空间比较友
# 好，但是压缩速度比较慢，压缩的时候需要占用较多的 CPU 资源。不同的机器需要根据 CPU 以及 I/O 资
# 源情况来配置怎样的压缩方式。例如：如果采用的压缩方式为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量
# 写入数据的情况下（导数据），发现系统的 I/O 压力很大（使用 iostat 发现 %util 持续 100% 或者使
# 用 top 命令发现 iowait 特别多），而 CPU 的资源还比较充裕，这个时候可以考虑将 level0 和
# level1 开启压缩，用 CPU 资源换取 I/O 资源。如果采用的压缩方式
# 为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量写入数据的情况下，发现系统的 I/O 压力不大，但是 CPU
# 资源已经吃光了，top -H 发现有大量的 bg 开头的线程（RocksDB 的 compaction 线程）在运行，这
# 个时候可以考虑用 I/O 资源换取 CPU 资源，将压缩方式改成"no:no:no:lz4:lz4:zstd:zstd"。总之，目
# 的是为了最大限度地利用系统的现有资源，使 TiKV 的性能在现有的资源情况下充分发挥。

FQA-3 海量数据无感知 扩容 TiKV 参数调整

【TiDB 最佳实践系列】PD 调度策略最佳实践 https://asktug.com/t/topic/1669

FQA-4 TiKV 内存占用异常

https://asktug.com/t/topic/63556/2

【问题描述】：TiKV 使用默认配置，理论上内存占用是 45% block-cache内存 + 2.5G write-buffer，

但在导数时经常达到80+%，是否有其他大的内存占用，和相关参数调整

答：

1. 使用top 显示是80%+，即64G占用了50多G；

top 中的 80% 是包含了操作系统本身的缓存，这个是正常情况，

如果想减少 loader 导数时的内存占用情况可以考虑降低导入时的线程数（由参数 pool-size 控制）。

1. TiKV 在处理大的查询的时候（例如 select * from ... ）会读取数据然后在内存中生成对应的数据结构返回给 TiDB，这个过程中 TiKV 会占用一部分内存

v5.0.1设置tikv参数raftstore.sync-log不生效了….

https://docs.pingcap.com/zh/tidb/stable/release-5.0.0

删除 raftstore.sync-log 配置项，默认会写入数据强制落盘， 之前显式关闭 raftstore.sync-log，成功升级 v5.0 版本后，会强制改为 true。

异步提交事务（Async Commit)

用户文档，#8316

• 数据库的客户端会同步等待数据库系统通过两阶段 (2PC) 完成事务的提交，事务在第一阶段提交成功后就会返回结果给客户端，系统会在后台异步执行第二阶段提交操作，降低事务提交的延迟。如果事务的写入只涉及一个 Region，则第二阶段可以直接被省略，变成一阶段提交。
• 开启异步提交事务特性后，在硬件、配置完全相同的情况下，Sysbench 设置 64 线程测试 Update index 时, 平均延迟由 12.04 ms 降低到 7.01ms ，降低了 41.7%。
• 开启异步提交事务特性时，数据库应用开发人员可以考虑将事务的一致性从线性一致性降低到 因果一致性，减少 1 次网络交互降低延迟，提升数据写入的性能。开启因果一致性的 SQL 语句为 START TRANSACTION WITH CAUSAL CONSISTENCY。
• 开启因果一致性后，在硬件和配置完全相同的情况下，Sysbench 设置 64 线程测试 oltp_write_only 时，平均延迟由 11.86ms 降低到 11.19ms，降低了 5.6%。
• 事务的一致性从线性一致性降低到因果一致性后，如果应用程序中多个事务之间没有相互依赖关系时，事务没有全局一致的顺序。

新创建的 5.0 集群默认开启异步提交事务功能。

从旧版本升级到 5.0 的集群，默认不开启该功能，你可以执行 set global tidb_enable_async_commit = ON; 和 set global tidb_enable_1pc = ON; 语句开启该功能。

一致性模型笔记

线性一致性 （Linearizability：Strong consistency or Atomic consistency) 顺序一致性（Sequential consistency） 因果一致性（Causal consistency） 最终一致性（Eventual consistency）

• Linearizability 的基本想法是让一个系统看起好像只有一个数据副本，且所有的操作都是原子的。在一个可线性化的系统中，一旦某个客户端成功提交写请求，所有客户端的读请求一定能够看到最近写入的值

Linearizability：可线性化是读写寄存器（单个对象）的最新值的保证。它并不要去做作组合到事务中，因此无比避免写倾斜等问题。

Serializability: 可串行化是事务的隔离属性，其中每隔事务可以读写多个对象（行，文档，记录等）。它用来确保事务的执行结果和串行执行（每次执行一个事务）的结果完全相同，即使串行执行的顺序可能和事务的实际执行顺序不同。

https://int64.me/2020/%E4%B8%80%E8%87%B4%E6%80%A7%E6%A8%A1%E5%9E%8B%E7%AC%94%E8%AE%B0.html

参考

一致性模型

分布式系统一致性

线性一致性理论

当数据库遇到分布式

如何验证线性一致性

线性一致性和 Raft

Consistency Models

Linearizability versus Serializability

Sequential Consistency versus Linearizability

Linearizability: A Correctness Condition for Concurrent Objects A Critique of ANSI SQL Isolation Levels