阿里雲RDS SQL自動化遷移上雲的一種方案

　　摘要

　　至今為止我們完成了SQL Server備份還原專題系列六篇月報分享：三種常見的資料庫備份、備份策略的制定、查詢備份鏈、資料庫的三種恢復模式與備份之間的關係、利用檔案組實現冷熱資料隔離備份方案以及如何監控備份還原進度，本期我們分享阿里雲是如何基於SQL Server備份還原理論來設計RDS SQL自動化遷移上雲方案的。

　　適用場景

　　RDS資料庫遷移上雲是指將使用者線下資料庫搬遷到阿里雲RDS上並完成應用切換到RDS上的工作過程。資料庫遷移上雲的重點和難點在於：如何保證使用者資料庫的完整性的同時，還要保證使用者應用停機切換時間足夠短(起碼要達到分鐘級)。通常使用的方法有邏輯遷移和物理遷移兩種。

　　邏輯遷移

　　邏輯遷移，是指將使用者線下資料庫物件和資料轉化為DDL和DML語句，然後在RDS上執行的遷移上雲方式。這些資料庫的物件包含但不僅限於：

　　?表：資料庫的表物件，是資料庫儲存資料的單元。如果表與表之間有建立主、外來鍵關係，在表物件建立之前，必須找出多表之間的主、外來鍵關係，先建立主表，再建立外表。

　　?約束：表與表之間的主、外來鍵約束;預設約束;唯一約束;Check約束等。

　　?檢視：檢視之間很可能存在引用關係，必須先建立被引用的檢視，然後再建立引用檢視。

　　?函式：函式之間也可能存在相互引用關係。

　　?儲存過程：建立儲存過程不需要嚴格按照引用關係來建立，但很有可能存在跨庫訪問的情況。

　　?同義詞：同義詞類似於物件別名，這個是很多人容易忽略的地方。邏輯遷移這種方式的好處是：應用切換時間很短，可以控制在秒級別。但是缺點也是顯而易見的。

　　?物件建立過程十分複雜，需要首先找出物件間相互依賴關係，才能成功建立所有物件。

　　?表與表主外來鍵約束，從而導致了資料插入操作必須先主表，再外表的順序;資料刪除則相反。

　　?將資料轉化為DML語句，然後在RDS上執行的方式，效率低下，尤其是大表的情況。

　　?頻繁的DML操作語句，非常容易導致RDS上Blocking發生，甚至嚴重時會產生死鎖。

　　?頻繁的DML操作，會導致資料日誌檔案在短時間內暴漲，消耗IOPS資源。

　　?最為嚴重的缺點是，頻繁的DML操作，會導致表索引碎片率在短時間內大幅增加和統計資訊的過時，從而導致執行計劃評估不準確，進行影響RDS資料庫的效能。

　　物理遷移

　　為了消除邏輯遷移的種種痛點，物理遷移是指，RDS SQL基於使用者的物理備份檔案，直接遷移上雲還原到RDS SQL上。既然RDS SQL上的資料是基於使用者線下資料庫備份檔案(既可以是完全備份檔案，也可以是完全備份檔案 + 差異備份或者日誌備份檔案)直接遷移上雲還原到RDS SQL上，那麼，我們就可以100%的保證RDS SQL上的資料庫和使用者線下資料庫是100%一致的。就不會存在以上邏輯遷移的種種痛點，而最大的有點體現在解決了索引碎片和統計資訊的不一致，導致使用者資料庫效能的問題，保證了使用者線下資料庫和RDS SQL資料庫行為時一致性。

　　兩者對比

　　邏輯遷移和物理遷移兩者的優缺點對比如下所示：

　　從對比的結果來看，物理遷移唯一的弱勢在於應用切換的時間稍長，控制在分鐘級別，但是我相信對於起碼95%以上的企業來講分鐘級別的遷移上雲應用停止的時間還是可以接受的。

　　方案解析

　　在前一個章節，我們詳細分析了線下SQL Server資料庫遷移上雲阿里雲RDS SQL的兩種方式：邏輯遷移和物理遷移，從對比結果來看，物理遷移具有更多的優點並且複雜度可控，是實現自動化遷移上雲的最佳方案。以下兩個小節是基於物理遷移上雲方案的分析和流程圖設計。

