TiDB定位
重点解决MySQL的单机性能和容量无法线性和灵活拓展的问题,与MySQL形成互补.
优势:
- 协议兼容MySQL
- 可在线拓展:数据通常要有分片,分片要支持分裂和自动迁移,并且迁移过程要尽量对业务无感知.
- 强一致的分布式事务:事务可以跨分片,跨节点执行,并且强一致性.
- 支持二级索引
- 性能方面:MySQL的业务特性,高并发的OLTP性能
- 跨机房服务:需要保证任何一个机房宕机,服务能自动切换
- 跨机房双写:支持跨机房双写是数据库领域的一大难题
业务接入
MySQL的业务接入方式主要有两种
- DNS接入
- Zebra客户端接入
上下游异构数据同步
- Mysql to TiDB
- MySQL到TiDB的迁移,需要解决数据迁移以及增量的实时同步,也就是DTS,Mydumper+Loader解决存量数据的同步,官方提供了DM工具可以很好的解决增量同步问题.
- MySQL大量使用了自增ID作为主题.分库分表Mysql合并到TiDB时，需要解决自增ID冲突的问题．这个通过在TiDB端去掉自增ID建立自己的唯一主键来解决．新版DM也提供了分表合并过程主键自动处理的功能．
典型的问题
- TiKV发生Write Stall TiKV底层有2个RocksDB作为存储.新写的数据写入L0层,当RocksDB的L0层数量达到一定数量时,就会发生减速,更高则发生Stall,用来自我保护. TiKV的默认配置:
- level0-slowdown-writes-trigger = 20
- level0-stop-writes-trigger = 36 出现L0文件过多的原因:
- 写入量大,Compact完不成.
- Snapshot一直创建不完,导致堆积的副本一下释放,RocksDB-Raft创建大量的L0文件 解决方案:
- 减缓 Raft Log Compact 频率（增大 raft-log-gc-size-limit、raft-log-gc-count-limit）
- 加快 Snapshot 速度（整体性能、包括硬件性能）
- max-sub-compactions 调整为 3
- max-background-jobs 调整为 12
- level 0 的 3 个 Trigger 调整为 16、32、64
*Delete大量数据,GC跟不上
现在TiDB的GC对于每个kv-instance是单线程的,当业务删除数据的量非常大时,会导致GC速度较慢,很可能GC的速度跟不上写入. 目前可以通过增多TiKV个数来解决,长期需要靠GC改为多线程执行.
*Insert响应时间越来越慢
业务上线初期，insert 的响应时间 80 线（Duration 80 By Instance）在 20ms 左右，随着运行时间增加，发现响应时间逐步增加到 200ms+。期间排查了多种可能原因，定位在由于 Region 数量快速上涨，Raftstore 里面要做的事情变多了，而它又是单线程工作，每个 Region 定期都要 heartbeat，带来了性能消耗。tikv-raft propose wait duration 指标持续增长。 解决方案:
- 增加Heartbeat的周期
- 需要减少 Region 个数，Merge 掉空 Region，官方在 2.1 版本中已经实现了 Region Merge 功能
- Truncate Table空间无法完全回收
DBA Truncate一张大表后,发现2个现象,一是空间回收较满,二是最终也没有完全回收.
- 由于底层 RocksDB 的机制，很多数据落在 Level 6 上，有可能清不掉。这个需要打开 cdynamic-level-bytes 会优化 Compaction 的策略，提高 Compact 回收空间的速度。
- 由于 Truncate 使用 delete_files_in_range 接口，发给 TiKV 去删 SST 文件，这里只删除不相交的部分，而之前判断是否相交的粒度是 Region，因此导致了大量 SST 无法及时删除掉。
- 考虑 Region 独立 SST 可以解决交叉问题，但是随之带来的是磁盘占用问题和 Split 延时问题。
- 目前最新的 2.1 版本优化为直接使用 DeleteFilesInRange 接口删除整个表占用的空间，然后清理少量残留数据，目前已经解决。
- SQL执行超时后,JDBC报错
业务偶尔报出privilege check fail. 是由于业务在JDBC设置了QueryTimeOut,SQL运行超过这个时间,会执行一个kill query指令,而TiDB执行这个指令需要Super权限,业务是没有权限的. 其实kill自己的query,并不需要额外的权限.在2.0.5之后不再需要soper权限
- 执行计划偶尔不准
关于TiDB的Google论文:
- Spanner:Google's Globally-Distributed Database
- Large-scale Incremental Processing Using Distributed Transactions and Notifications
- In Search of an Understandable Consensus Algorithm
- Online, Asynchronous Schema Change in F1
