一、硬件选型
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 机器）上软件版本满足条件即可
中控机：
ansible --version
ansible 2.5.0
pip -V
pip 8.1.2
pip show jinja2
Metadata-Version: 2.0
Name: Jinja2
Version: 2.10
pip show jmespath
Metadata-Version: 2.0
Name: jmespath
Version: 0.9.3
监控机（grafana）：
rpm -qa | grep fontconfig
fontconfig-2.10.95-11.el7.x86_64
rpm -qa | grep open-sans-fonts
open-sans-fonts-1.10-1.el7.noarch
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:3000admin/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。
