TiDB 基础 *** 作集

1、测试环境推荐配置

2、生产环境推荐配置

3、 如果 tikv 服务器的 CPU及磁盘配置较高，可以考虑多实例部署，按照每个 tikv 实例16~20core + 64G 内存 + 800G 磁盘的比例分配硬件资源。

同时需要注意 inventory.ini 及 ansible/conf/tikv.yml 的相关配置。

4、tidb 服务器视业务类型，如果业务逻辑有偏 AP 类的 SQL，需要考虑配置大内存，防止出现 OOM。

如果是纯 TP 类业务，tidb 服务器 CPU 配置较高的话，也可以考虑多实例部署，每个 tidb-server 分配20~32core，可以避免无谓的CPU上下文切换， 减少 system cpu 消耗。

5、pd 服务器的磁盘可以配置200~500G 的SSD 盘，主要用来保存源数据信息。在集群规模较大，源数据信息较多的时候，SSD 磁盘能够避免源数据信息存取成为集群的瓶颈点。

1、 *** 作系统版本要求

建议 centos 7.3及以上，支持 redhat 7.3版本及以上，不推荐其他版本的系统。

2、ansible、jinja 等软件依赖包版本，只需要验证中控机（运行ansible 机器）上软件版本满足条件即可

中控机：

监控机（grafana）：

3、测试环境磁盘 IO 不满足需求

ansible-playbook bootstrap.yml --extra-vars "dev_mode=True"

加上 dev_mode=True 可以在部署时，绕过系统磁盘相关的 benchmark

4、关闭防火墙、开启时钟同步

systemctl status firewalld

systemctl status chronyd/ntpd

5、集群下所有服务器要配置不同的 hostname

如果否，可以编辑 inventory.ini 的配置项 set_hostname=True 来自动修改 hostname

6、调整参数

参数在 ansible/conf/目录下，tidb.yml，tikv.yml，常见的可能需要调整的参数

tidb.yml：

grpc-connection-count: 如果服务器 CPU 配置较高，tikv 实例个数较多，该参数可以调整至20~32之间

slow-threshold：slow-query 记录的阈值，默认300ms

level：日志级别，默认 info，可以视情况调整为 debug 或 error

tikv.yml：

sync-log：raft-log sync配置，默认值true，对于磁盘 io 消耗较高，测试/非金融生产环境建议设置为 false

region-split-check-diff：检测 region 分裂的阈值，非 SSD 磁盘建议调大至32MB

rocksdb defaultcf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 30%（多实例部署下配置，单实例部署不需要修改）

rocksdb writecf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 45%（多实例部署下配置，单实例部署不需要修改）

rocksdb lockcf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 2.5% (最小 128 MB)（多实例部署下配置，单实例部署不需要修改）

raftdb defaultcf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 2.5% (最小 128 MB)（多实例部署下配置，单实例部署不需要修改）

多实例情况下，需要修改 

readpool:

  coprocessor:

  high-concurrency

  normal-concurrency

  low-concurrency

三个参数，推荐为实例数*参数值 = CPU 核数 * 0.8。

 raftstore:

   capacity

 磁盘总容量 / TiKV 实例数量，例如 “100GB”

修改完后，可以使用下面命令验证

cat tidb-ansible/conf/tikv.yml |grep -Ev "^$|#"

无误后执行 

ansible-playbook rolling_update.yml --tags=tidb/tikv

滚动升级，tags 可选

7、官网有比较完善的在线+离线部署方案、在线升级指导、在线扩容缩容文档，具体参考：

https://pingcap.com/docs-cn/op-guide/ansible-deployment/

https://pingcap.com/docs-cn/op-guide/offline-ansible-deployment/

https://pingcap.com/docs-cn/op-guide/ansible-deployment-scale/

1、从 MySQL 迁移

TiDB 兼容 MySQL 语法，小数据量建议直接使用 mysqldump、mydumper 来全量导出数据，再通过 source、myloader 的方式导入 TiDB。

