TiDB 一些运维笔记

感谢 @凌云Cloud 的贡献

存储限制

  • 单列6M,单行6M(增加默认值会带来性能问题)
  • 一个事务最大支持30w行数据,一行小于6M,整个事务不能大于100M
  • 存储节点kv不易过大,kv单节点不超过2T,即单节点约2w个region(按100M算),超过这个值需要加节点来解决单节点容量过大问题

Split 数据切分

TiDB 底层数据存储是采用 Region 方式存储,Region 可以用 [StartKey,EndKey) 来描述,默认是 96MB,支持用户自定义,官方不建议修改。Region 默认按 RowID 顺序存放。用户不用关心数据库、表底层如何存储,TiDB 会根据 Region 大小自动 Split 生成新的Region。前期用着很香。。。

问题:

  • 热点问题,安装 MySQL 建表习惯采用自增ID,就会造成数据一直写入最新的 Region,从而导致写入热点,耗时增加。
  • Region Split 高频会影响集群性能。

分区表问题

TiDB分区表使用限制比较多,对于数据量比较大的应用,特别是有归档需求的场景,TiDB分区表就不太适合,例如稳定性要求很高的金融场景。

  • 分区表的每个唯一键,必须包含分区表达式中用到所有列
  • 分区裁减目前不稳定,其功能还是实验特性
  • 不能使用 Plan Cache
  • 不能使用 IndexJoin 的执行方式
  • 不支持全局索引
  • 不能修改SQL mode

https://docs.pingcap.com/zh/tidb/stable/basic-features/#分区

备份问题

  • TiDB 的备份在4.x之前都是使用mydumper/mysqldumper来进行备份,全完是逻辑备份,对于大表很难备份出来,同时需要调整足够长的gc lifetime才能完成,对于达到20~30亿(700G以上)的大表这个时间需要设置很长(超过12h)
ps:gc lifetime 与mvcc相关联,过长会影响集群性能
  • 4.x后使用dumping,BR,dumping 可以有根据需要动态修改gc 时间,但是对于DB来说不可控,对于大集群TiDB引入了BR,BR严格意义上来说是逻辑的,在备份时候性能会下降15%至30%
  • 增量备份问题,由正常情况下生不环境gc时间不会设置太长,而增量备份需要在上一次GC safepoint 之前,生产环境一般很难满足
  • TiDB的日志组件是独立的,备份不能同时备份增量日志

binglog管理问题

  • pump:日志管理组件pump是相互独立的,默认情况下生产需要部署多个pump以防事务写失败,所有pump的加总才是一个完全的事务日志,如果其中一个pump节点的日志没有消费完,则会导致丢数据。
  • pump与drainer的运维管理工具缺限,如下线的节点,很难从集群中删除,易给运维管理人员带来困惑。

内存 OOM

  • TiDB Server 执行全表扫、慢查会导致内存疯长,目前没有明确参数可控制。
  • 单机部署 TiKV 双实例,需控制单个实例内存,不然容易OOM。

监控问题

对于个集群的监控是相互独立的,如果有多个集群时不能集中管理,主要体现在以下方面

  • 数据:每个集群对应一个promethus ,多个集群时相应的监控数据不能集中管理,
  • 界面显示:统一的在一个界面上显示,需要做变相的处理,手动把不同集群的数据源与显示界面添加到grafana中去

无自动备份恢复,TiDB监控界面不能对备份恢复做自动化管理,还需要DBA在运维中单独处理

2 Likes