| title | category |
|---|---|
TiDB FAQ |
FAQ |
TiDB 是一个分布式 NewSQL 数据库。支持水平扩展、高可用、ACID 事务、SQL 等特性。同时 TiDB 还支持 MySQL 语法和 MySQL 协议。
不是。虽然 TiDB 支持 MySQL 语法和协议，但是 TiDB 是由 PingCAP 团队完全自主开发的产品。
MySQL Group Replication (MGR) 是基于 MySQL 单机版的一个高可用解决方案，而 MGR 不解决扩展性的问题。TiDB 从架构上就比较适合分布式场景，在开发过程中的各种决策也是以如何适应分布式场景出发来设计的。
TiDB 是 SQL 层，主要负责 SQL 的解析、制定查询计划、生成执行器；TiKV 是分布式 Key-Value 存储引擎，用来存储真正的数据。简而言之，TiKV 是 TiDB 的存储引擎。
PD 是 TiDB 集群的管理组件，负责存储 TiKV 的元数据，同时也负责分配时间戳以及对 TiKV 做负载均衡调度。
是的，TiDB 用起来很简单。启动整套服务后，就可以将 TiDB 当做一个普通的 MySQL Server 来用，你可以将 TiDB 用在任何以 MySQL 作为后台存储服务的应用中，并且基本上不需要修改应用代码。同时你可以用大部分流行的 MySQL 管理工具来管理 TiDB。
原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时，可以考虑使用 TiDB 无缝替换 MySQL。TiDB 可以提供如下特性：
- 吞吐、存储和计算能力的水平扩展
- 水平伸缩时不停服务
- 强一致性
- 分布式 ACID 事务
如果你的应用数据量小（所有数据千万级别行以下），且没有高可用、强一致性或者多数据中心复制等要求，那么就不适合使用 TiDB。
TiDB 使用 Raft 在多个副本之间做数据同步，从而保证数据的强一致。单个副本失效时，不影响数据的可靠性。
TiDB 支持 ACID 分布式事务。事务模型是以 Google 的 Percolator 模型为基础，并做了一些优化。这个模型需要一个时间戳分配器，分配唯一且递增的时间戳。在 TiDB 集群中，PD 承担时间戳分配器的角色。
会，事务冲突中写入失败的事务会进行退避，并在合适的时机进行重试，TiDB 中默认失败重试的次数为 10 次。
可以用任何你喜欢的编程语言，只要该语言有 MySQL Client/Driver。
和这些数据库相比，TiDB 最大的特点是可以无限水平扩展，在此过程中不损失事务特性。
TiDB 在提供水平扩展特性的同时，还能提供 SQL 以及分布式事务。
请手动将 TiDB 复制到 GOPATH 目录，然后运行 make 命令。TiDB 是一个项目而不是一个库，它的依赖比较复杂，并且 parser 也是根据 parser.y 生成的，我们不支持 go get 方式，而是使用 Makefile 来管理。
如果你是开发者并且熟悉 Go 语言，你可以尝试在 TiDB 项目的根目录运行 make parser; ln -s _vendor/src vendor ，之后就可以使用 go run, go test, go install 等命令，但是并不推荐这种做法。
高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。具体见 TiDB 高可用性。
DELETE，TRUNCATE 和 DROP 都不会立即释放空间。对于 TRUNCATE 和 DROP 操作，在达到 TiDB 的 GC (garbage collection) 时间后（默认 10 分钟），TiDB 的 GC 机制会删除数据并释放空间。对于 DELETE 操作 TiDB 的 GC 机制会删除数据，但不会释放空间，而是当后续数据写入 RocksDB 且进行 compact 时对空间重新利用。
不可以，加载数据期间不能对目标表执行任何 DDL 操作，这会导致数据加载失败。
支持，但是 load data 不支持 replace into 语法。
TiDB 目前暂时不支持 select into outfile，可以通过以下方式导出 TiDB 数据：
- 参考 MySQL使用mysqldump导出某个表的部分数据，使用 mysqldump 加 where 条件导出。
- 使用 MySQL client 将 select 的结果输出到一个文件。
TiDB 暂不支持数据库层面的会话超时，目前想要实现超时，在没 LB（Load Balancing） 的时候，需要应用侧记录发起的 session 的 id，通过应用自定义超时，超时以后需要到发起 query 的节点上用 kill tidb id 来杀掉 sql。目前建议使用应用程序来实现会话超时，当达到超时时间，应用层就会抛出异常继续执行后续的程序段。
PD 的大部分 API 需要在初始化 TiKV 集群以后才能使用，如果在部署新集群的时候只启动了 PD，还没有启动 TiKV，这时候访问 PD 就会报这个错误。遇到这个错误应该先把要部署的 TiKV 启动起来，TiKV 会自动完成初始化工作，然后就可以正常访问 PD 了。
PD 启动参数中的 --initial-cluster 包含了某个不属于该集群的成员。遇到这个错误时请检查各个成员的所属集群，剔除错误的成员后即可正常启动。
当想更改 PD 的 --client-url，--advertise-client-url 或 --name 时，只要用更新后的参数重新启动该 PD 就可以了。当更改的参数是 --peer-url 或 --advertise-peer-url 时，有以下几种情况需要区别处理：
- 之前的启动参数中有
--advertise-peer-url，但只想更新--peer-url：用更新后的参数重启即可。 - 之前的启动参数中没有
--advertise-peer-url：先用etcdctl更新该 PD 的信息，之后再用更新后的参数重启即可。
理论上误差越小越好，切换 leader 的时候如果时钟回退，就会卡住直到追上之前的 leader。这个容忍是业务上的，PD 多长的误差都能容忍。 但是误差越大，主从切换的时候，停止服务的时间越长。
Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD 与 TiKV 对 client 透明。当 TiDB 连接任意一台 PD 的时候，PD 会告知 TiDB 当前的 leader 是谁，如果此台 PD 不是 leader ，TiDB 将会重新连接至 leader PD。
leader-schedule-limit 调度是用来均衡不同 TiKV 的 leader 数，影响处理查询的负载。region-schedule-limit 调度是均衡不同 TiKV 的副本数，影响不同节点的数据量。
可以，目前只能调整全局的 replica 数量。首次启动时 PD 会读配置文件（conf/pd.yml），使用其中的 max-replicas 配置，之后修改需要使用 pd-ctl 配置命令 config set max-replicas $num，配置后可通过 config show all 来查看已生效的配置。调整的时候，不会影响业务，会在后台添加，注意总 TiKV 实例数总是要大于等于设置的副本数，例如 3 副本需要至少 3 个 TiKV。增加副本数量之前需要预估额外的存储需求。pd-ctl 的详细用法可参考 PD Control 使用说明。
启动 TiDB Server 时，需要通过命令行参数设置 lease 参数（--lease=60），其值会影响 DDL 的速度（只会影响当前执行 DDL 的 session，其他的 session 不会受影响）。在测试阶段，lease 的值可以设为 1s，加快测试进度；在生产环境下，我们推荐这个值设为分钟级（一般可以设为 60），这样可以保证 DDL 操作的安全。
是的。除了 TiKV 之外，TiDB 还支持一些流行的单机存储引擎，比如 GolevelDB, RocksDB, BoltDB 等。如果一个存储引擎是支持事务的 KV 引擎，并且能提供一个满足 TiDB 接口要求的 Client，即可接入 TiDB。
在 RocksDB 中。
可能原因如下：
- 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句会比较慢。原因是当前 TiDB 集群中 DDL 操作是串行执行的。
- 在正常集群启动后，第一个 DDL 操作的执行时间可能会比较久，一般在 30s 左右，这个原因是刚启动时 TiDB 在竞选处理 DDL 的 leader。
- 在滚动升级或者停机升级时，由于停机顺序（先停 PD 再停 TiDB）或者用
kill -9指令停 TiDB 导致 TiDB 没有及时清理注册数据，那么会影响 TiDB 启动后 10min 内的 DDL 语句处理时间。这段时间内运行 DDL 语句时，每个 DDL 状态变化都需要等待 2 * lease（默认 lease = 10s）。 - 当集群中某个 TiDB 与 PD 之间发生通讯问题，即 TiDB 不能从 PD 及时获取或更新版本信息，那么这时候 DDL 操作的每个状态处理需要等待 2 * lease。
- log 中是否有 panic
- dmesg 中是否有 oom, 命令：
dmesg |grep -i oom - 长时间没有访问，也会收到这个报错，一般是 tcp 超时导致的，tcp 长时间不用, 会被操作系统 kill。
不可以，目前 TiDB 只支持分布式存储引擎和 Goleveldb/Rocksdb/Boltdb 引擎；
如果你能够实现 S3 存储引擎客户端，应该基于 TiKV 接口实现。
测试的话，3 副本即可，副本升高，性能会有下降，但是安全性更高。是否设置更多副本需要看具体业务需要。
不可以。
TiKV 的 --data-dir 参数默认值为 /tmp/tikv/store，在某些虚拟机中，重启操作系统会删除 /tmp 目录下的数据，推荐通过 --data-dir 参数显式设置 TiKV 数据目录。
TiKV 本地存储的 cluster ID 和指定的 PD 的 cluster ID 不一致。在部署新的 PD 集群的时候，PD 会随机生成一个 cluster ID，TiKV 第一次初始化的时候会从 PD 获取 cluster ID 存储在本地，下次启动的时候会检查本地的 cluster ID 与 PD 的 cluster ID 是否一致，如果不一致则会报错并退出。出现这个错误一个常见的原因是，用户原先部署了一个集群，后来把 PD 的数据删除了并且重新部署了新的 PD，但是 TiKV 还是使用旧的数据重启连到新的 PD 上，就会报这个错误。
启动参数中的地址已经被其他的 TiKV 注册在 PD 集群中了。造成该错误的常见情况：TiKV --data-dir 指定的路径下没有数据文件夹时（删除或移动后没有更新 --data-dir），用之前参数重新启动该 TiKV。请尝试用 pdctl 的 store 删除功能，删除之前的 store, 然后重新启动 TiKV 即可。
RocksDB 对于 key 有压缩。
目前来看 master 有些文件的压缩率会高一些，这个取决于底层数据的分布和 RocksDB 的实现，数据大小偶尔有些波动是正常的，底层存储引擎会根据需要调整数据。
TiKV 使用了 RocksDB 的 Column Family (CF) 特性，KV 数据最终存储在默认 RocksDB 内部的 default、write 和 lock 3 个 CF 内。
-
default CF 存储的是真正的数据，与其对应的参数位于 [rocksdb.defaultcf] 项中； write CF 存储的是数据的版本信息（MVCC）以及索引相关的数据，相关的参数位于 [rocksdb.writecf] 项中； lock CF 存储的是锁信息，系统使用默认参数。
-
Raft Rocksdb 实例存储 Raft log。 default CF 主要存储的是 Raft log，与其对应的参数位于 [raftdb.defaultcf] 项中。
-
每个 CF 都有单独的 block-cache，用于缓存数据块，加速 RocksDB 的读取速度，block-cache 的大小通过参数 block-cache-size 控制，block-cache-size 越大，能够缓存的热点数据越多，对读取操作越有利，同时占用的系统内存也会越多。
-
每个 CF 有各自的 write-buffer，大小通过 write-buffer-size 控制。
- 通过
ps -Tp ${tikvPID}查看该 TiKV 下线程数量 - 登陆 TiKV 机器，通过
top -h查看该机器下线程使用 CPU 状态 - 登陆 Grafana 查看 TiKV dashboard 中 Thread-CPU；该 tab 中有各线程使用 CPU 状态
| 线程名 | 相关信息 |
|---|---|
| grpc-server-* | TiKV 与邻居以及 TiDB & PD 网络通信线程 |
| raftstore-* | 负责处理 raft 消息，通常写入量大的时候该线程会增高 |
| sched-worker-* | TiKV 写入会经过这个线程，当有大量写入数据时，线程使用cpu 增高 |
| endpoint-* | TiKV 读取数据会经过这个线程，需要读取大量数据或者 explain 出现 TableScan，线程使用 CPU 增高 |
| apply worker | 数据写入操作完成后，会经过这个线程写入到 rocksdb |
| rocksdb:bg* | rocksdb 对数据进行 compaction 的线程 |
可以参考 TiSpark 用户指南。
请参考链接中介绍的案例。
如果要使用配置文件，请设置 TiKV/PD 的 --config 参数，TiKV/PD 默认情况下不会读取配置文件。
因为 RocksDB 在 XFS 和某些 Linux kernel 中有 bug。所以不推荐使用 XFS 作为文件系统。
如果您想尝试使用，可以在 TiKV 的部署盘运行如下脚本，如果结果是 5000，可以尝试使用，但是不建议在生产环境中使用。
#!/bin/bash
touch tidb_test
fallocate -n -o 0 -l 9192 tidb_test
printf 'a%.0s' {1..5000} > tidb_test
truncate -s 5000 tidb_test
fallocate -p -n -o 5000 -l 4192 tidb_test
LANG=en_US.UTF-8 stat tidb_test |awk 'NR==2{print $2}'
rm -rf tidb_test可以，只要能让 PD 机器时间同步就行。若使用 Chrony 配置时间同步，请在运行 deploy 脚本之前将 inventory.ini 配置文件中的 enable_ntpd 置为 False，即 enable_ntpd = False。
当您的业务不断增长时，数据库可能会面临三方面瓶颈，第一是存储资源不够，也就是磁盘空间不够；第二是计算资源不够用，如 CPU 占用较高，第三是吞吐跟不上。这时可以对 TiDB 集群做水平扩展。
- 如果是存储资源不够，可以通过添加 TiKV Server 节点来解决。新节点启动后，PD 会自动将其他节点的部分数据迁移过去，无需人工介入。
- 如果是计算资源不够，可以查看 TiDB Server 和 TiKV Server 节点的 CPU 消耗情况，再考虑添加 TiDB Server 节点或者是 TiKV Server 节点来解决。如添加 TiDB Server 节点，将其配置在前端的 Load Balancer 之后即可。
- 如果是吞吐跟不上，一般可以考虑同时增加 TiDB Server 和 TiKV Server 节点。
监控机建议单独部署。建议 CPU 8 core，内存 32 GB 以上，硬盘 500 GB 以上。
查看访问监控的机器时间跟集群内机器的时间差，如果比较大，更正时间后即可显示正常。
下载 Syncer Json 导入到 Grafana，修改 Prometheus 配置文件，添加以下内容：
- job_name: ‘syncer_ops’ // 任务名字
static_configs:
- targets: [’10.10.1.1:10096’] //syncer监听地址与端口，通知prometheus去拉去syncer的数据。
重启 Prometheus 即可。
TiDB 支持绝大多数 MySQL 语法，一般不需要修改代码。我们提供了一个检查工具，用于检查 MySQL 中的 Schema 是否和 TiDB 兼容。
重启 TiDB 服务，配置文件中增加 -skip-grant-table=true 参数，登陆集群后按照如下 SQL 重建：
DROP TABLE IF EXIST mysql.user;
CREATE TABLE if not exists mysql.user (
Host CHAR(64),
User CHAR(16),
Password CHAR(41),
Select_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Insert_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Update_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Delete_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Create_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Drop_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Process_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Grant_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
References_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Alter_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Show_db_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Super_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Create_tmp_table_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Lock_tables_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Execute_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Create_view_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Show_view_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Create_routine_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Alter_routine_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Index_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Create_user_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Event_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
Trigger_priv ENUM('N','Y') NOT NULL DEFAULT 'N',
PRIMARY KEY (Host, User));
INSERT INTO mysql.user VALUES ("%", "root", "", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y", "Y");
TiDB 遵循 MySQL 的权限管理体系，可以创建用户并授予权限。
在创建用户时，可以使用 MySQL 语法，如 CREATE USER 'test'@'localhost' identified by '123';，这样就添加了一个用户名为 test，密码为 123 的用户，这个用户只能从 localhost 登录。
修改用户密码时，可以使用 Set Password 语句，例如给 TiDB 的默认 root 用户增加密码：SET PASSWORD FOR 'root'@'%' = '123';
在进行授权时，也可以使用 MySQL 语法，如 GRANT SELECT ON *.* TO 'test'@'localhost'; 将读权限授予 test 用户。
更多细节可以参考权限管理。
这三个组件默认情况下会将日志输出到标准错误，如果启动的时候通过 --log-file 参数指定了日志文件，那么日志会输出到指定的文件中，并且按天做 rotation。
如果是用 Ansible 部署的，可以使用 ansible-playbook stop.yml 命令停止 TiDB 集群。如果不是 Ansible 部署的，可以直接 kill 掉所有服务。如果使用 kill 命令，TiDB 的组件会做 graceful 的 shutdown。
可以 kill DML 语句。首先使用 show processlist，找到对应 session 的 id，然后执行 kill tidb connection id。
但是，目前不能 kill DDL 语句。DDL 语句一旦开始执行便不能停止，除非出错，出错以后，会停止运行。
- supervise 守护进程
- svc 启停服务
- svstat 查看进程状态
由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制：
- 单条 KV entry 不超过 6MB
- KV entry 的总条数不超过 30w
- KV entry 的总大小不超过 100MB
在 Google 的 Cloud Spanner 上面，也有类似的限制。
解决方案：
- 导入数据的时候，可以分批插入，每批最好不要超过 1w 行。
- 对于
insert和select，可以开启set @@session.tidb_batch_insert=1;隐藏参数，insert会把大事务分批执行。这样不会因为事务太大而超时，但是可能会导致事务原子性的丢失。如果事务执行过程中报错，会导致只完成一部分事务的插入。所以建议只有在需要的时候，在 session 中使用，这样不会影响其他语句。事务完成以后，可以用set @@session.tidb_batch_insert=0关闭。 - 对
delete和update语句，可以使用limit加循环的方式进行操作。
- 可以使用
admin show ddl，语句查看正在运行的 DDL 作业。 admin show ddl jobs，用于查看当前 DDL 作业队列中的所有结果（包括正在运行以及等待运行的任务）以及已执行完成的 DDL 作业队列中的最近十条结果。
- 通过
admin show ddl查看当前添加索引 job；如下:
mysql> admin show ddl;
+------------+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+
| SCHEMA_VER | OWNER | JOB | SELF_ID |
+------------+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+
| 69 | 9deb4179-fb5c-4040-b3b3-2e8fc585d8db | ID:102, Type:add index, State:running, SchemaState:write reorganization, SchemaID:81, TableID:90, RowCount:1293344122, ArgLen:0 | 9deb4179-fb5c-4040-b3b3-2e8fc585d8db |
+------------+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+
- 其中 OWNER 代表了正在执行此 DDL 的 tidb 机器；JOB 列出了任务详细信息
- JOB 中
SchemaID:81, TableID:90为数据库 ID 和用户表 ID - JOB 中
RowCount:1293344122为当前已操作行数
- JOB 中
SHOW DATABASES 是一个全局的权限而不是数据库级的权限，所以授予此项权限时，不能授予某个数据库，而是需要授予所有数据库：grant SHOW DATABASES on *.*。
count(1) 就是暴力扫表，提高并发度能显著的提升速度，修改并发度可以参考 tidb_distsql_scan_concurrency 变量。 但是也要看 CPU 和 I/O 资源。TiDB 每次查询都要访问 TiKV，在数据量小的情况下，MySQL 都在内存里，TiDB 还需要进行一次网络访问。
提升建议：
获取系统时间不要使用 FROM_UNIXTIME，建议采用 datetime 转成时间戳去比较的方式，目前 FROM_UNIXTIME 无法走索引。