【TiDBer 唠嗑茶话会 65 】赢取 Ti 红露营五件套，分享常见 TiDB 错误 & 解决不费脑！

TiDB社区小助手 · 2023 年3 月 31 日 09:41

Ti 红露营装备五件套限时空降本期唠嗑茶话会啦！！

各位 TiDBer 肯定会问了
：该如何获得Ti 红露营装备五件套呐？？？
：大家先别急，让 robot 先来介绍一下本期的主题：TiDB 数据库常见错误以及对应解决方案分享大会。
（PS: 如果你真的很急，允许你先跳转到最后【Ti 红露营装备限定奖】查看获得条件）

在使用 TiDB 进行开发或运维时，我们常常会遇到一些错误或问题。了解这些错误及其解决方法可以帮助我们更好地管理 TiDB 数据库，提高工作效率。所以本期来个 TiDB 数据库中常见的错误 & 解决方法分享大会！来把我们走过的路分享给更多小伙伴们吧～

举个栗子🌰：

“PD server timeout” 错误：该错误通常表示 PD Server（Placement Driver）的响应超时，可能是由于网络故障或 PD 集群负载过高导致的。

解决方法包括增加 PD 集群节点，优化 PD 集群性能。检查 PD 节点的状态并修复任何宕机或网络问题。

再举个栗子🌰：

“Error 1009: invalid time zone” 错误：该错误通常表示时区设置不正确，可能是由于操作系统或 TiDB 配置的问题导致的。

解决方法包括修改时区设置，重新启动 TiDB 集群等。

所以本期各位 TiDBer 们来秀出你的经验吧～PS: 请各位 TiDBer 们分享的时候按照以下两部分进行分享哦～👇

常见的错误 + 解决方案

话题结束后各位小伙伴们分享的集合会做成【社区智慧干货】出现哦～

本期话题：

快来分享TiDB 数据库中常见的错误 & 解决方法吧～（PS:两部分都要有哦）

活动奖励：

Ti 红露营装备限定奖

本期唠嗑茶话会按照格式分享并收获 最多好评💗点赞 的 TiDBer 奖励 Ti 红露营装备五件套！

本期唠嗑茶话会按照格式分享并 贡献数量最多 常见的 TiDB 数据库错误及对应解决方案的 TiDBer 奖励 Ti 红露营装备五件套！

参与奖：

按照【常见错误+解决方法】格式分享的 TiDBer 可获得 30 积分奖励～

活动时间：

2023.3.31-2023.4.7

Ti 红露营装备五件套展示图

ShawnYan · 2023 年3 月 31 日 12:00

举个栗子🌰

xfworld · 2023 年3 月 31 日 13:44

[常见错误]
tikv 内存疯长，不见消退

[解决方法]

查看 tikv 的版本是否是官方编译版本，否则请查阅 linux 的内存分配方案（方案选择错误，导致内存无法及时回收）
磁盘IO 不足，写入较慢，导致写入内存快于刷盘，开启流控，保证内存和刷盘能够稳定…
slow Query 下推长期占用资源，无法及时的释放；开启资源定位，能够找到这些 slow query，进行优化，减少资源长期占用的情况

Jellybean · 2023 年3 月 31 日 14:27

执行SQL时，尤其是执行时间较久的SQL，有时会报 Information schema is changed 错误
- 原理：TiDB 在执行 SQL 语句时，会使用当时的 schema 来处理该 SQL 语句，而且 TiDB 支持在线异步变更 DDL。那么，在执行 DML 的时候可能有 DDL 语句也在执行，而你需要确保每个 SQL 语句在同一个 schema 上执行。所以当执行 DML 时，遇到正在执行中的 DDL 操作就可能会报 Information schema is changed 的错误
- 原因 1：正在执行的 DML 所涉及的表和集群中正在执行的 DDL 的表有相同的
- 原因 2：这个 DML 执行时间很久，期间集群执行了很多 DDL 语句或 TiDB 由于网络问题长时间不能加载到 schema information，导致中间 schema 版本变更次数超过 tidb_max_delta_schema_count 的值
解决方法：
- SQL 在失败后重试，大部分情况都可以恢复
- 检查集群之间的网络情况，排除网络问题

