TiDB 最佳实践之深度巡检指引
作者： Jellybean 原文来源：https://tidb.net/blog/1eeed4a6
背景说明
在日常使用和管理 TiDB 集群的时候，通常是业务出现了访问性能、延迟出现抖动或者其他故障问题时，我们才会去针对性解决对应的问题。数据库的安全稳定运行，正如一个人身体健康，天天吃好睡好一样，二者是有相通之处的。数据库的管理员，包括但不限于 DBA，就是数据库的专属医生，排查和分析数据库的问题与医生需要对病人望闻问切一样异曲同工。经验丰富的资深 DBA，就是数据库的专家级医生，当数据库生病时（遇到问题、故障），由于管理员的能力水平差异，治好的时间和效果也会不同，最终导致不一样的业务损失。我们当前尽量避免这种情况的出现，宁愿事发前花数倍的时间精力去琢磨如何避免，也不愿意半夜处理过多的意外性问题。所以，需要提前规避突发性、临时性的、危急性的情况发生，尽量做到一切尽在掌控中。
我们会定期去做体检以检查有无健康问题，对于数据库，同样期望对它去做定期的“体检”，这样就可以提前发现潜在的风险和隐患，避免病状来临时情况危急，可以提前解决隐患问题，保证数据库健康、安全稳定运行。
通常我们可以借助工具可以实现 TiDB 数据库的诊断，比如官方推荐的 PingCAP Clinic 诊断服务与 Clinic Server 云诊断平台，它们实现远程定位集群问题和本地快速检查集群状态。第三方工具，如 DBdoctor 等，也是一个考虑的选项。
本文更多地从朴素的思考维度结合常用的命令分享日常的运维管理经验，让大家能在无法使用工具的场景，如离线环境、对安全有苛刻要求的私有云场景、部分模块的深度检查等方面，有所参考借鉴。
核心要点
【基础】集群健康状态检查
【基础】集群组件参数配置检查
【基础】硬件资源和配置检查
【高级】网络及操作系统内核配置检查
【高级】数据库性能检查
【高级】灾备及高可用
深度检查介绍
方法概要
本次巡检主要包括数据库
服务器操作系统配置
数据库配置
网络配置
磁盘配置
数据库性能分析
备份、高可用等。
根据所收集时间点的相关数据来评估主要的配置情况，提供建议使性能加以优化。
注意说明，在执行深度的业务巡检时由于营运系统是一个复杂的系统工程，牵涉到主机，操作系统，网络，数据库，中间件等，还有系统的核心内容，即业务应用。任何方面导致的故障问题、调整都可能造成系统的变化。
本次巡检主要针对系统前一段时间和目前的一些运行情况进行检查，会根据收集的信息进行分析并指出系统的运行情况及存在隐患，同时给出适当的建议。
从预防的角度看，着重于避免已知故障的重演，同时对保持系统良好运行提出建议。大家平时常见的数据库 bug，也是在特定情况、特定场合触发的故障问题，它事先不是一定有症兆的，所以有时我们做健康检查也无法百分百能提前发现所有的问题。
使用工具
本次数据库性能检查的工具说明：
TiDB Dashboard、Prometheus、Grafana 进行系统信息收集
操作系统工具和命令检查操作系统
SQL 命令检查数据库配置
TiDB Dashboard、Prometheus、Grafana 进行数据库性能资料的收集
系统配置深度巡检[标准项]
数据库系统拓扑概况
1）登陆集群中控机，执行命令：
tiup-cluster 支持使用同一个中控机部署多套集群，而命令 tiup cluster list 可以查看当前登录的用户使用该中控机部署了哪些集群。输出含有以下字段的表格：
● Name：集群名字
● User：部署用户
● Version：集群版本
● Path：集群部署数据在中控机上的路径
● PrivateKey：连接集群的私钥所在路径
2）查看集群概况，执行下面命令
初步从整体把控集群的概括、节点总数和部署拓扑等内容。
操作系统最佳实践配置检查
登录 TiDB 集群中控机，执行官方推荐的验命令一键检查：
结果会输出 selinux 、swap 、network 、THP 、CPU 使用模式等诸多内容检查项，常规的检查通过此方法已经可以满足。如果机器环境都符合要求，则不会存在 fail 项内容（warn 项看情况可选修复）。如果存在 fail 项内容，可以再参考下面官方推荐的命令进行自动修复：
tiup cluster check {cluster-name} --cluster --apply
如果上述自动修复执行仍存在 fail 项内容，请联系业务环境相关的负责人处理，直到无 fail 项检查内容。
如果遇到更加精细化的深度巡检，需要对每个内核系统项逐一检查，则可以参考下述内容。
操作系统版本
执行命令：
结果样例：
内核参数配置
登陆每一台机器，执行命令检查：
结果样例：
Ulimit 参数配置
检查 /etc/security/limits.conf 中各项 limit 值。执行命令：
检查 /etc/security/limits.conf 中各项 limit 值：
<deploy-user> soft nofile 1000000
<deploy-user> hard nofile 1000000
<deploy-user> soft stack 10240
其中 <deploy-user> 为部署、运行 TiDB 集群的用户，最后一列的数值为要求达到的最小值。
结果样例：
swap 分区状态
检查部署机是否启用 Swap 分区：建议禁用 Swap 分区。执行命令：
若文件内容为空或仅有标题行，则 Swap 未启用。
结果样例：
透明大页配置
检查部署机是否启用透明大页：建议禁用透明大页。
执行命令：
如果结果不是 never，参考使用 grubby –update-kernel=ALL –args=“transparent_hugepage=never” 修改。
结果样例：
NTP 服务状态
检查部署机是否配置了时间同步服务：即 ntpd 是否在运行
执行命令：
如果输出 running 表示 NTP 服务正在运行。若返回报错信息 Unit ntpd.service could not be found.，请尝试执行以下命令，以查看与 NTP 进行时钟同步所使用的系统配置是 chronyd 还是 ntpd。
若发现系统既没有配置 chronyd 也没有配置 ntpd，则表示系统尚未安装任一服务。此时，应先安装其中一个服务，并保证它可以自动启动。
1）如果安装的是 NTP，则执行 ntpstat 命令检测是否与 NTP 服务器同步
如果输出 synchronised to NTP server，表示正在与 NTP 服务器正常同步，如果输出 unsynchronised 表示 NTP 服务未正常同步，输出 Unable to talk to NTP daemon. Is it running? 表示 NTP 服务未正常运行。
2）如果安装的是 Chrony 服务，则执行 chronyc tracking 命令查看 Chrony 服务是否与 NTP 服务器同步。
如果该命令返回结果为 Leap status : Normal，则代表同步过程正常。如果返回 Not synchronised 表示同步过程出错。如果返回 506 Cannot talk to daemon 则表示 Chrony 服务未正常运行。
结果样例：
磁盘挂载参数
检查 ext4 分区的挂载参数：确保挂载参数包含 nodelalloc,noatime 选项。
执行命令：
确认数据盘包含 nodelalloc,noatime 选项。
结果样例：
防火墙运行状态
执行命令：
检查 FirewallD 服务是否启用：建议用户禁用 FirewallD 或为集群各服务地址和端口添加允许规则。
结果样例：
3.2.9 SELinux
SELinux 必须关闭或设置为 permissive 模式。
执行命令：
在输出中查找 SELinux 如果是 disabled 或 permissive，则满足要求。如果 SELinux 未关闭，请打开 /etc/selinux/config 文件，找到以 SELINUX= 开头的行，并将其修改为 SELINUX=disabled。修改完成后，需要重启系统，因为从 enforcing 或 permissive 切换到 disabled 模式只有在重启后才会生效。
结果样例：
irqbalance
检查 irqbalance 服务是否启用：建议用户启用 irqbalance 服务。
执行命令：
若显示 Active: active (running)，表示服务已启用。若显示 Active: inactive (dead)，表示服务未运行。
结果样例：
CPU 运行模式
执行命令：
在输出中查找 current policy 或 current governor 字段，若显示 performance，则表示 CPU 处于高性能模式。
结果样例：
3.2.12 系统时间
检查部署机系统时间是否同步：将部署机系统时间与中控机对比，偏差超出某一阈值（500ms）后报错。
执行命令：
在输出时间与中控机时间对比，计算出时间差。
结果样例：
系统时区
检查部署机系统时区是否同步：将部署机系统的时区配置进行对比，如果时区不一致则报错。
执行命令：
在输出时区与中控机对比，确认是否一致。
结果样例：
网络配置
执行命令：
查看网卡支持的最大速度、当前协商速率及双工模式。建议是万兆网卡。
结果样例：
服务器配置
内存大小
检查部署机的内存大小：建议生产集群总内存容量 >= 32Gb。
执行命令：
结果样例：
CPU 核心数
检查部署机 CPU 信息：建议生产集群 CPU 逻辑核心数 >= 16
执行命令：
结果样例：
CPU 是否开启超线程
● Thread(s) per core：
○ 若为 1，表示超线程未开启。
○ 若为 2，表示超线程已启用。
执行命令：
结果样例：
磁盘使用量
执行命令
结果样例：
也可以登陆 TiDB Dashboard，查看集群信息，可以确认：
● CPU 架构、CPU 配置
● 物理内存
● 磁盘文件系统、磁盘容量
数据库集群[标准项]
系统 service 清单
登录 Grafana 查看 Overview 面板，Services Port Status，确认各个节点服务是否正常。
以上面板展示常见的负载、内存、网络、IO 监控。发现有瓶颈时，推荐扩容或者优化集群拓扑，优化 SQL、集群参数等。
集群组件清单
TiDB : 与应用进行交互负责 SQL 逻辑，通过 PD 寻址到实际数据的 TiKV 位置，进行 SQL 操作。
TiKV : 负责数据存储，是一个提供完整 ACID 事务的分布式 Key-Value 存储引擎；
PD : 负责管理调度，如数据和 TiKV 位置的路由信息维护、TiKV 数据均衡，TiDB 通过 pd 获取 tso
数据库检查
软件组件版本
登陆 TiDB Dashboard，查看集群信息，选择实例，可以确认组件版本情况。
集群检查 [高级]
集群存储拓扑
集群拓扑 lable
replication.location-labels:
- region
- zone
- rack
- host
- node
集群拓扑 level：isolation-level：[]
集群副本 replicas：max-replicas=3
结论：当前集群 isolation-level 为空，且副本数为 3，副本保障级别是 host，满足 3 副本高可用要求。
集群参数
tiup edit-config 查看集群的配置内容，输出和判断结果样例：
PD 概览
原则上来说，该监控面板偶尔有数据是符合预期的。但长期有数据，需要排查是否存在问题。
查看 Grafana TiDB 监控面板概览
结果样例：Storage capacity ： 300TB
Current storage size : 合理范围
Region Health ： empty-region count 50k
结论：判断集群容量充足，空 region 较多。
查看 Grafana PD 健康面板，获取 TiKV 的打分信息
结果：Store capacity : 各区域内 Store 容量基本一致
Store available: 各区域内 Store 容量基本一致
Store Region score ： 各区域内 Store 打分基本一致
Store leader score ： 各区域内 Store 打分基本一致
结论：各区域内 Store 打分基本一致，不同区域因配置原因差异较大。
TiDB 概览
查看 Grafana TiDB 监控面板概览
TiKV 当前 .99（百分位）的响应时间。如果发现有明显高的节点，可以排查是否有热点，或者相关节点性能较差。
结果：Statement OPS ： 单类 SQL 操作次数合理
Duration ：99% 的 SQL 延时较高
CPU ：各节点 CPU 使用率较低
Memory ：各节点内存使用率较低
结论：判断是否 Duration 较高，如果较高则建议结合业务情况分析慢 SQL
TiKV 概览
查看 Grafana TiKV Details 监控 CLuster 面板概览
结果样例：
leader ： 各节点 Region Leader 分布差异较大
region ： 各节点 Region 分布不均
结论样例：leader 分布不均匀，Region 分布不均匀，主要为空 region 较多、各区域配置不同、数据导数等原因导致，以各区域 region score 为主。
系统信息概览
查看 Dashboard 里主机监控信息面板概览
结果样例：CPU Usage ： TiDB、TiKV、PD 各节点占用 CPU 在 较低
Memory Available ： TiDB 节点、TiKV 节点可用内存充足
Network Traffic ： 网络流量未达到瓶颈
IO Util ： 各磁盘平均使用率基本都在 40% 以下
结论： 操作系统侧资源负载居于正常水平
数据库性能[高级]
GC 状态
通过查看系统表 mysql.tidb 可以检查到最后 GC（垃圾清理）的时间，观察 GC 是否正常。
如果 GC 发生异常，可能会造成历史数据存留过多，进而可能影响访问效率。
SQL 性能概况
查看 TiDB Dashboard 查看 TOP SQL。
结论样例：当前集群主要负载为压测 SQL，分别为全表扫描以及 update 更新同一条数据导致锁冲突，可以尝试优化压测逻辑，建立合适索引。
慢查询分析
查看 TiDB Dashboard 查看慢查询界面，分析慢日志，分析执行计划。
结论样例：统计信息过期，需要进行更新统计信息。
灾备及高可用[高级]
全量备份
全量备份的方法使用官方推荐的 BR 工具实现，通常是快照备份。可以通过查看 BR 的备份日志 backup.log 日志或者查看 S3 上的数据情况，确认备份成功情况。
结果样例：备份成功。
增量备份
在 v6.5 之前的增量备份可以是 TICDC 备份到 S3，在 v6.5 之后的版本是通过 PITR 功能实现备份。
结果样例：
如果是 TICDC，可以通过 Grafana 查看 TICDC-Overview 项中的 dataflow 面板，查看 changefeed 的延迟情况。
如果是 PITR 增量备份，可以通过查看 PD 持久化日志备份任务状态确认，可以通过
br log status查询。
TiCDC 同步状态
如果有搭建异地灾备集群，即主从集群，可以通过确认 TICDC 的实时同步延迟情况，确认 TICDC 是否正常。也可以使用命令行查询 Changefeed 是否正常运行。使用
changefeed query命令可以查询特定同步任务（对应某个同步任务的信息和状态），指定--simple或-s参数会简化输出，提供基本的同步状态和 checkpoint 信息。不指定该参数会输出详细的任务配置、同步状态和同步表信息。结果样例：
如果是 TICDC，可以通过 Grafana 查看 TICDC-Overview 项中的 dataflow 面板，查看 changefeed 的延迟情况。
确认同步正常
深度巡检报告模板
本次对 xxx 系统生产数据库为 xxx 版本的 TiDB 数据库，本次深度检查发现了一些问题，具体描述和建议如下面的报告。
如上为检查的结果情况，如果在检查中发现 TiDB 运行状态的问题，对检查范围内的情况进行记录，给出整改的建议。
总结
本文通过从常用的命令和监控入手，分享日常的深度巡检指引，让大家能在无法使用其他工具的场景，如离线环境、对安全有苛刻要求的私有云场景、部分模块的深度检查等方面，也能够如期开展深度检查工作，哪怕只有一个点能起到帮助作用，也发挥出它的价值了。
望与君共勉！
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/b183fc40abf505f7d46f87a02】。文章转载请联系作者。
TiDB 社区官网:https://tidb.net/ 2021-12-15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论