本文介紹了 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 的備份恢復特性打造成穩定可靠的高效能備份恢復解決方案。