./bin/mydumper -h 127.0.0.1 -P 3306 -u root -t 16 -F 64 -B test -T t1,t2 --skip-tz-utc -o ./var/test

./bin/loader -h 127.0.0.1 -u root -P 4000 -t 32 -d ./var/test

详情请参考： https://pingcap.com/docs-cn/op-guide/migration/#使用-mydumper-loader-全量导入数据

如果数据量较大，超过几百 G，可以联系原厂申请试用 lightning 工具，loader 导入数据平均速度是20G/小时，lightning 约为100~150G/小时

2、从 Oracle 迁移

目前有几种方式可以参考

使用 OGG 做全量+增量同步

使用 Navicat Premium 版的 data transfer 功能，支持从 Oracle/SqlServer 迁移全量数据至 TiDB

通过 kafka 等消息队列工具，解析 OGG 的日志，开发写入 TiDB/MySQL 的工具

目前我们也在积极跟专业的数据异构平台合作，争取能够尽快在更多的数据迁移工具中兼容 TiDB 数据源。

1、启动集群

ansible-playbook start.yml --tags=tidb/tikv/pd

在正确的 ansible 目录下，确保 inventory.ini 里的配置正确，tags 可选

2、停止集群

ansible-playbook stop.yml --tags=tidb/tikv/pd

在正确的 ansible 目录下，确保 inventory.ini 里的配置正确，tags 可选

3、停止单个 tidb-server / tikv-server

ansible-playbook stop.yml --tags=tidb/tikv/pd -l IP

-l 后面接 inventory.ini 配置的IP 或别名

4、访问 tidb

TiDB 兼容 MySQL 协议，所有连接 MySQL 的方式都适用于TiDB

mysql -uroot -h127.0.0.1 -P4000 -p

常见的图形化界面工具，navicat 等都可以直接访问 tidb

同时也支持jdbc、odbc 等，需要注意的是 mysql 8.0版本的客户端，及 mariadb 客户端可能存在兼容性问题，不建议使用

SQL 语法基本兼容 MySQL，某些不兼容的场景见： https://pingcap.com/docs-cn/sql/mysql-compatibility/#与-mysql-兼容性对比

5、修改参数

可以通过修改 tidb-ansible/conf/tidb.yml 配置文件，然后执行

ansible-playbook rolling_update.yml --tags=tidb/tikv

也可以直接登录服务器，找到deploy_dir/conf/tidb.toml，直接编辑文件，然后 pkill tidb-server 来重启服务

6、查看 tidb 版本信息

select tidb_version()

Release Version: v2.1.0-rc.3-24-g23f90a6

Git Commit Hash: 23f90a68be321e724280da6033a2b63ebf6cc7dd

Git Branch: HEAD

UTC Build Time: 2018-10-10 09:18:39

GoVersion: go version go1.11 linux/amd64

Race Enabled: false

TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e

Check Table Before Drop: false

7、备份 tidb 数据

全量备份可以采用 mydumper，增量备份需要开启 binlog，实时恢复采用商业版工具 reparo。

8、查看监控数据

在 ansible 的配置文件 inventory.ini 里，有一个监控服务器的配置

[monitoring_servers]

10.1.163.87

deploy 的时候会默认在这个配置服务器上部署 grafana 组件，通过

http://10.1.163.87:3000 admin/admin  访问

具体一些常见的监控指标，请参考： https://pingcap.com/docs-cn/op-guide/dashboard-overview-info/

9、收集统计信息

set @@tidb_build_stats_concurrency=20

set @@tidb_distsql_scan_concurrency=100

set @@tidb_index_serial_scan_concurrency=20

analyze table xxx index xxx

修改上面三个参数可以提升 scan 效率。

具体统计信息相关，请参考： https://pingcap.com/docs-cn/sql/statistics/#统计信息简介

1、Transaction too large

TiDB 对于事务有限制，简单来说以下几点：

