背景

使用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 ，数据存储单独挂***盘。

实例个数IP数据存储目录配置TiDB310.0.1.1 10.0.1.2 10.0.1.3无默认端口 全局目录配置PD310.0.1.1 10.0.1.2 10.0.1.31块 1.8T ***默认端口 全局目录配置TiKV310.0.1.1 10.0.1.2 10.0.1.31块 1.8T ***默认端口 全局目录配置TiFlash110.0.1.41块 1.8T ***默认端口 全局目录配置Monitoring & Grafana110.0.1.4TiFlash共用***默认端口 全局目录配置

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

pd_servers:  # # The ip address of the PD Server. - host: xx.xx.xx.xx   listen_host: xx.xx.xx.xx

单条sql查询内存限制

单条 sql 语句可以占用的最大内存阈值，单位为字节。默认1G，我们业务压测时有部分sql会超出内存限制，跑不出结果，mem-quota-query设置为10G

server_configs: tidb:   mem-quota-query: 10737418240

TiDB 日志保留周期

TiDB 、TiKV 、PD，均有如下日志保留周期设置，可根据需要添加

# log.file.xx # max-days # 日志最大保留的天数。 # 默认值：0 # 默认不清理；如果设置了参数值，在 max-days 之后 TiDB 会清理过期的日志文件。 # max-backups # 保留的日志的最大数量。 # 默认值：0 # 默认全部保存；如果设置为 7，会最多保留 7 个老的日志文件。 tidb_servers: - host: xx.xx.xx.xx   config:     log.file.max-days: 7     log.file.max-backups: 7

混合部署（可选）

下面配置适合混合部署，机器资源不够时给予各个实例CPU、内存等方面限制。目前我们机器资源还有剩余，后续也会考虑扩容复用，所以也提前配置了部分。

label调度

对于单机部署多实例TiKV ，避免物理机宕机导致3副本中2副本丢失，导致集群不可用问题，以通过 label 来实现 PD 智能调度，保证同台机器的多 TiKV 实例不会出现 Region Group 只有 2 副本的情况。

TiKV 配置相同物理机配置相同的 host 级别 label 信息：

tikv_servers: - host: xx.xx.xx.xx   config:     server.labels:       host: tikv3

PD 需要配置 labels 类型来识别并调度 Region :

server_configs: pd:   replication.location-labels: ["host"]

TiKV 内存 读缓存大小

storage CF (all RocksDB column families) 内存，默认storage.block-cache.shared: true，block-cache 设置为机器总内存的 45%，多个TiKV实例会造成机器内存不足，可设置单个实例读缓存大小，我们是设置30G，具体根据实际修改

# storage.block-cache.capacity = (MEM_TOTAL * 0.5 / TiKV 实例数量) server_configs: tikv:   storage.block-cache.capacity: 32212254720

TiKV CPU大小

TiKV 的读取请求分为两类：

1）一类是指定查询某一行或者某几行的简单查询，这类查询会运行在 Storage Read Pool 中

2）另一类是复杂的聚合计算、范围查询，这类请求会运行在 Coprocessor Read Pool 中

从 TiKV 5.0 版本起，默认所有的读取请求都通过统一的线程池进行查询

readpool.storage.use-unified-pool: true readpool.coprocessor.use-unified-pool: true

混合部署时，该值最好通过绑核分离，再加上此处限制

# readpool.unified.max-thread-count = cores * 0.8 / TiKV 数量 server_configs: tikv:   readpool.storage.use-unified-pool: true   readpool.coprocessor.use-unified-pool: true   readpool.unified.max-thread-count: 20

numa_node 绑核

numa 绑核使用前，确认已经安装 numactl 工具，以及物理机对应的物理机 cpu 的信息后，再进行参数配置；PD、TiDB、TiKV 可以运用绑核，根据实际情况绑定cpu，我们机器只有两个cpu（0、1）

pd_servers: - host: xx.xx.xx.xx numa_node: "0,1"

其他限制（仅了解，尽量不设置）

目前资源方面，我们只对TiKV 读缓存使用内存大小以及readpool cpu 有所限制，其他像TiDB这些组件实例也有相关资源限制，达到限制会导致正在执行的sql语句强制终止，影响使用，所以并未应用生产

TiDB内存限制

当 tidb-server 实例内存使用到达 32 GB 时，正在执行的 SQL 语句会被随机强制终止，直至 tidb-server 实例内存使用下降到 32 GB 以下。被强制终止的 SQL 操作会向客户端返回 Out Of Global Memory Limit! 错误信息。

# 默认值为 0，表示无内存限制。 # 目前为实验性特性，不建议在生产环境中使用 [performance] server-memory-quota = 34359738368

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地址就行，但是如果需要实现告警邮件发送到对应邮箱还需要进行单独配置

