TiDB 一些运维笔记

🌌 运维指南 TiDB 运维手册
1

感谢 @凌云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 个赞