我的书签
添加书签
移除书签- FAQ
- 一、 TiDB 介绍、架构、原理
- 二、云上部署
- 三、故障排除
- 3.1 TiDB 自定义报错汇总
- 3.1.1 ERROR 8005 (HY000) : Write Conflict, txnStartTS is stale
- 3.1.2 ERROR 9001 (HY000) : PD Server Timeout
- 3.1.3 ERROR 9002 (HY000) : TiKV Server Timeout
- 3.1.4 ERROR 9003 (HY000) : TiKV Server is Busy
- 3.1.5 ERROR 9004 (HY000) : Resolve Lock Timeout
- 3.1.6 ERROR 9005 (HY000) : Region is unavailable
- 3.1.7 ERROR 9006 (HY000) : GC life time is shorter than transaction duration
- 3.1.8 ERROR 9007 (HY000) : Write Conflict
- 3.1.9 ERROR 8130 (HY000): client has multi-statement capability disabled
- 3.2 MySQL 原生报错汇总
- 3.2.1 ERROR 2013 (HY000): Lost connection to MySQL server during query 问题的排查方法？
- 3.2.2 ERROR 1105 (HY000): other error: unknown error Wire Error(InvalidEnumValue(4004)) 是什么意思？
- 3.2.3 ERROR 1148 (42000): the used command is not allowed with this TiDB version 问题的处理方法？
- 3.2.4 ERROR 9001 (HY000): PD server timeout start timestamp may fall behind safe point
- 3.3 TiDB 日志中的报错信息
- 3.1 TiDB 自定义报错汇总
FAQ
一、 TiDB 介绍、架构、原理
1.1 TiDB 介绍及整体架构
1.1.1 TiDB 整体架构
1.1.2 TiDB 是什么？
TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。
1.1.3 TiDB 是基于 MySQL 开发的吗？
不是，虽然 TiDB 支持 MySQL 语法和协议，但是 TiDB 是由 PingCAP 团队完全自主开发的产品。
1.1.4 TiDB、TiKV、Placement Driver (PD) 主要作用？
- TiDB 是 Server 计算层，主要负责 SQL 的解析、制定查询计划、生成执行器。
- TiKV 是分布式 Key-Value 存储引擎，用来存储真正的数据，简而言之，TiKV 是 TiDB 的存储引擎。
- PD 是 TiDB 集群的管理组件，负责存储 TiKV 的元数据，同时也负责分配时间戳以及对 TiKV 做负载均衡调度。
1.1.5 TiDB 易用性如何？
TiDB 使用起来很简单，可以将 TiDB 集群当成 MySQL 来用，你可以将 TiDB 用在任何以 MySQL 作为后台存储服务的应用中，并且基本上不需要修改应用代码，同时你可以用大部分流行的 MySQL 管理工具来管理 TiDB。
1.1.6 TiDB 和 MySQL 兼容性如何？
TiDB 目前还不支持触发器、存储过程、自定义函数、外键，除此之外，TiDB 支持绝大部分 MySQL 5.7 的语法。
详情参见与 MySQL 兼容性对比。
1.1.7 TiDB 支持分布式事务吗？
支持。无论是一个地方的几个节点，还是跨多个数据中心的多个节点，TiDB 均支持 ACID 分布式事务。
TiDB 事务模型灵感源自 Google Percolator 模型，主体是一个两阶段提交协议，并进行了一些实用的优化。该模型依赖于一个时间戳分配器，为每个事务分配单调递增的时间戳，这样就检测到事务冲突。在 TiDB 集群中，PD 承担时间戳分配器的角色。
1.1.8 TiDB 支持哪些编程语言？
只要支持 MySQL Client/Driver 的编程语言，都可以直接使用 TiDB。
1.1.9 TiDB 是否支持其他存储引擎？
是的，除了 TiKV 之外，TiDB 还支持一些流行的单机存储引擎，比如 GolevelDB、RocksDB、BoltDB 等。如果一个存储引擎是支持事务的 KV 引擎，并且能提供一个满足 TiDB 接口要求的 Client，即可接入 TiDB。
1.1.10 除了官方文档，有没有其他 TiDB 知识获取途径？
目前官方文档是获取 TiDB 相关知识最主要、最及时的发布途径。除此之外，我们也有一些技术沟通群，如有需求可发邮件至 info@pingcap.com 获取，以及 AskTUG 网站 与技术专家互动交流。
1.1.11 TiDB 用户名长度限制？
在 TiDB 中用户名最长为 32 字符。
1.1.12 TiDB 是否支持 XA？
虽然 TiDB 的 JDBC 驱动用的就是 MySQL JDBC（Connector / J），但是当使用 Atomikos 的时候，数据源要配置成类似这样的配置：type="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource"。MySQL JDBC XADataSource 连接 TiDB 的模式目前是不支持的。MySQL JDBC 中配置好的 XADataSource 模式，只对 MySQL 数据库起作用（DML 去修改 redo 等）。
Atomikos 配好两个数据源后，JDBC 驱动都要设置成 XA 模式，然后 Atomikos 在操作 TM 和 RM（DB）的时候，会通过数据源的配置，发起带有 XA 指令到 JDBC 层，JDBC 层 XA 模式启用的情况下，会对 InnoDB（如果是 MySQL 的话）下发操作一连串 XA 逻辑的动作，包括 DML 去变更 redo log 等，就是两阶段递交的那些操作。TiDB 目前的引擎版本中，没有对上层应用层 JTA / XA 的支持，不解析这些 Atomikos 发过来的 XA 类型的操作。
MySQL 是单机数据库，只能通过 XA 来满足跨数据库事务，而 TiDB 本身就通过 Google 的 Percolator 事务模型支持分布式事务，性能稳定性比 XA 要高出很多，所以不会也不需要支持 XA。
1.2 TiDB 原理
1.2.1 存储 TiKV
1.2.1.1 TiKV 详细解读
1.2.2 计算 TiDB
1.2.2.1 TiDB 详细解读
1.2.3 调度 PD
1.2.3.1 PD 详细解读
二、云上部署
2.1 公有云
2.1.1 目前 TiDB 云上部署都支持哪些云厂商？
关于云上部署，TiDB 支持在 Google GKE、AWS EKS 和 阿里云 ACK 上部署使用。
此外，TiDB 云上部署也已在京东云、UCloud 上线，均为数据库一级入口，欢迎大家使用。
三、故障排除
3.1 TiDB 自定义报错汇总
3.1.1 ERROR 8005 (HY000) : Write Conflict, txnStartTS is stale
可以检查 tidb_disable_txn_auto_retry 是否为 on。如是，将其设置为 off；如已经是 off，将 tidb_retry_limit 调大到不再发生该错误。
3.1.2 ERROR 9001 (HY000) : PD Server Timeout
请求 PD 超时，请检查 PD Server 状态/监控/日志以及 TiDB Server 与 PD Server 之间的网络。
3.1.3 ERROR 9002 (HY000) : TiKV Server Timeout
请求 TiKV 超时，请检查 TiKV Server 状态/监控/日志以及 TiDB Server 与 TiKV Server 之间的网络。
3.1.4 ERROR 9003 (HY000) : TiKV Server is Busy
TiKV 操作繁忙，一般出现在数据库负载比较高时，请检查 TiKV Server 状态/监控/日志。
3.1.5 ERROR 9004 (HY000) : Resolve Lock Timeout
清理锁超时，当数据库上承载的业务存在大量的事务冲突时，会遇到这种错误，请检查业务代码是否有锁争用。
3.1.6 ERROR 9005 (HY000) : Region is unavailable
访问的 Region 不可用，某个 Raft Group 不可用，如副本数目不足，出现在 TiKV 比较繁忙或者是 TiKV 节点停机的时候，请检查 TiKV Server 状态/监控/日志。
3.1.7 ERROR 9006 (HY000) : GC life time is shorter than transaction duration
GC Life Time 间隔时间过短，长事务本应读到的数据可能被清理了，可使用如下命令增加 GC Life Time：
update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time';
其中 30m 代表仅清理 30 分钟前的数据，这可能会额外占用一定的存储空间。
3.1.8 ERROR 9007 (HY000) : Write Conflict
可以检查 tidb_disable_txn_auto_retry 是否为 on。如是，将其设置为 off；如已经是 off，将 tidb_retry_limit 调大到不再发生该错误。
3.1.9 ERROR 8130 (HY000): client has multi-statement capability disabled
从早期版本的 TiDB 升级后，可能会出现该问题。为了减少 SQL 注入攻击的影响，TiDB 目前默认不允许在同一 COM_QUERY 调用中执行多个查询。
可通过系统变量 tidb_multi_statement_mode 控制是否在同一 COM_QUERY 调用中执行多个查询。
3.2 MySQL 原生报错汇总
3.2.1 ERROR 2013 (HY000): Lost connection to MySQL server during query 问题的排查方法？
- log 中是否有 panic
- dmesg 中是否有 oom，命令：
dmesg -T | grep -i oom - 长时间没有访问，也会收到这个报错，一般是 tcp 超时导致的，tcp 长时间不用, 会被操作系统 kill。
3.2.2 ERROR 1105 (HY000): other error: unknown error Wire Error(InvalidEnumValue(4004)) 是什么意思？
这类问题一般是 TiDB 和 TiKV 版本不匹配，在升级过程尽量一起升级，避免版本 mismatch。
3.2.3 ERROR 1148 (42000): the used command is not allowed with this TiDB version 问题的处理方法？
这个问题是因为在执行 LOAD DATA LOCAL 语句的时候，MySQL 客户端不允许执行此语句（即 local_infile 选项为 0）。解决方法是在启动 MySQL 客户端时，用 --local-infile=1 选项。具体启动指令类似：mysql --local-infile=1 -u root -h 127.0.0.1 -P 4000。有些 MySQL 客户端需要设置而有些不需要设置，原因是不同版本的 MySQL 客户端对 local-infile 的默认值不同。
3.2.4 ERROR 9001 (HY000): PD server timeout start timestamp may fall behind safe point
这个报错一般是 TiDB 访问 PD 出了问题，TiDB 后台有个 worker 会不断地从 PD 查询 safepoint，如果超过 100s 查不成功就会报这个错。一般是因为 PD 磁盘操作过忙、反应过慢，或者 TiDB 和 PD 之间的网络有问题。TiDB 常见错误码请参考错误码与故障诊断。
3.3 TiDB 日志中的报错信息
3.3.1 EOF
当客户端或者 proxy 断开连接时，TiDB 不会立刻察觉连接已断开，而是等到开始往连接返回数据时，才发现连接已断开，此时日志会打印 EOF 错误。