单个事务的SQL 语句数量不能超过5000，（ 在 tidb.yml 可配 stmt-count-limit ）

单条 KV entry 不超过 6MB

KV entry 的总条数不超过 30w

KV entry 的总大小不超过 100MB

备注：假设某张表有4个索引，那么一条数据对应的 kv entry 为数据+索引，一共5个kv 记录。

如果是批量 insert 或delete，建议先修改

set tidb_batch_insert = 1 

set tidb_batch_delete = 1

update mysql.tidb set variable_value='24h' where variable_name='tikv_gc_life_time'

再执行 SQL。

如果是批量 update，建议采用 limit 循环的方式执行。

2、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'

3、Lost connection to MySQL server during query

log 中是否有 panic

dmesg 中是否有 oom，命令： dmesg -T | grep -i oom

长时间没有访问，也会收到这个报错，一般是 tcp 超时导致的，tcp 长时间不用, 会被 *** 作系统 kill。

案例1[问题澄清] TiDB集群启动过程中报错： [FATAL] [main.go:111] [“run server failed”] [error=“listen tcp 192.xxx.73.101:2380: bind: cannot assign requested address”]            [原因分析]             网络问题             [解决方案] 1.使用ping命令检查ip是否可以访问 2.使用telnel命令测试端口是否可以访问 3.在tidb集群中尽量避免内网和外网ip混用 [参考案例] PD端口无法启动https://asktug.com/t/pd/638[引申学习点] ping命令https://blog.csdn.net/hebbely/article/details/54965989telnet命令https://blog.csdn.net/swazer_z/article/details/64442730案例2 [问题澄清] PD启动过程中报错： [PANIC] [server.go:446] [“failed to recover v3 backend from snapshot”] [error=“failed to find database snapshot file (snap: snapshot file doesn’t exist)”] [原因分析] 服务器掉电，导致 *** 作系统数据丢失 [解决方案] 1. 掉电后可能目录变为只读，请运维人员帮助从 *** 作系统层面恢复只读文件 2. 如果TiDB集群有PD节点无法启动，建议使用pd-recover命令恢复https://pingcap.com/docs-cn/stable/reference/tools/pd-recover/#pd-recover-%25E4%25BD%25BF%25E7%2594%25A8%25E6%2596%2587%25E6%25A1%25A3[参考案例]系统断电，来电后重启tidb集群，启动PD节点报错，3个PD节点有两个报错 https://asktug.com/t/tidb-pd-3-pd/1369[学习引申点] EXT4文件系统学习（五）掉电数据损坏重启挂载失败并修复，仅限参考非标准步骤，fsck失败可能导致数据损坏https://blog.csdn.net/TSZ0000/article/details/84664865案例3 [问题澄清] TiKV启动过程中报错： ERRO tikv-server.rs:155: failed to create kv engine: “Corruption: Sst file size mismatch: /data/tidb/deploy/data/db/67704904.sst. Size recorded in manifest 325143, actual size 0 ”] [原因分析] 服务器重启，导致数据未及时sync [解决方案] 下线节点，重新扩容，参考扩容缩容步骤https://pingcap.com/docs-cn/stable/how-to/scale/with-ansible/会在某个新版本修复此问题   https://github.com/tikv/tikv/pull/4807[参考案例]TiKV节点无法启动 https://asktug.com/t/tikv/1375[学习引申点] RocksDB - MANIFESThttps://www.jianshu.com/p/d1b38ce0d966案例4 [问题澄清] TiKV启动过程中报错： ERRO panic_hook.rs:104: thread ‘raftstore-11’ panicked ‘[region 125868]323807 to_commit 181879 is out of range [last_index 181878]’ at "/home/jenkins/.cargo/git/checkouts/raft-rs-841f8a6db665c5c0/b10d74c/src/raft_log.rs:248"3.2019/04/30 18:11:27.625 ERRO panic_hook.rs:104: thread ‘raftstore-11’ panicked ‘[region 125868]323807 to_commit 181879 is out of range [last_index 181878]’ at “/home/jenkins/.cargo/git/checkouts/raft-rs-841f8a6db665c5c0/b10d74c/src/raft_log.rs:248” stack backtrace:stack backtrace: [原因分析] to_commit out of range 意味着这个 peer 想要 commit 一条不存在的日志，说明因某些主动 *** 作或者异常情况发生导致最近的 raft log 丢失了 [解决方案] 1.通过 tikv-ctl 工具定位损坏的region，指定 db 目录（当前损坏 tikv 节点的目录）。 2.通过 tikv-ctl 进行数据修复。 2.1 如果修复失败。如下： set_region_tombstone: StringError("The peer is still in target peers") 使用tikv-ctl 执行 region tombstone 需要对损坏节点 region peer 进行判断，需要人工清理。remove 掉异常的 peer。 2.2 重复使用 tikv-ctl 工具执行修复即可。 [参考案例]TiKV 报错 ERRO panic_hook.rs:104 是什么原因 https://asktug.com/t/tikv-erro-panic-hook-rs-104/165 Tikv节点挂掉后，启动报错“[region 32] 33 to_commit 405937 is out of range [last_index 405933]” https://asktug.com/t/tikv-region-32-33-to-commit-405937-is-out-of-range-last-index-405933/1922[学习引申点] Raft 日志复制 Log replicationhttps://www.jianshu.com/p/b28e73eefa88案例5 [问题澄清] PD启动过程中报错： FAILED - RETRYING: wait until the PD health page is available (12 retries left). FAILED - RETRYING: wait until the PD health page is available (12 retries left) [原因分析] ip地址异常 [解决方案] 1.检查是否有内外网ip导致不通 2.是否是更换PD ip地址导致，可以采用扩容缩容的方法处理PD. [参考案例]节点IP变化后，如何 *** 作更新 https://asktug.com/t/ip/1106 TiDB集群启动不起来 https://asktug.com/t/tidb/1563[学习引申点]TiDB 最佳实践系列（二）PD 调度策略最佳实践https://pingcap.com/blog-cn/best-practice-pd/案例6 [问题澄清] TiDB无法启动, tidb_stderr.log 报错： fatal error: runtime: out of memory [原因分析] 设置 echo 2 >/proc/sys/vm/overcommit_memory [解决方案] 设置echo 0 >/proc/sys/vm/overcommit_memory [参考案例]修改内存使用策略导致 TiDB自动下线后 无法启动 https://asktug.com/t/tidb/1716[学习引申点]linux下overcommit_memory的问题https://blog.csdn.net/houjixin/article/details/46412557案例7 [问题澄清] TiDB集群启动过程中报错： Ansible FAILED! =>playbook: start.ymlTASK: Check grafana API Key listmessage: {“changed”: false, “connection”: “close”, “content”: “{“message”:“Invalid username or password”}”, “content_length”: “42”, “content_type”: “application/jsoncharset=UTF-8”, “date”: “Wed, 25 Dec 2019 02:22:44 GMT”, “json”: {“message”: “Invalid username or password”}, “msg”: “Status code was 401 and not [200]: HTTP Error 401: Unauthorized”, “redirected”: false, “status”: 401, “url”: “ http://192.168.179.112:3000/api/auth/keys ”} [原因分析] 修改过 Grafana 的密码 [解决方案] inventory.ini 中配置的用户名和密码也需要修改为新的密码 [参考案例]启动集tidb集群出现错误 https://asktug.com/t/topic/2253[学习引申点]Grafana全面瓦解https://www.jianshu.com/p/7e7e0d06709b案例8 [问题澄清] TiDB集群启动过程中TiDB日志报错： [error="[global:3]critical error write binlog failed, the last error no avaliable pump to write binlog"] [原因分析] pump与Draine造成的 [解决方案] pump错误为：fail to notify all living drainer: notify drainer。将drainer启动，然后成功下线后，start.yml执行成功 [参考案例]tidb服务已经启动了，但是wait until the TiDB port is up失败 https://asktug.com/t/topic/2606[学习引申点]TiDB Binlog 简介https://pingcap.com/docs-cn/stable/reference/tidb-binlog/overview/

