一、硬件选型
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、官网有比较完善的在线+离线部署方案、在线升级指导、在线扩容缩容文档,具体参考:
三、数据迁移
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
如果数据量较大,超过几百 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 客户端可能存在兼容性问题,不建议使用
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 组件,通过
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 效率。
五、常见问题
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。