【 TiDB 使用环境】测试
【 TiDB 版本】v7.5
【复现路径】
【遇到的问题：问题现象及影响】历史存量的数据大概有2个PB，需要以月份为单位把数据导入TiDB，然后备份入磁带库。按集群默认配置时3副本（目标TiKV的集群的总存储空间必须大于（数据源大小 乘 副本数量 乘 2），这样最后的容量是（2乘3乘2=12PB）。太大了，能否设置成1个副本，总体规划成（2 乘 1 乘 1.2=2.4PB）的容量。可否实现？有什么影响吗？
请问是打算是用来做冷数据归档存储吗
对的，可以这样认为
修改方式：
set config pd replication.max-replicas=1;
查看;
show config where NAME like ‘%max-replicas%’;
建议搭建个测试环境试试，我单机跑有时候用没发现问题，设置1就自动调整为1个副本
1 个赞
好的，我试试。找到一个资料，说最终的备份的大小等于数据大小。我测试下。
备份数据有多大，备份会有副本吗？
备份的时候仅仅在每个 Region 的 Leader 处生成该 Region 的备份文件。因此备份的大小等于数据大小，不会有多余的副本数据。所以最终的总大小大约是 TiKV 数据总量除以副本数。
但是假如想要从本地恢复数据，因为每个 TiKV 都必须要能访问到所有备份文件，在最终恢复的时候会有等同于恢复时 TiKV 节点数量的副本。
这个是物理备份，你要备份到磁带我觉得还是平面文件（csv）好点吧。用dumpling逻辑备份，导出为csv格式，历史数据可以加where条件
tikv有压缩，默认3副本也要不了12P那么大的空间，估计也就3-4P吧。
如果非要用单副本就按楼上那种方式改就行，但是单副本会不会遇到啥奇怪问题不好说
1 个赞
你设置为单副本存储，虽然技术上可行，但是无法保证高可用的。
有没有想过，如果一台机器宕机了，无法恢复，丢失了数据，这个后果该如何应对？业务上是怎么考虑的
你的数据2PB空间是磁盘文件大小吗？
我们之前从MySQL迁移过来，tidb 即使是3副本，最终的数据占据的磁盘空间也只是mysql 的70%，还节省了空间。
压缩算法会和具体的数据结构、数据分布、稀疏情况等有关，建议你用真实的数据去测一测，验证一下才能分析最后可能占据的总空间。
这么大的数据量，建议从长计议，一切判断要根据实际环境验证的测试结果为准
2 个赞
根据压缩算法，不会占用那么多存储空间，建议导一部分数据，再计算评估一下
我看了下资料，dumpling不适合大数据量导出
你的上游数据库是什么？应该会有对应的数据传输工具可以使用的，优先去确认有无物理导出工具，因为这类工具往往效率高，适合超大规模数据的搬迁工作
1副本可能会碰到奇怪问题，建议还是3副本，3副本的情况，2P数据应该有3P磁盘差不多，可以先来一个月数据试试
如果上游是mysql的话，2PB，存到tidb3副本大小一般最多也就3-4PB，没有3倍那么多，tidb底层存储不一样，而且对数据有压缩。如果只用1副本的话，任意坏一个节点，你数据库直接废掉了，不建议这么用。
风险比较大，建议考虑其它方案
是不太适合一次导出太多，不过你都是历史数据，可以分批次导出， dumpling能加where条件
冷数据归档，搞个cdc同步到mysql多好
生产系统不建议在线切换副本数 建议搞个冷数据备份释放空间
楼主测试情况如何？
数据是本身就在tidb里面吗，如果不是，数据导入tidb，他会自动压缩的。压缩比例大概是3:1 ，这是我生产的表大小，如果你的是2PB，压缩后变成3副本，可能也是2PB多点。
1 个赞