【 TiDB 使用环境】
【概述】：场景 + 问题概述
【背景】：做过哪些操作
【现象】：业务和数据库现象
【问题】：mysql数据大小有100gb，迁移到tidb后只有50gb，默认三副本，这个情况正常吗？
【业务影响】：
【TiDB 版本】：5.3
【附件】：
- 相关日志
- 配置文件
- Grafana 监控（https://metricstool.pingcap.com/)
1 个赞
你这50G是从哪看的
mysql的100G是一个主库的吗，包括binlog不，tidb的50G是多个节点加起来的总和吗，另外你看下mysql的表碎片多不多。
100gb是表的大小，不包含日志，tidb方向是5个节点加上一共占用50gb
哦，好的
我再补充一个每层数据的默认压缩配置，看看能不能帮上：
compression-per-level
- 每一层默认压缩算法。
-
defaultcf的默认值：[“no”, “no”, “lz4”, “lz4”, “lz4”, “zstd”, “zstd”] -
writecf的默认值：[“no”, “no”, “lz4”, “lz4”, “lz4”, “zstd”, “zstd”] -
lockcf的默认值：[“no”, “no”, “no”, “no”, “no”, “no”, “no”]
2 个赞
兄台这篇文章能发个链接嘛
底层的rocksdb是有压缩机制的
MySQL 100gb也不包含索引吧？TiDB三副本50gb，每个kv大概16.7gb，压缩率很高了
其实我在想这100g是怎么算出来的，如果是根据information_schema.tables算出来的，那有可能不准，如果是根据表空间文件.ibd 算出来也有可能不准，tidb这么高的压缩率第一次见
谢谢大佬
这个是怎么算出来的？ 假如MySQL MGR是3节点，比如说1T数据，按3节点计算，一共是3T数据，那么是否是在TiDB中是3个副本一共是1.11T数据，这个时候存储成本就是mysql 37%了？ 有没有具体的数值啊？
tidb是有压缩机制的。如果不放心可以检查一下数据的正确性
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。