【产品名称】oblogrpxy
【产品版本】未发布的版本
【问题描述】oblogproxy 全量/增量备份中的日志位点是哪种？
2.1增量备份订阅工具canal中使用了oblogclient，订阅数据时需要传一个startTimestamp,是否是时间戳，还是clog的位点？
2.2 如果是时间戳,如何避免日志不准确(同-时间多个日志)
2.3保证全局一致性的物理备份/恢复的原理，是否也是基于timestamp的？如何获取到全量备份后，下一个增量日志开始的timestamp？
对于问题1/2：收到的心跳消息中的位点可以理解为当前同步范围内所有分区输出的最小位点（提交时间戳）（因此断点续传场景下是由重复数据的）
对于物理备份恢复，内部维护各分区的位点信息，用户不用感知
你好，那我想问，要做两个OB集群的同步问题，我先使用备份恢复工具，将A集群的OB进行备份，在恢复到B集群，这种时候，我在使用增量实时同步，怎么获取到那个增量同步的开始时间点startTimestamp来保障数据不丢失？
用的是那种备份恢复工具呢？物理备份恢复是容灾手段，是出现故障时将集群数据恢复到一个历史点，然后继续提供服务，历史位点和恢复完成前之间的数据是损失的。如果想要实时备份，可以用主备库，也可以自己用CDC组件做逻辑同步（全量+增量，此时增量要使用的应该是全量开始时的时间点并向前推一段时间，比如全量从10点开始做，全量完成后从9点开始做增量同步）
现在是想通过3.1.1版本发布的备份/恢复做一次全量同步，然后使用oblogproxy+Canal 做增量同步到另一个OB集群。
这个方案可行性如何？
目前就是那个增量同步的起始点不好确认，时间点太前会出现重复数据。
理论上可以先启动liboblog链接要恢复到的集群，启动时保证要恢复出来的租户在白名单中，启动liboblog后执行恢复操作。
这个需求建议这样实现：
+ 使用 oblogproxy 启动ob的增量日志收集。
+ 使用 datax 开始在ob a 集群和 ob b 集群做数据全量同步。
+ 等全量同步结束后，启动 canal 在ob b 集群应用增量。期间忽略 insert 主键或者唯一键冲突。