嗯嗯好嘞～
期待PITR GA
早日GA!!!
干巴得～
我已经测试过两轮了，每次都是一样的现象，先不测试了吧，坐等GA!
谢谢大佬指点～
这个另外一种模式，BR + CDC 会是不同的体验
TiCDC是灾备。。。目前我们没有考虑这个哦。。。
另外，BR+TiCDC怎么玩的呀？
看官网的介绍，TiCDC只能同步到集群，一旦开启，应该是时间线一直往前走的，这样的话，如何结合BR来做恢复呢？求指点，哈哈～
如果能够实现预期，也未尝不可一试 
TiCDC 只支持增量，不支持全量
BR 增强不建议在生产环境使用，默认是支持全量的
加起来就是支持 全量 + 增量了
如果有两套集群，可以作为逃生窗口，直接切换，这样也是一种方案
目前较为稳妥的也是这种了
TiCDC支持增量，但是已写入备集群的且和全量重叠的数据，在恢复的时候不会有问题吗？
这个看策略怎么定的了，全量是冷备了，CDC是热备，不一样的
对，但是感觉这个跟策略没有关系，我觉得灾备都不需要BR了，一直开着CDC就行了，对吧？
策略怎么做都规避不了的一个问题就是BR的冷备和CDC的热备数据重复的问题，我是这么理解的哈，不知道是不是有问题？可能有我没理解到的点。 
BR 备份是需要选择某个时间点的，但是业务不会停，所以数据还会有变化，这个时候 CDC 可以记录这些变化
BR的全量不需要指定时间点吧，只有BR的增量才需要指定时间点吧？全量都是后面的会覆盖前面的。
而且之前测试的时候发现，库表已存在的情况下，BR的全量恢复还会报错，必须要删除库表才能执行全量恢复，忘记是只要删除表还是库表都要删了。
BR 全量需要指定的（快照模式），即使不指定，也默认是当前时间
但是时间不会停下来，对吧
BR 恢复操作要按照官方文档的指引来操作了…
嗯对的，我测试的时候默认的应该是当前时间。对，时间不会停下来。
所以，我理解一下你的意思哈，两次BR全量备份之间的新数据由CDC来备份到下游，是这样吗？如果是这样，备份确实是没问题，但是第二次BR全量备份的数据是会覆盖中间这次CDC备份的增量数据的，而且这些数据已经通过CDC同步到下游备集群了，这样的话还是出现数据重复的问题了。
不知道我理解的对不对哈？
我个人认为，除非CDC+BR能够在恢复的时候自动处理掉这些冲突实现数据的完整性和可靠性，不然恢复的时候还是会存在问题的。但是又有一个矛盾点，我都能做到热备了，我干嘛还要多此一举加个冷备呢？我一直开着热备不就好了嘛… 
冷备是为了以防万一，如果整个机房挂了呢？
短时间不能恢复，但是冷备的数据可以到另外的机房去恢复了
备份和恢复，就是一个策略的选择，至于恢复是否重复，就是选了个错误的方式恢复嘛