TiDB集群副本调整(由三副本调整为一副本)

【 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个副本

好的,我试试。找到一个资料,说最终的备份的大小等于数据大小。我测试下。

备份与恢复常见问题 | PingCAP 文档中心

备份数据有多大,备份会有副本吗?

备份的时候仅仅在每个 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多点。
image

1 个赞