br的官方文档里提供恢复单表的例子，但没有说怎么运用binlog日志做按时间点的恢复。假如我是前一天备份的，那恢复的时候是不是就丢了一天的数据了？我想知道有什么工具去消费tidb 的binlog，或者tidb不是用的binlog来做恢复的？
可以参考一下 这个https://docs.pingcap.com/zh/tidb/stable/tidb-binlog-reparo#reparo-%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3 增量恢复binlog
全量备份与全量恢复：BR 或 dumpling
增量备份：drainer 的 file 模式输出（tidb-binlog）
增量恢复：reparo
全量增量对接时间戳在 BR 和 dumpling 的备份目录中的 meta 文件上都有记录
只有这种方式了吗，那我还要为此装dumpling和drainer ，按照官方建议，dumpling要3个节点，drainer要一个节点，还是有点耗资源啊！
dumpling 是类似 mydumper 的逻辑备份工具。你是说 pump 需要 3 个节点吧？目前是这样的，等待后续版本 BR 实现了增量文件备份功能，整个 pitr 功能就只由 BR 一个工具来覆盖了。
还想追问一下，我现在的目的是像mysql那样生成binlog到时候用于恢复的。但是tidb看起来是要装pump(采集数据)，drainer(解析数据)，pump和drainer都会记录一份binlog，然后reparo运用drainer解析后的数据进行恢复，所以不能只装pump。drainer还需要指定下游的dest_type，但是我也不需要指定，所以又不需要drainer，这个怎么解？
可以延长gc时间 开启闪回功能flashback 官方有教程。哪个恢复数据很简单。也不用工具
目前增量文件备份就是采用 drainer 的 file 输出模式，也就是 db-type = file
我担心到时候整个集群挂掉，然后执行不了命令的这种情况
binlog是最后保底的办法
你这个担心是多余的 分布式不存在单点挂掉的情况。第二 如果突然断电你们机器都断。也不会出问题。当然机房的ups得放上去
理论上确实如你所言，但是我总觉得用binlog心里有底，万一flashback的方式被gc掉了，或者很长时间才发现一张表不见了咋办。那方便问下你们生产环境是用flashback+br（或dumpling）的方式吗，没开启binlog吗？
我们业务的update场景多，项目上线初期，tidb_gc_life_time目前我设置了48h，没敢设置太长时间。
现在做到时间点恢复好像不支持吧
那业界tidb的备份方式是怎样的呢，有没有大兄弟可以指教下，真就不开binlog吗，要开吧？
不用怕tidb挂掉 不可能的
tidb可以被压死但从来不会出问题
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。