【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
因为成本问题 我们tidb选的是单节点。本地磁盘 怕数据丢。需要做备份
第周周六全备份一次，其它按7天增量备份
1 个赞
这数据量只能做到重要表备份
2 个赞
- 考虑低成本–存储费用足够低
- 考虑安全性–存储架构高可用
- 考虑使用性–这种数据量一般是日志类，非核心
传统 全备 和 7天备份几乎 不可能了。 上云吧。oss 存储？？
这体量应该是ap 分析类数据吧，应该上分布式存储，或者对象存储，能节约成本
1 个赞
这种数据量级别的就算有备份恢复起来也是一个灾难级的时间吧，只能长时间一次全备，比如一个月，然后增量了，
2 个赞
~300T BR full backup restore
就算备份了，恢复也很难
1 个赞
没有1000t的这么大的量，最多也就40t左右。一周br整个全备，然后增量备份。备份到s3
你这个单节点不会是tikv的单副本吧？如果是tikv单副本，那还是很容易出问题的，搞备份也不能保证一条数据不丢，毕竟备份搞不到实时。如果只要tidb的单节点影响不大。
不考虑成本，弄一个相同的集群ticdc实时增量备份， 这个体量走全库备份估计没戏，不是容量的问题，是全库备份对主库的消耗问题，尤其是最后的校验部分
2 个赞
估计只能定时全量，平时增量吧。
1 个赞
频繁的做全量备份指定不合适， 全量+增量可以了。 或者用存储技术， 不过那个贵了。
1 个赞
只能降低备份频率，挑重要表备份了。
1 个赞
分库分表分批备份吧
br，限制备份速度的只有带宽和磁盘速度
一个月本分一次全量，中间每天增量，备份很多时候还会影响正常业务，占io跟带宽
重要表备份。GC开大点
没有遇到过这么大量
1、多中心
2、重要表备份
3、这么大量都是热数据么，对冷热数据做拆分
1 个赞
数据量太大了，短期内全量备份不现实，而且备份操作也会影响集群性能。最好定期做全量备份，然后重要表做增量备份，最好存储到分布式文件系统中，本地磁盘风险太大，万一损坏估计数据就嗝屁了。