monitoring_servers: - host: xx.xx.xxx.xx grafana_servers: - host: xx.xx.xxx.xx alertmanager_servers: - host: xx.xx.xxx.xx # 字段指定一个本地文件，该文件会在集群配置初始化阶段被传输到目标机器上，作为 Alertmanager 的配置 config_file: /local/config/alertmanager.yml

alertmanager.yml

global: smtp_smarthost: "xxx:465" smtp_from: "xxx" smtp_auth_username: "xxx" smtp_auth_password: "xxx" smtp_require_tls: false route: receiver: "Ops" group_by: ["env", "job", "xx"] group_wait: 60s group_interval: 10m repeat_interval: 300m routes: receivers: - name: "Ops" email_configs: - send_resolved: true #是否通知警报被解决，即 Alert 消失也发邮件 to: xxx #收件人 headers: { Subject: " 【TiDB监控告警】 {{ .CommonLabels.alertname }} " }

4、功能验证

拓展

1、HAproxy 实践

通过上述配置安装后，一个已经可以用的TiDB 集群已经可以使用了

mysql -u root -h ${tidb_server_host_IP_address} -P 4000

但是我们有3个TiDB Server ，可通过HAproxy 实现 TiDB Server 层的负载均衡

HAproxy 以及keepalived高可用等安装配置步骤可以自行配置，如下为官网提供配置

global # 全局配置。 log 127.0.0.1 local2 # 定义全局的 syslog 服务器，最多可以定义两个。 chroot /var/lib/haproxy # 更改当前目录并为启动进程设置超级用户权限，从而提高安全性。 pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 maxconn 4096 # 单个 HAProxy 进程可接受的最大并发连接数，等价于命令行参数 "-n"。 nbthread 48 # 最大线程数。线程数的上限与 CPU 数量相同。 user haproxy # 同 UID 参数。 group haproxy # 同 GID 参数，建议使用专用用户组。 daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 stats socket /var/lib/haproxy/stats # 统计信息保存位置。 defaults # 默认配置。 log global # 日志继承全局配置段的设置。 retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 timeout server 30000s # 服务器端非活动连接的超时时间。 listen admin_stats # frontend 和 backend 的组合体，此监控组的名称可按需进行自定义。 bind 0.0.0.0:8080 # 监听端口。 mode http # 监控运行的模式，此处为 `http` 模式。 option httplog # 开始启用记录 HTTP 请求的日志功能。 maxconn 10 # 最大并发连接数。 stats refresh 30s # 每隔 30 秒自动刷新监控页面。 stats uri /haproxy # 监控页面的 URL。 stats realm HAProxy # 监控页面的提示信息。 stats auth admin:pingcap123 # 监控页面的用户和密码，可设置多个用户名。 stats hide-version # 隐藏监控页面上的 HAProxy 版本信息。 stats admin if TRUE # 手工启用或禁用后端服务器（HAProxy 1.4.9 及之后版本开始支持）。 listen tidb-cluster # 配置 database 负载均衡。 bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 mode tcp # HAProxy 要使用第 4 层的传输层。 balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3

空闲超时

默认官方空闲超时设置非交互式连接无限制，交互式连接超时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日志也接入了告警，并根据出现的警告和错误，一一排查，屏蔽可忽略告警，以下列了一些常见告警或警告。

忽略不支持的事务隔离级别告警

[error="[variable:8048]The isolation level READ-UNCOMMITTED is not supported. Set tidb_skip_isolation_level_check=1 to skip this error"

修改tidb_analyze_version版本，解决内存不断上涨的问题

#当 tidb_analyze_version = 2 时，如果执行 ANALYZE 语句后发生 OOM，请设置全局变量 tidb_analyze_version = 1 1、set global tidb_analyze_version = 1; //使用v1版本的 analyze 2、执行以下sql产生的语句 select distinct(concat(DROP STATS ,table_schema, ., table_name,;)) from information_schema.tables, mysql.stats_histograms where stats_ver = 2 and table_id = tidb_table_id ; 3、步骤二产生的语句全部执行完后，确认stats_ver = 2以下语句没有内容 select distinct(concat(table_schema, ., table_name)) from information_schema.tables, mysql.stats_histograms where stats_ver = 2 and table_id = tidb_table_id ; 4、重启tidb-server

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”的报错，需要关注以下监控：

通过 “PD Client CMD Duration” 中 “99-tso-aync-wait” ,SQL Parse 和 SQL Compile 对延迟的影响情况。 通过 “PD TSO Wait Duration”，可以监控到 TiDB Server Function Request to Feedback 延迟收到网络的影响。 通过 “PD TSO RPC Duration” 可以直观监控的网络的延迟时间，PD 处理慢这个可能性存，但较小。

expensive query

TiDB 在执行 SQL时，预估出来每个operator 处理了超过 10000 条数据就认为这条 query