　　方案分析

　　從整個遷移上雲的過程分析來看，主要牽扯到四個方面的參與者，我們只需要把這四個參與者之間關係及用途分析清楚，方案就一目瞭然了。

　　?使用者線下資料庫：使用者在自己線下環境的SQL Server例項中的資料庫。使用者需要線上下資料庫中完成準備工作、資料庫備份及備份檔案上傳到OSS。

　　?OSS(阿里雲物件儲存服務)：暫存使用者的備份檔案，供RDS SQL例項下載備份檔案。

　　?RDS控制檯：承載著與使用者介面互動的功能，使用者需要透過RDS控制檯告訴阿里雲RDS SQL，將哪一個備份檔案恢復到哪一個例項的哪一個資料庫下。

　　?RDS SQL例項：從OSS下載使用者的備份檔案，然後還原到RDS例項中。

　　流程圖設計

　　從“方案分析”中，我們很清楚的瞭解到遷移上雲方案四方參與者，各司其職，各盡所能，就可以很完美的實現使用者遷移上雲的功能。將整個過程做成流程圖，如下所示：

　　這個流程圖，很清楚的描繪了四方參與者之間的職責以及他們的資料流走向。

　　一個案例

　　參照上面的“方案解析”部分的介紹，我們舉一個特定的案例，來看看阿里雲RDS SQL自動遷移上雲的案例。

　　時間軸

　　首先，從時間維度來看一個典型的上雲案例，參照下圖所示：

　　?橫軸：表示時間，從左往右

　　?數字1 - 9：表示操作步驟先後順序，和時間對應

　　?數字右邊文字：表示操作步驟名稱

　　?數字下方文字：表示操作步驟的詳細描述資訊

　　案例描述

　　根據上圖增量上雲案例，按時間維度，解釋如下：

　　?Step1. Before 00:00：完成準備工作，包括完成DBCC CheckDB檢查;關閉本地環境備份系統;修改資料庫為FULL恢復模式;

　　?Step2. 00:01：使用者備份線下資料庫開始FULL Backup;

　　?Step3. 02:00：完成FULL Backup，耗時近1小時，開始上傳備份檔案到OSS Bucket;

　　?Step4. 03:00：完成備份檔案上傳，耗時1小時，開始在RDS控制檯恢復FULL Backup檔案;

　　?Step5. 22:00：完成FULL Backup上雲，耗時19小時，開始資料庫Backup LOG;

　　?Step6. 22:20：完成LOG Backup，耗時20分鐘，RDS控制檯恢復LOG Backup檔案;

　　?Step7. 22:30：完成LOG Backup上雲，耗時10分鐘，重複步驟5 – 6，不斷Backup LOG、上傳到OSS、增量上雲LOG備份檔案，確保最後一個Backup LOG檔案儘量小(500MB以下)，然後停止本地應用對資料庫的寫入操作，最後再做一個LOG Backup，最後一次增量上雲。

　　?Step8. 22:34：完成了最後一個LOG Backup檔案增量上雲操作，耗時4分鐘，開始將資料庫待上線;

　　?Step9. 22:35：資料庫上線完畢，如果選擇非同步執行DBCC操作，上線動作很快，耗時1分鐘。

　　從整個的動作流程和時間軸來看，使用者需要停止應用的時間非常的短，僅僅是在最後一個LOG Backup之前停止應用寫入即可。在本例中整個應用停止的時間控制在5分鐘內。

　　參考連結

　　關於SQL Server備份還原理論，我們完成了備份還原專題系列月報六篇，以及基於這些理論設計出了阿里雲RDS SQL自動化遷移上雲方法。

　　產品介紹參加如下幫助文件：

　　全量備份資料上雲SQL Server 2008 R2版：https://help.aliyun.com/document_detail/64341.html

　　全量備份資料上雲SQL Server 2012及以上版本：https://help.aliyun.com/document_detail/68310.html

　　增量備份資料上雲SQL Server 2012及以上版本：https://help.aliyun.com/document_detail/71614.html

　　歡迎大家使用並提出寶貴意見。

　　來源：雲棲社群
　　本文作者：風移
　　原文連結：https://yq.aliyun.com/articles/602887?spm=a2c4e.11153940.bloghomeflow.1.5d1c291aPovzkf