背景介紹
資料庫存儲着企業的核心資料，在企業中占據非常重要的位置，一旦出現SQL注入，資料誤删的情況，影響的不僅僅是業務，還會洩露使用者的個人資訊。是以，資料庫的資料安全問題十分重要。
當資料庫遷移到雲端，其安全問題又被進一步放大，雲資料庫能否高效、便捷地備份資料庫，當發生故障或者資料誤删時，及時高效地恢複資料，成為企業使用者關心的重要問題，影響着他們遷移資料庫上雲的信心。
近期，
阿裡雲分布式關系型資料庫服務 DRDS資料恢複功能重磅釋出，針對執行個體級、資料庫級、表級、行級的資料丢失，分别提供備份恢複、表資源回收筒、SQL 閃回功能，助您在不同場景下快速恢複資料，全方位保障使用者資料的安全。
功能優勢
- 全方位的資料守護：提供執行個體級、資料庫級、表級、行級全方位的資料恢複能力
- 一緻性備份恢複：針對 MySQL 分庫分表場景，在最小化對使用者業務影響的前提下，提供了保證資料的全局一緻性的備份恢複方案
- SQL 級精确閃回：針對SQL誤删(改)操作，無需依賴備份集，提供精确到特定 SQL 的資料閃回能力
- 操作便捷：基于 DRDS 控制台即可完成資料恢複工作，無需再次跳轉至 RDS 控制台，體驗便捷高效
- 價格優勢：功能免費，僅需支付 RDS 備份集所占用的存儲空間費用
應用場景
在實際的生産應用中，資料庫的資料丢失，按照不同場景，大緻可以分為執行個體&資料庫級、資料行級、表級：
- 執行個體&資料庫級資料丢失：整個執行個體或者資料庫的資料丢失，通常是使用者誤删執行個體（資料庫）造成。
- 資料行級丢失：資料表中的部分資料丢失，通常是使用者執行了錯誤的 DELETE（UPDATE）SQL 或者 SQL 注入攻擊，該情況最為常見。
- 資料表丢失：整張資料表的丢失，通常是使用者執行錯誤的 DROP TABLE 操作造成。
針對以上的幾種場景，DRDS 資料恢複都提供了相應的恢複能力，如下圖所示：
備份恢複——執行個體&資料庫級的恢複能力
DRDS 備份恢複提供了 OLTP 場景下必備的執行個體級、資料庫級的備份恢複能力。備份政策上，支援自動備份與手動備份兩種，使用者可以按需選擇，滿足實際的安全需求。
備份恢複方式上，針對MySQL Sharding 場景，提供了
快速備份恢複與
一緻性備份恢複兩種。衆所周知，全局一緻性的備份恢複能力是金融行業以及線上核心交易類業務對資料庫的核心訴求。然而面向 MySQL Sharding 場景，現有的資料庫備份方案主要有兩種：
- 針對每個 MySQL 執行個體分别進行備份。該方案隻能保證單個實體分庫的資料一緻性，在分布式事務存在的情況下，無法保證全局的資料一緻性。
- 對資料庫全局禁寫，之後分别針對每個 MySQL 執行個體進行備份。該方案保證了全局的資料一緻性，但是對使用者業務侵入較大，資料庫在一定時間内無法提供資料寫入服務。
顯然以上兩種備份恢複方式都無法滿足實際的使用者備份需求。針對這一問題，DRDS 在最小化對使用者業務影響的前提下，創新性地為使用者提供了全局一緻性的備份恢複能力，備份過程中資料庫無需禁寫，僅存在亞秒級的RT 抖動。
SQL 閃回——SQL 級誤操作的精确恢複能力
在實際的生産環境中，運維人員執行了錯誤的DELETE（UPDATE）語句，造成資料丢失，是較為常見的資料丢失場景。面對這種情況，通常的解決方案是通過備份恢複或者MySQL Binlog Flashback 工具逆向 Binlog 恢複資料：
- 備份恢複依賴備份集的存在，且這種恢複方式通常會丢失部分資料
- MySQL Binlog Flashback 工具，也隻能按照時間範圍及簡單的過濾條件，逆向 Binlog 的資料，然後使用者從中挑選資料，需要較多的人工介入
針對上述資料行級的誤操作場景，提供精确到特定 SQL 的資料恢複能力。使用者僅需提供誤操作 SQL 的相關資訊，即可針對該 SQL 生成精确的
復原SQL（或原始 SQL）檔案，使用者下載下傳後根據需求恢複資料。
下圖給出了 SQL 閃回恢複資料的示例：
SQL 閃回的使用界面及生成的恢複檔案如下圖所示：
表資源回收筒——表誤删後的快速恢複能力
DRDS 表資源回收筒針對誤删表操作，提供快速的資料恢複能力。表資源回收筒功能開啟後，通過 DROP TABLE 指令删除的表，将移動至表資源回收筒中，2 小時内皆可從資源回收筒中快速恢複。
功能文檔
關于 DRDS 資料恢複的具體功能，請參考：