相比于 Intel 的 x86-64 架构，ARM 架构虽然作为后来者，但在服务器领域也开始在不停地攻城拔寨，很多企业也开始将自己的服务迁移到 ARM 架构上面，自然，对于 TiDB 来说，大家也想将 TiDB 运行到 ARM 上面。因为 AWS 上面直接提供了 ARM 机型，所以我们决定先尝试在 AWS 的 ARM 上面编译运行 TiDB。

TiDB 主要包含三个组件 - PD，TiKV 和 TiDB，对于 PD 和 TiDB 来说，使用的是 Go 进行编译的，所以我们只需要在 ARM 机器上面装好 Go 的版本就可以了。这里，我使用的是 go1.12.6.linux-arm64 这个版本。

用 Go 编译 TiDB 和 PD 比较容易，中途遇到了一个 TiDB 的编译问题，只需要升级下 vendor 就解决了。

编译 TiKV 就比较麻烦了，因为我们使用的是 CentOS 系统，系统用 yum 就能安装相关的依赖，除了 cmake3 ，装 cmake 需要做如下处理：

当然，编译 RocksDB 还有 Titan 的时候还遇到了一些错误，不过多数就是传递编译参数的时候需要处理下 ARM64 相关的选项，并不是特别的困难。

总的来说，编译并没有花太多的时间，这里有一个 脚本 ，大家可以自行去看如何在 ARM64 上面编译 TiDB。对于运行集群需要的 Grafana 和 Prometheus，官方都提供了 ARM64 版本，大家可以直接去 Google。

