对于这个问题我有一个新的想法，就是 逻辑备份+ ticdc to cos。
我们首先基于时间点进行逻辑备份，然后在做 ticdc to cos 的增量。不过得对这个文件自己解析来做数据的增删改。
这样我们就可以只专注于核心的表进行备份。
已经超出我的认知了，谢谢
备份的话这么大数据，主要是要花钱，买好的存储设备就行
单副本出问题是迟早的事情
确实如此，全量备一次或全量恢复太费时间了
全量…增量
开眼了，数据量那么大。分库降低主库备份量，不总是访问的数据归档到历史库。
我司的思路是，两地三中心：
1 本地建设生产集群800TB，部署双活服务，或者HA。
2 同城远距离建设60%规模的备份集群，建设灾难级的切换机制，数据铺底后，每日增量同步。重点保证核心数据表的数据一致。
题外话：数据同步备份是一部分，如何及时的切换更为棘手，平时的应急演练也要多做多总结
时间长了肯定会有的
核心是资本投入，技术是次要的
虽然没遇到这么大的库，但分布式数据库的大库备份确实是没啥特别好的可行性方案。
有点大，不是太好备份
不归档吗
做双集群，cdc实时增量吧
容灾规划吧
这么大的量，出了问题靠备份来恢复，效率太低了。
上双集群，主备实时复制，主库出了问题备库顶上去。
1 个赞
- 主从
- 增量
- 只备份关键数据