TiDBer_pFFcXLgY · 2023 年3 月 31 日 15:51

【常见错误】
查询使用了hint，但是还是不走tiflash，查询很慢。
而主动设置SESSION为tiflash后查询，查询速度很快

【解决方法】
子查询也加上hint；
表的统计信息不准，可以手动 analyze table 收集统计信息，可能不加 hint 也能默认走到 tiflash

清风明月 · 2023 年3 月 31 日 22:17

【常见错误】
1、通过tidb operator在创建各组件的Pod时常处于 Pending 状态，通常会卡在某个组件服务的创建上。
【解决方法】
通常都是资源不满足导致的，具体的可以通过kubectl describe po -n ${namespace} ${pod_name}进行查看具体的，大部分的原因都是由于PV卷没有正常绑定造成的，通过修改或删除进行相关的解决。

2、tidb各服务组件常出现 CrashLoopBackOff
【原因】
在想pv里写数据库的时候由于该pv有数据或没有权限造成的。
【解决方法】
1.通过kubectl describe pod/$pod -n$ns。发现初始化失败重启后失败又重启。

2.通过查看该pod的日志，发现相关的报错，大致就是初始化数据的时候有相关的文件造成初始化数据文件失败。新的pod在往里写数据的时候写不进去。

3.通过解绑pv和pvc，删除pv里的数据，然后重新绑定解决。或者直接删除绑定pv里的数据，kubelet过两分钟还会重启该容器，最近该pod的状态为running。

天蓝色的小九 · 2023 年3 月 31 日 23:43

访问 PD 报错：TiKV cluster is not bootstrapped

PD 的大部分 API 需要在初始化 TiKV 集群以后才能使用，如果在部署新集群的时候只启动了 PD，还没有启动 TiKV，这时候访问 PD 就会报这个错误。遇到这个错误应该先把要部署的 TiKV 启动起来，TiKV 会自动完成初始化工作，然后就可以正常访问 PD

YuchongXU · 2023 年4 月 1 日 00:24

查询异常变慢？

TiDBer_AAeSUyTk · 2023 年4 月 1 日 01:19

发生 CrashLoopBackOff有没有快速解决方式呢？

清风明月 · 2023 年4 月 1 日 01:21

是的，在整个集群初始化的过程中，需要先启动pd，然后tikv，tidb。相关数据的持久化需要存储在tikv，tikv正常启动后整个服务才会正常使用pd

清风明月 · 2023 年4 月 1 日 01:22

看下绑定pv的SC，在删除的时候可以设置卷的类型为delete。解绑的时候就会自动删除里边的数据。

啦啦啦啦啦 · 2023 年4 月 1 日 09:58

【常见错误】
一个缩容的常见错误，3节点的tikv集群，宕机一台后起不来缩容一直处于offline状态，无法正常下线。
【原因】
要保证三副本，只剩下2个tikv节点会导致region 副本无法进行调度，因此无法正常下线
【解决方法】
要先扩容一个节点，让集群满足至少3节点的条件，region副本可以正常调度再进行缩容tikv

DBRE · 2023 年4 月 2 日 00:28

【常见错误】
tikv metric过多导致prometheus存储量巨大和prometheus多次重启
【原因】
tikv metric过多
【解决方法】
prometheus配置文件在job:tikv处增加如下行
metric_relabel_configs:

source_labels: [name]
separator: ;
regex: tikv_thread_nonvoluntary_context_switches|tikv_thread_voluntary_context_switches|tikv_threads_io_bytes_total
action: drop
source_labels: [name,name]
separator: ;
regex: tikv_thread_cpu_seconds_total;(tokio|rocksdb).+
action: drop

