👆 立即咨询 TiDB 企业版 👆
本文将深入解析 TiDB 在运维管理中的关键环节，包括慢查询的识别与优化、数据的备份与恢复机制，以及集群容量的计算。通过结合实际案例和详细的操作指南，帮助大家深入理解 TiDB 的内部工作机制，掌握高效的运维实战技巧，确保数据库服务的高性能和高可用性。
1
TiDB 慢查询日志分析
慢查询相关参数
● tidb_enable_slow_log：用于控制是否开启 slow log 功能
● tidb_slow_log_threshold ：设置慢日志的阈值，执行时间超过阈值的 SQL 语句将被记录到慢日志中。默认值是 300 ms
● tidb_query_log_max_len ：设置慢日志记录 SQL 语句的最大长度。默认值是 4096 byte
● tidb_redact_log ：设置慢日志记录 SQL 时是否将用户数据脱敏用 ? 代替。默认值是 0 ，即关闭该功能
● tidb_enable_collect_execution_info ：设置是否记录执行计划中各个算子的物理执行信息，默认值是 1
慢查询日志原理
TiDB 的慢查询日志原理与 MySQL 一致，在每条 SQL 执行结束时，并且执行时间超过慢日志阈值时，会把 SQL 执行相关信息记录到慢日志中，同样的 SQL 多次执行超过阈值都会记录。
分析慢查询日志
TiDB 是一个分布式数据库，具有存算分离架构，每个节点都会生成慢查询日志。为了方便分析，TiDB 提供了 INFORMATION_SCHEMA.SLOW_QUERY 表和 TiDB Dashboard 的慢查询日志界面。
尽管官方文档提供了查询示例，但在高负载或异常情况下，分析慢查询日志可能变得复杂。因此，借鉴 MySQL 的慢日志分析工具如 mysqldumpslow 和 pt-query-digest，可以开发聚合分析 SQL，简化慢查询日志的处理。
● 慢日志聚合查询 SQL
● 单条 SQL 执行历史
收集慢查询日志脚本
此脚本用于生成 HTML 格式的慢日志分析结果，结合定时任务和 Nginx 的自动索引功能，可以轻松地收集和查看各个 TiDB 集群的慢日志。
脚本请在这个链接取：https://asktug.com/t/topic/1022684
效果展示：
点击此处丨查看原文
2
一文读懂 TiDB 的备份与恢复技术
TiDB 备份能力概述
TiDB 支持物理备份和逻辑备份两种方式。物理备份包括全量和增量备份，适用于大规模数据，确保一致性。逻辑备份适用于小规模数据，不保证业务运行时的一致性。
1.1 物理备份
物理备份分为全量备份和增量备份。全量备份又称为“快照备份”，即通过快照保证备份出的数据一致；增量备份在当前的 TiDB 版本中又称为“日志备份”，即每次备份最近一个时间范围的 kv 变更日志。
快照备份
快照备份的机制原理
日志备份
日志备份的机制原理
1.2 逻辑备份
逻辑备份简单理解就是使用 TiDB 的 SQL 语句或导出工具将数据导出来。除了常用的导出语句，TiDB 提供一款叫 Dumpling 的工具，可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式。
TiDB 恢复能力概述
TiDB 恢复分为物理和逻辑备份恢复。物理恢复用 br restore 命令，适用于大规模数据全量还原；逻辑恢复通过数据导入，如使用 Dumpling 导入，适合小规模或少量表的数据。
2.1 物理恢复
物理恢复有两种方式：一种是直接快照恢复，只需指定备份路径，另一种是 PITR (Point-in-time Recovery)时间点恢复，需指定备份路径和恢复时间。
2.2 逻辑恢复
逻辑恢复即数据导入，TiDB 提供 Lightning 工具，用于从静态文件快速导入数据至集群，适合初始化数据导入。具体可参考官网 TiDB Lightning 简介或 PingCAP 文档中心 (https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview )。
点击此处丨查看原文
3
一篇文章彻底搞懂
TiDB 集群各种容量计算方式
背景
TiDB 监控面板包含两个关键且常用的指标。
○ Storage capacity：集群的总容量
○ Current storage size：集群当前已经使用的空间大小
在部署 TiDB 集群后，客户常问服务器磁盘与 TiKV 实例的已用和可用空间之和不等于总容量的问题。深入源码分析后发现，监控显示的 TiKV 实例容量与磁盘实际大小不符，尤其在大容量磁盘上更为明显。
结论先行
● PD 监控下的 Storage capacity 和 Current storage size 来自各个 store 的累加，这里 store 包含了 TiKV 和 TiFlash
● Current storage size 包含了多个数据副本（TiKV 和 TiFlash 的所有副本数），非真实数据大小
● TiKV 实例容量统计的是 TiKV 所在磁盘的整体大小与 raftstore.capacity 参数较小的值，同时监控用的 bytes(SI) 标准显示，就是说不是用 1024 做的转换而是 1000，所以和 df -h 输出的盘大小有差距
● TiKV 实例的已用空间只统计了 data-dir 下的部分目录，非整个 data-dir 或整块盘
● 基于前两条，可用空间就不等于总空间减去已用空间了
看到的现象
● Dashboard 上显示的 TiKV 盘大小（GiB）是实际部署盘的总大小，Grafana 也是部署盘的总大小但单位是 GB
● Grafana 集群总容量是所有存储节点部署盘的累计大小
● TiKV 实例已用空间大小计算方式未知
不同进制转换带来的影响
GB和GiB的区别在于进制转换：
● GB 基于 10 进制（1GB=1000MB），是商业标准
● GiB 基于 2 进制（1GiB=1024MiB），是计算机标准
假设你买了一台 128G 存储的手机，实际使用中会发现空间“缩水”了，U 盘、硬盘等也类似。与这两个进制差异有关的还有两个行业标准，即 byte(SI) 和 byte(IEC) ，感兴趣的可以去查一下历史，这里只需要知道：
● byte(SI) 对应十进制
● byte(IEC) 对应二进制
Grafana 里面可以使用编辑监控面板调整显示单位，例如：
如果把单位统一的话，前 2 个现象就很好解释了。
但 Grafana 中不同面板对 byte(SI) 和 byte(IEC) 的使用不一，如 TiDB 内存面板用十进制，System Info 用二进制，使用时应留意单位差异。
TiKV 的数据文件
要理解 TiKV 的已用空间计算，需先了解其数据文件。TiKV 使用 RocksDB 作为存储层，其中 raft 日志和实际数据各对应一个 RocksDB 实例。需查看 TiKV 数据目录的内容。以前面的集群为例：
几类文件解读一下：
● db 目录：存储最终数据，位置固定不可变。
● rocksdb[-xxx-xxx].info 文件：RocksDB 日志文件，可归档删除
● raft-engine 目录：存放 raft 日志，由相关参数控制。
● rocksdb[-xxx-xxx].info 文件：raft 日志 RocksDB 实例日志，可归档删除。
● snap 目录：存储快照数据。
● import 目录：与数据导入相关，具体用途不明。
● space_placeholder_file 文件：预留空间的临时文件，用于磁盘告警。
● last_tikv.toml 和 LOCK 文件：配置和锁定文件。
从前面的观察来看，被监控统计到的 TiKV 已用空间比整个数据目录要小，那么可以推测出只统计了数据目录下的部分文件或目录，具体是哪些就要从源码里寻找答案了。
点击此处 | 查看原文
👇 立即咨询 TiDB 企业版 👇
