从 TiDB 搭建到监控闭环
作者: xie123 原文来源:https://tidb.net/blog/341d7ea4
背景
使用TiDB
已经有一段时间了,也陆陆续续遇到了一些问题。有些小问题用着用着才发现,部分需要集群维护重启才能修改,部分只能拓扑文件安装时修改,当然也可以临时修改,不过重启失效,容易遗忘反复出现比较麻烦。计划从头梳理一下,希望对自己和大家从安装配置、使用、后期监控维护有一定帮助
安装
1、版本选择
我们集群目前安装的版本为 TiDB
v5.4.0 和 v5.4.1,操作系统为debian10
和Ubuntu 18.04.6 LTS
。可以先根据 TiDB 数据库快速上手指南 选择对应版本单机部署体验一下,在满足功能的基础上对比操作系统要求 TiDB 软件和硬件环境建议配置
2、集群拓扑规划
必备组件:PD
、TiDB
、TiKV
可选组件:TiFlash
、TiCDC
、TiSpark
、Monitoring & Grafana
、TiDB Binlog
相关组件功能就不介绍了,具体可以看官网,根据功能规划拓扑。我们线上集群架构如下,三台物理服务器,所有实例部署目录/home/tidb/tidb-deploy
,数据存储单独挂SSD
盘。
| 实例 | 个数 | IP | 数据存储目录 | 配置 || ———————- | – | ————————– | —————- | ———– || TiDB
| 3 | 10.0.1.1 10.0.1.2 10.0.1.3 | 无 | 默认端口 全局目录配置 || PD
| 3 | 10.0.1.1 10.0.1.2 10.0.1.3 | 1 块 1.8T SSD
| 默认端口 全局目录配置 || TiKV
| 3 | 10.0.1.1 10.0.1.2 10.0.1.3 | 1 块 1.8T SSD
| 默认端口 全局目录配置 || TiFlash
| 1 | 10.0.1.4 | 1 块 1.8T SSD
| 默认端口 全局目录配置 || Monitoring & Grafana
| 1 | 10.0.1.4 | TiFlash
共用SSD
| 默认端口 全局目录配置 |
3、配置安装
安装其实挺简单的,几条命令执行就能安装成功,主要是相关环境检查和配置文件配置规划,v6.1 版本还有 TiUniManager 界面一键安装管理,目前还未测试过,这个后续也会调研使用下
1)软件环境检查
2)安装TiUP
,生成拓扑文件
3)修改拓扑配置topology.yaml
并使用TiUP
一键检查配置安装
该部分比较重要,刚开始我们基本都是按照默认的,只填了对应ip
、data dir
、deploy dir
,现在根据维护过程中发现的一些小问题,进行添加修改。更多配置可参考 通过 TiUP 部署 TiDB 集群的拓扑文件配置
ps:topology.yaml
所有需要填的 host
尽量都填内网ip
PD
监听端口在有内外网的情况下,如果
host
填对应主机名,默认组件会监听 0.0.0.0,内外网都可访问,但是etcd
有安全漏洞,若不对外网暴露,需要在配置PD
部分加listen_host
为内网ip
,或者host
填内网ip
单条
sql
查询内存限制单条
sql
语句可以占用的最大内存阈值,单位为字节。默认 1G,我们业务压测时有部分sql
会超出内存限制,跑不出结果,mem-quota-query
设置为 10GTiDB
日志保留周期TiDB
、TiKV
、PD
,均有如下日志保留周期设置,可根据需要添加
混合部署(可选)
下面配置适合混合部署,机器资源不够时给予各个实例 CPU、内存等方面限制。目前我们机器资源还有剩余,后续也会考虑扩容复用,所以也提前配置了部分。
label
调度对于单机部署多实例
TiKV
,避免物理机宕机导致 3 副本中 2 副本丢失,导致集群不可用问题,以通过label
来实现PD
智能调度,保证同台机器的多TiKV
实例不会出现Region Group
只有 2 副本的情况。
TiKV
配置相同物理机配置相同的 host
级别 labe
l 信息:
PD
需要配置 labels
类型来识别并调度 Region
:
TiKV 内存
读缓存大小storage CF
(all RocksDB column families
) 内存,默认storage.block-cache.shared: true
,block-cache
设置为机器总内存的 45%,多个TiKV
实例会造成机器内存不足,可设置单个实例读缓存大小,我们是设置 30G,具体根据实际修改TiKV CPU
大小
TiKV
的读取请求分为两类:
1)一类是指定查询某一行或者某几行的简单查询,这类查询会运行在 Storage Read Pool 中
2)另一类是复杂的聚合计算、范围查询,这类请求会运行在 Coprocessor Read Pool 中
从 TiKV
5.0 版本起,默认所有的读取请求都通过统一的线程池进行查询
混合部署时,该值最好通过绑核分离,再加上此处限制
numa_node
绑核numa
绑核使用前,确认已经安装numactl
工具,以及物理机对应的物理机cpu
的信息后,再进行参数配置;PD
、TiDB
、TiKV
可以运用绑核,根据实际情况绑定cpu
,我们机器只有两个cpu
(0、1)
其他限制(仅了解,尽量不设置)
目前资源方面,我们只对TiKV
读缓存使用内存大小以及readpool cpu
有所限制,其他像TiDB
这些组件实例也有相关资源限制,达到限制会导致正在执行的sql
语句强制终止,影响使用,所以并未应用生产
TiDB
内存限制当
tidb-server
实例内存使用到达 32 GB 时,正在执行的SQL
语句会被随机强制终止,直至tidb-server
实例内存使用下降到 32 GB 以下。被强制终止的SQL
操作会向客户端返回Out Of Global Memory Limit!
错误信息。resource_control
:运行时资源控制,该字段下所有配置都将写入systemd
的service
文件中,默认无限制。支持控制的资源如下:memory_limit
: 限制运行时最大内存,例如"2G"
表示最多使用 2GB 内存cpu_quota
:限制运行时最大 CPU 占用率,例如"200%"
io_read_bandwidth_max
:读磁盘 I/O 的最大带宽,例如:"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M"
io_write_bandwidth_max
:写磁盘 I/O 的最大带宽,例如:"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M"
limit_core
:控制core dump
的大小
监控告警(可选)
监控方面,默认是采用Prometheus
、Grafana
、Alertmanager
这一套,架构图如下。通过TiUP
部署,会自动部署监控报警系统,当然也可以手动部署,不过默认部署的监控会有对应组件机器的告警规则,dashboard 等,很方便且能快速使用,但是也有限制,对部分告警规则自定义,需另外配置,否则重启会覆盖修改的配置。
只需要填Prometheus
、Grafana
、Alertmanager
地址就行,但是如果需要实现告警邮件发送到对应邮箱还需要进行单独配置
alertmanager.yml
4、功能验证
拓展
1、HAproxy
实践
通过上述配置安装后,一个已经可以用的TiDB
集群已经可以使用了
但是我们有 3 个TiDB Server
,可通过HAproxy
实现 TiDB Server
层的负载均衡
HAproxy
以及keepalived
高可用等安装配置步骤可以自行配置,如下为官网提供配置
空闲超时
默认官方空闲超时设置非交互式连接无限制,交互式连接超时 8 小时,在官方提供这个HAproxy
配置超时 30000s >8h
在实际生产环境中,空闲连接和一直无限执行的 SQL 对数据库和应用都有不好的影响。空闲连接超时我们通过统一入口HAproxy
配置为半小时,当然也可根据系统参数修改TiDB
层的超时
交互式连接的wait_timeout
继承于global
的interactive_timeout
(默认 8 小时)
非交互式连接的wait_timeout
继承于global
的wait_timeout
(默认 0,无限制)
SQL 执行超时
TiDB
提供 max_execution_time
控制与 Java 应用连接中 SQL 执行的超时时间,即控制 TiDB 与 Java 应用的连接最长忙多久。默认值是 0
,即默认无限忙碌(一个 SQL 语句执行无限的长的时间),可根据实际情况设置
2、监控排查 && 整合
1.Grafana
图表 && 告警规则
Grafana
通过配置方式,在部署目录provisioning
分别定义了固定的dashboards
和datasources
,我们可以不配置任何东西就有对应集群图表展示。在界面可以根据文件夹名区分不同分组的图表归属,排查对应组件问题。
说实话TiDB
监控告警规则和告警已经很完善了,对应告警规则也有排查方法,已经满足使用。在Grafana Alerting
界面也可看到已经定义的告警规则及告警状态。当我们收到对应邮件告警可根据 TiDB 集群报警规则 确定告警级别、告警详情以及处理方法。随着遇到的一些问题,也可以修改一些监控图表和告警指标,单独展示一些重点指标。
2. 日志告警
之前有遇到一个问题,默认告警策略并未有异常,后续通过TiDB
日志发现大量警告和错误,正好我们有一套日志告警监控,于是把TiDB
日志也接入了告警,并根据出现的警告和错误,一一排查,屏蔽可忽略告警,以下列了一些常见告警或警告。
忽略不支持的事务隔离级别告警
修改
tidb_analyze_version
版本,解决内存不断上涨的问题get timestamp too slow
取时间戳是从 TiDB Server
向 PD Server
批量获取 TSO
时间戳,实际消耗主要是在网络层,网络的延迟导致这个操作慢的情况。另外 PD Server
系统负载高,PD
的 Goroutin
调度过程中会有瓶颈。其次就是TiDB Server
在进行 SQL Parse
或者 build SQL Plan
时间较长,会导致获取的时间戳不使用的情况。取ts
和 QL Parse
和 Build Plan
是并行的,总时间会取决于慢的那一个,一般情况是因为获取时间戳慢,也有上述情况导致的慢,在监控中变现就是 “Get Timestamp too slow”
。如果在运维过程中发现 TiDB
日志中出现大量“Get Timestamp too slow”
的报错,需要关注以下监控:
expensive query
TiDB
在执行 SQL
时,预估出来每个 operator
处理了超过 10000
条数据就认为这条 query
是 expensive query
。可以通过修改 tidb-server
配置参数来对这个门限值进行调整,调整后需要重新启动 tidb-server
。如果创建用户、授权ddl
是expensive_query
那么集群有问题了,可以监控设置expensive
查询有多少就报错
Client without Auth Plugin support; Please upgrade client
客户端的问题:https://github.com/pingcap/tidb/issues/29725
Specified key was too long; max key length is 3072 bytes
function READ ONLY has only noop implementation in tidb now, use tidb_enable_noop_functions to enable these functions
tidb_enable_noop_functions
从 v4.0 版本开始引入,参数不改,观察日志告警反馈业务方
3. 整合统一
目前我们有 3 个TiDB
集群,根据官方默认安装监控,一共有 3 套Grafana
、Prometheus
、Alertmanager
,一方面是资源浪费,而且自带的告警规则修改还需另外配置,不然reload
会被覆盖,还需要修改几个集群。另一方面是维护多个界面后台服务很繁琐,于是想统一一个Grafana
展示监控图表、统一查询入口,一个Prometheus
维护监控指标 ,一个Alertmanager
提供邮件告警。具体方案也在社区和网络上找了很多,网上方案 使用 Prometheus + Grafana 打造 TiDB 监控整合方案 和我们需求基本满足。
为了改动较小,且新增集群也可快速适配,我们选择这套监控搭建在容器上,保留TiDB
自动部署监控的exportor
的数据采集接口,对原有的Prometheus
数据拉取任务、告警配置修改。新增集群只需要默认安装Prothemes
,再配置拉取任务就可实现监控告警,并且对告警添加解决方案链接,可以实现快速定位。
Prometheus
数据 pull 适配
拷贝任一集群原有prometheus conf
配置目录,修改prometheus.yml
,修改部分注释已标注
Prometheus
告警规则适配
对上述提供的rule_files
告警规则文件,批量修改,以如下一个告警规则为例
Grafana
展示适配
拷贝原有集群 provisioning/dashboards
目录内容,批量修改json
文件datasource
、集群区分变量、uid
目录结构如下
datasource
配置,统一为一个
Alertmanager
配置
延续原有配置,为减少报警,修改分组和告警频率
自定义
dashboard
和告警
对于一些重点关注图表和告警规则,可通过Grafana
单独配置告,单独告警走Grafana
邮件
3、配置修改方式
目前的状态也是在问题中不断完善使用方式,优化配置,因此也整理了TiDB
配置参数的几种修改方式,以及对应参数查找未知,记录一些临时修改的参数
1. 配置文件修改(永久)
这部分修改肯定是永久保留的,但是需要重启服务更新维护,在业务运行时需要评估影响,且有部分是只能安装是指定,指定后就不能修改了,最好安装时就配置,具体可见上述安装拓扑配置修改
只能拓扑安装时修改
部分字段部署完成之后不能再修改。如下所示:
可以 edit-config 修改
在部署集群之后,如果需要再调整集群服务的配置,则可以使用命令 tiup cluster edit-config
,它会启动一个编辑器(默认为 $EDITOR 环境变量指定的值,当 EDITOR 环境变量不存在时,使用 vi 打开)允许用户修改指定集群的拓扑文件 以及配置文件参数
2. 在线动态修改(临时)
在线配置变更主要是通过利用 SQL 对包括 TiDB、TiKV 以及 PD 在内的各组件的配置进行在线更新。用户可以通过在线配置变更对各组件进行性能调优而无需重启集群组件。该部分修改值,大部分为临时修改,重启或reload
后会失效,记得保留临时修改配置
在线修改配置
可以查看在线修改配置 查找可在线修改的参数,以及配置值
系统提供的变量
TiDB
系统变量的行为与 MySQL 相似但有一些不同,变量的作用范围可以是全局范围有效 (Global Scope)、实例级别有效 (Instance Scope) 或会话级别有效 (Session Scope),或组合了上述多个范围。其中:
1)对 GLOBAL
作用域变量的更改,设置后只对新 TiDB
连接会话生效,当前活动连接会话不受影响。更改会被持久化,重启后仍然生效。
2)对 INSTANCE
作用域变量的更改,设置后会立即对当前 TiDB
实例所有活动连接会话或新连接会话生效,其他 TiDB
实例不生效。更改不会被持久化,重启 TiDB
后会失效。
3)作用域为 NONE
的变量为只读变量,通常用于展示 TiDB
服务器启动后不会改变的静态信息。
使用set
语句可以设置变量的作用范围为全局级别、实例级别或会话级别。具体参数可查看所记录的系统变量
3. 已临时修改参数记录
记录了部分集群维护不便暂时未永久设置的参数
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/82ce7b853aa722355cd71c505】。文章转载请联系作者。
评论