但是tikv为何这么多的metrics还需要官方定位，再次捞下旧帖： tikv状态接口输出metric过多，请问如何优化呢？

兜兜就是我 · 2023 年4 月 2 日 03:21

经常性晕倒非数据库问题，而是由于操作系统、网络、应用端的错误配置引起数据库异常的事件！！！！

Soysauce520 · 2023 年4 月 2 日 04:13

drainer组件同步延迟：该问题是业务量过大，drainer进程处理不过来导致
解决方法拆分drainer，扩容drainer利用参数syncer.replicate-do-db分别同步不同的database
config:
syncer.replicate-do-db
- database1, dataase2, database3

ddhe9527 · 2023 年4 月 2 日 12:20

执行SQL语句时出现报错：1105 - Out Of Memory Quota
解决方案：可以在session级别设置tidb_mem_quota_query到足够大，例如：

set tidb_mem_quota_query=8589934592;

tomxu · 2023 年4 月 3 日 00:59

[常见错误]
一、使用 TiDB Lightning 导入数据，可能会出现以下几种情况导致导入失败：

[解决方法]
1.数据源错误：TiDB Lightning 要求 MySQL 数据库 dump 文件的格式必须符合规范，否则可能会导致导入失败。可以通过使用 mydumper 工具生成规范的 dump 文件，或者使用其他工具进行数据预处理以满足要求。
2.配置错误：TiDB Lightning 的配置文件中需要指定正确的参数，如 MySQL 数据库地址、端口、用户名、密码等。如果配置有误，导入也会失败。
3.磁盘空间不足：在导入过程中，TiDB Lightning 会将导入的数据暂时存储到磁盘中，并在导入完成后删除。如果磁盘空间不足，导入也会失败。
4.TiDB 集群故障：在导入过程中，如果 TiDB 集群出现故障，如 PD 节点宕机、TiKV 节点宕机等，也会导致导入失败。
5.数据冲突：在导入过程中，如果原数据库中存在与待导入数据冲突的数据，如主键冲突，也会导致导入失败。
6.权限问题：TiDB Lightning 对下游数据库的账号权限也是要求的。如果没有给予足够权限，导入过程中也会出现权限不足的错误。
总之，TiDB Lightning 导入数据失败的原因有可能很多，需要根据具体情况进行排查。可以通过查看 TiDB Lightning 的报错信息，并结合实际情况分析，逐步解决问题。

[常见错误]
二、TiDB 使用过程中最常见的几类问题及其解决方法：

[解决方法]
1.TiDB 集群无法正常启动：
可能的情况包括 TiDB 组件配置错误、物理机器硬件故障、TiDB 版本不兼容等。解决方法需要根据具体错误日志来定位问题并进行逐一排查。
2.TiDB 集群性能较差：
可能的原因包括 TiDB 性能调优不足、写入热点导致的数据分布不均衡等。解决方法可以通过 TiUP Bench 工具对集群进行基准测试，然后进行相关优化。
3.TiDB 导入/导出数据失败：
主要问题包括磁盘空间不足、数据量太大导致内存不足、数据库连接不稳定等。解决方法可以添加更多磁盘或者从 TiDB 集群中增加节点来提高资源容量，或者尝试将数据切分成多个小批次进行导出。
4.TiDB 集群出现数据损坏：
可能的原因包括磁盘故障、节点崩溃、操作系统异常等。解决方法可以通过备份和恢复集群来解决问题。
5.TiDB SQL 优化不足：
可能的原因包括 SQL 写法不合理、表设计不合理等。解决方法可以通过使用 TiDB Query Profiling 工具来分析 SQL 查询性能，进行优化。
6.TiDB 安全风险：
可能的问题包括隐私数据泄露、身份验证不安全等。解决方法可以通过加强 TiDB 集群的安全机制，限制某些权限和操作，保护敏感数据安全。