编译好了 ARM64 的版本，自然就是测试了，这里我使用了 go-ycsb 进行了简单的测试，这里我使用的是 16c32g 的 ARM64 机器，顺带也开了一台同配置的 x86 作为对比。

在每台测试机器上面，启动一个 PD，一个 TiKV，使用的是默认配置，然后 go-ycsb 使用 100 并发，导入 1 百万数据， *** 作次数 1 百万，batch size 为 0。

结果如下：

可以看到，ARM 的机器性能比 x86 的差了很多，需要来优化了。在网上找了这篇 文章 ，使用了上面的脚本，但发现没有什么变化。在这个脚本里面，主要的优化就是将网卡中断的处理绑定到某一个 CPU 上面，然后将 RPS 分散到不同的 CPU。对于 16c32g 的机器来说，这个脚本将网卡中断的处理绑定到 CPU core 0 和 8 上面，然后把 RPS 分散到所有的 CPU 上面，但是我通过 mpstat 发现，core 0 和 8 几乎被打满：

于是我重新调了下，将 RPS 分散到除开 core 0 和 8 的地方：

然后 OPS 稍微提升了一点，但 CPU core 0 和 8 仍然是瓶颈。而这个瓶颈明显是网络处理造成的，直观的优化就是减少网络消息的处理，于是将 batch size 设为 128，可以发现在 ARM 上面性能提升很多，譬如对于 workload C，OPS 能提升到 118270。但即使这样，CPU core 0 和 8 还是会成为瓶颈。

对比 ARM，x86 下面 CPU 的分配明显的均匀很多：

所以后面我们要考虑的事情就是如何让 ARM 能更好的处理网络消息。

上面简单的说了一下如何在 ARM 上面编译运行 TiDB，以及一些调优策略。个人认为，虽然 ARM 在性能上面还赶不上相同配置的 x86，但低功耗，成本这些是一个非常大的优势，加上很多不可说的原因，个人认为会有越来越多的企业使用 ARM，所以这块也会是趋势。

---