共计 2306 个字符，预计需要花费 6 分钟才能阅读完成。
本文介绍了 TiDB 数据库的基于工夫点的复原（PiTR）个性，该个性容许用户将数据库复原到特定工夫点，从而防止失落重要数据。文章首先介绍了 PiTR 技术的基本概念和工作原理，接着探讨了 TiDB 对 PiTR 的优化，包含 PiTR 的技术指标，稳定性和性能晋升。最初，文章瞻望了 TiDB PiTR 将来的改良方向，将继续摸索备份复原的更多可能性。
基于工夫点复原（PiTR）技术介绍
对于数据库产品而言，基于工夫点的复原是十分重要的根底能力，它容许用户依据须要，将数据库复原到特定工夫点，以帮忙客户的数据库免受意外损坏或错误操作的影响。例如，数据库在某个工夫点之后的数据蒙受了意外的删除或损坏，则能够应用 PiTR 性能将数据库复原到该工夫点之前的状态，从而防止失落重要数据。
因为 TiDB 数据库，每一次的数据扭转都会产生对应的分布式日志，其中记录了数据库每一次变更的信息，包含事务 ID、工夫戳和变更的具体内容。
当用户启用 PiTR 性能后，TiDB 会定期将分布式变更日志保留到内部存储（例如：AWS S3，Azure BloB 或 NFS 等）。如果在某个工夫点之后的数据被意外删除或蒙受了损坏，则能够应用 BR 工具将之前的数据库备份复原回来，通过利用保留在内部存储上的数据扭转到用户指定的工夫点，从而达到定点复原的目标。
下面的图示形容了 PiTR 个性的架构：当用户启动了日志备份之后，BR 工具会向 PD 注册一个备份工作。同时，某个 TiDB 节点会被抉择成为日志备份的协调者，定期与 PD 进行交互，以便计算全局备份 checkpoint ts。同时，每个 TiKV 节点会运行定期向 PD 上报本节点的备份工作状态，并将数据变更日志发送到指定的内部存储上。
对于复原过程，当用户发动了基于工夫点的复原命令之后，BR 工具会读取备份的元数据信息，并告诉所有的 TiKV 节点启动复原工作，TiKV 节点上的 Restore worker 会读取定点之前的变更日志并将其利用集群中，就能够失去指定工夫点的 TiDB 集群。
PiTR 个性的工作机制
接下来，咱们进一步看一下日志备份和复原过程的工作机制。
上面的流程图阐明了日志备份的次要工作机制
其中次要的交互流程如下：
1.BR 接管备份命令 br log start
解析日志备份工作的日志备份起始工夫点和备份存储地址，并向 PD 注册日志备份工作 (log backup task)。
2.TiKV 定期监测新建 / 更新的日志备份工作
每个 TiKV 节点的日志备份 observer 监听 PD 中创立与更新日志备份工作，而后备份该节点上在备份工夫范畴内的变更数据日志。
3.TiKV 节点备份 KV 变更日志，并将本地备份进度上报到 TiDB
TiKV 节点中 observer 服务会继续地备份 KV 变更日志，联结从 PD 查问到的 global-checkpoint-ts 来生成备份元数据信息，并定期将日志备份数据和元信息上传到存储中，同时 observer 服务还会避免未备份实现的 MVCC 数据被 PD 回收。
4.TiDB 节点计算并长久化全局备份进度。
TiDB 协调者节点轮询所有 TiKV 节点，获取各个 Region 的备份进度，并依据各个节点的备份进度计算出整体日志备份的进度，而后上报给 PD。
对于复原的过程，能够参考上面的流程图理解其工作机制
当用户发动“br restore <timespot>”命令后，BR 工具会对全量数据和日志数据备份地址、须要复原到的工夫点，须要复原的数据库对象等信息进行校验，确保信息无效后，开始进行复原。BR 首先会将全量数据进行复原，之后读取存在的日志备份数据，计算须要复原的日志备份数据，并拜访 PD 取得须要复原的 Region 和 KV range 相干的信息，创立复原日志申请，发送给对应的 TiKV 节点。TiKV 节点在接管到复原申请后，启动 restore worker，并从备份介质中下载相应的备份数据到本地，并将须要回复的数据扭转复原到对应的 region 当中。在复原实现之后，将复原的执行的后果返回给 BR 工具。
TiDB 对 PiTR 的优化
从下面的工作机制能够看到，无论是日志备份还是复原，其过程都是比较复杂的，所以 TiDB 在 PiTR 公布之后，始终对这个个性进行优化，一直的晋升 PiTR 的技术指标，稳定性和性能。
例如，在最后的版本中日志备份会产生大量的小文件，给用户在应用期间带来很多的问题。在最新版本中，咱们将日志备份文件聚合成为多个大小至多为 128M 的文件，很好的解决了这个问题。
对于大规模的 TiDB 集群，其全量备份往往须要运行很长时间，如果不反对断点续传性能的话，当备份过程中呈现一些异常情况，导致备份工作中断的话，对用户来说是十分令人失望的。在 6.5.0 版本中，咱们反对了备份的断点续传能力，并且优化了备份的性能，目前单个 TiKV 的数据备份性能能够达到 100MB/s，日志备份对源集群的性能影响能够管制在 5% 左右，这些优化都极大的晋升了大规模集群备份的用户体验和备份的成功率。
因为备份复原通常都会被用户作为数据安全的最初一道防线，PiTR 的 RPO 和 RTO 指标也是很多用户所关怀的。咱们在 PiTR 的稳定性上也做了很多的优化，其中包含：
- 通过优化 BR 与 PD 和 TiKV 的通信机制，在绝大多数 TiDB 集群异样场景和 TiKV 滚动重启场景，PiTR 都能够保障 RPO 小于 5 分钟
- 通过优化复原性能，让 PiTR 在利用日志阶段的性能达到 30 GB/h，从而升高升高 RTO 工夫。
对于更多的备份复原性能指标，请参考“TiDB 备份与复原概述”文档。
将来布局
接下来，咱们会对 PiTR 这个个性进行更多的优化，一直的晋升这个个性的稳定性和性能。并摸索备份复原的更多可能性，将 TiDB 的备份复原个性打造成稳固牢靠的高性能备份复原解决方案。
