常见问题解答

一,TiDB介绍,架构,原理

1.1 TiDB介绍及整体架构

1.1.1 TiDB整体架构

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，放置驱动器（PD）主要作用？

• TiDB是服务器计算层,主要负责SQL的解析,制定查询计划,生成执行器。
• TiKV是分布式键值存储引擎，用来存储真正的数据，简而言之，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均支持酸分布式事务。

TiDB事务模型灵感源自谷歌Percolator模型,主体是一个两阶段提交协议,并进行了一些实用的优化。该模型依赖于一个时间戳分配器，为每个事务分配单调递增的时间戳，这样就检测到事务冲突。在TiDB集群中,PD承担时间戳分配器的角色。

1.1.8 TiDB支持哪些编程语言吗?

只要支持MySQL客户端/驱动程序的编程语言,都可以直接使用TiDB。

1.1.9 TiDB是否支持其他存储引擎?

是的,除了TiKV之外,TiDB还支持一些流行的单机存储引擎,比如GolevelDB, RocksDB, BoltDB等。如果一个存储引擎是支持事务的KV引擎,并且能提供一个满足TiDB接口要求的客户端,即可接入TiDB。

1.1.10除了官方文档，有没有其他TiDB知识获取途径？

目前官方文档是获取TiDB相关知识最主要，最及时的发布途径。除此之外，我们也有一些技术沟通群，如有需求可发邮件至info@m.rzhenli.com获取，以及AskTUG网站与技术专家互动交流。

1.1.11 TiDB用户名长度限制？

在TiDB中用户名最长为32字符。

1.1.12 TiDB是否支持XA？

虽然TiDB的JDBC驱动用的就是MySQL的JDBC（接头/ J），但是当使用Atomikos公司的时候，数据源要配置成类似这样的配置：type = " com.mysql.jdbc.jdbc2.optional.MysqlXADataSource "。MySQL JDBC XADataSource来连接TiDB的模式目前是不支持的。MySQL JDBC中配置好的XADataSource来模式,只对MySQL数据库起作用(DML去修改重做等)。

于Atomikos配好两个数据源后,JDBC驱动都要设置成XA模式,然后于Atomikos在操作TM和RM (DB)的时候,会通过数据源的配置,发起带有XA指令到JDBC层。XA JDBC层模式启用的情况下,会对InnoDB(如果是MySQL的话)下发操作一连串XA逻辑的动作,包括DML去变更重做日志等,就是两阶段递交的那些操作。TiDB目前的引擎版本中,没有对上层应用层JTA / XA的支持,不解析这些于Atomikos发过来的XA类型的操作。

MySQL的是单机数据库，只能通过XA来满足跨数据库事务，而TiDB本身就通过谷歌的渗滤器事务模型支持分布式事务，性能稳定性比XA要高出很多，所以不会也不需要支持XA。

1.2 TiDB原理

1.2.1存储TiKV

1.2.1.1 TiKV详细解读

三篇文章了解TiDB技术内幕 - 说存储

1.2.2计算TiDB

1.2.2.1 TiDB详细解读

三篇文章了解TiDB技术内幕——说计算

1.2.3调度PD

1.2.3.1 PD详细解读

三篇文章了解TiDB技术内幕——谈调度

二、云上部署

2.1公有云

2.1.1目前TiDB云上部署都支持哪些云厂商？

关于云上部署,TiDB支持在谷歌GKE、AWS的和阿里云ACK上部署使用。

此外,TiDB云上部署也已在京东云,UCloud上线,均为数据库一级入口,欢迎大家使用。

三、故障排除

3.1 TiDB自定义报错汇总

3.1.1 ERROR 8005（HY000）：写入冲突，txnStartTS陈旧

可以检查tidb_disable_txn_auto_retry是否为上如是，将其设置为关闭;如已经是关闭，将tidb_retry_limit调大到不再发生该错误。

3.1.2 ERROR 9001 (HY000): PD Server Timeout

请求PD超时,请检查PD服务器状态/监控/日志以及TiDB服务器与PD服务器之间的网络。

3.1.3错误9002 (HY000): TiKV服务器超时

请求TiKV超时，请检查TiKV服务器状态/监控/日志以及TiDB服务器与TiKV服务器之间的网络。

3.1.4错误9003 (HY000): TiKV服务器忙

TiKV操作繁忙，一般出现在数据库负载比较高时，请检查TiKV服务器状态/监控/日志。

3.1.5 ERROR 9004 (HY000): Resolve Lock Timeout

清理锁超时，当数据库上承载的业务存在大量的事务冲突时，会遇到这种错误，请检查业务代码是否有锁争用。

3.1.6 ERROR 9005 (HY000): Region is unavailable

访问的地区不可用,某个筏集团不可用,如副本数目不足,出现在TiKV比较繁忙或者是TiKV节点停机的时候,请检查TiKV服务器状态/监控/日志。

3.1.7 ERROR 9006（HY000）：GC寿命为交易持续时间短

GC寿命间隔时间过短，长事务本应读到的数据可能被清理了。你可以使用如下命令修改tidb_gc_life_time的值：

集全球tidb_gc_life_time＝30米的；

其中30米代表仅清理30分钟前的数据,这可能会额外占用一定的存储空间。

3.1.8 ERROR 9007（HY000）：写入冲突

可以检查tidb_disable_txn_auto_retry是否为上如是，将其设置为关闭;如已经是关闭，将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错误2013 (HY000):失去了连接到MySQL服务器在查询问题的排查方法?

• 日志中是否有恐慌
• dmesg命令中是否有伯父,命令:dmesg的-T |grep的-i OOM
• 长时间没有访问，也会收到这个报错，一般是TCP超时导致的，TCP长时间不用，会被操作系统杀死。

3.2.2 ERROR 1105（HY000）：其他错误：未知错误线错误（InvalidEnumValue（4004））是什么意思？

这类问题一般是TiDB和TiKV版本不匹配，在升级过程尽量一起升级，避免版本不匹配。

3.2.3 ERROR 1148（42000）：所使用的命令是不是与此TiDB版本问题的处理方法允许？

这个问题是因为在执行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服务器超时启动时间戳可能落后于安全点

这个报错一般是TiDB访问PD出了问题，TiDB后台有个工作人员会不断地从PD查询还原点，如果超过100秒查不成功就会报这个错。一般是因为PD磁盘操作过忙，反应过慢，或者TiDB和PD之间的网络有问题.TiDB常见错误码请参考错误码与故障诊断。

3.3 TiDB日志中的报错信息

3.3.1 EOF

当客户端或者代理断开连接时，TiDB不会立刻察觉连接已断开，而是等到开始往连接返回数据时，才发现连接已断开，此时日志会打印EOF错误。