筆者在《遷移 SQL Server 數據庫到 Azure SQL 實戰》一文中，介紹瞭如何把一個本地版的 SQL Server 數據庫遷移到 Azure SQL Database。遷移雖然順利實現了，但是現在我們又面臨一個新的任務：如何對新遷移的數據庫進行備份？
對於數據庫的維護來說，備份工作可謂是重中之重。MS Azure 當然也提供了很完善的數據庫備份功能，但是在動手創建備份計劃前，請思考一下備份工作的真實目的：當然首先要保證數據的安全，一般來說定時創建數據庫的備份文件，再拷貝到不同的存儲設備上就可以了；其次，當災難發生時，能不能在最短的時間內還原數據庫從而恢復應用？最後，能不能讓備份的數據庫也創造一些價值？
讓我們帶着這些問題，一起來了解下 Azure 提供的一種可以跨越數據中心的數據庫備份方式：Active Geo-Replication。
文章來源：葡萄城產品技術社區
一、Active Geo-Replication 是什麼？
這裏的 Active 我們可以理解爲 "正在運行的"，Geo 表示的是 "geographic" 也就是 "地理的"，Replication 是 "複製" 的意思。合起來的大意就是 "在不同的地理位置上運行的副本"。
Active Geo-Replication 允許我們最多配置4個只讀的從數據庫，再加上一個主數據庫，此時你就會擁有五個數據庫的實例，並且它們都是可訪問的。注意，這五個數據庫可以設置在不同的數據中心，也就是說當其中的四個數據中心完全掛掉的時候，你的數據庫依然是安全的，並且可以立即使用，這是因爲它是正在運行的數據庫。主數據庫可讀寫，並且以異步的方式把變更同步到其餘的從數據庫。我們可以輕鬆的把主數據庫和從數據庫配置到不同的數據中心，因而當災難發生時，我們可以用最少的時間恢復程序的執行並且做到不丟失數據。
這是如何做到的呢？當主數據庫由於任何原因不可用時，我們可以把任何一個從數據庫切換爲主數據庫，切換完成後，各個數據庫會立即適應自己的新角色，即主數據庫異步的向從數據庫同步數據。需要注意的是，Azure 並不會智能的幫我們做切換工作，這個工作需要小夥伴們自己手動執行，或者是寫程序執行。
Active Geo-Replication 實現了一個可以在不同的區域間進行數據庫冗餘備份的架構 (Azure 上的數據庫) 。它通過異步複製已提交的事務來保證主從服務器的同步。因此從數據庫中的數據會稍微比主數據庫滯後一點點(筆者在主數據庫中插入一條數據，在下一行中執行從數據庫中的查詢就能查到這條數據)。
Active Geo-Replication 的設置非常簡單，可以通過圖形化的操作就能完成。下面的截圖是設置了一個從數據庫的 demo:
這一點 MS 真的做得很好，操作好用到你想在哪個數據中心創建備份，直接點地圖上的圈圈就行了！但是操作的時間問題卻是無法保證的，筆者嘗試把 8G 的數據庫向不同的數據中心做備份，短的幾分鐘就好了，長的則需要數小時！
二、使用 Active Geo-Replication 的優勢
1. 提供數據庫級別的災難恢復
當我們把從數據庫部署到 Azure 上的不同的數據中心時，就爲應用程序提供了最強的的災難恢復能力。跨數據中心的冗餘數據庫備份讓我們能夠很容易的，並且很快的從災難中恢復數據。其中，這些災難可能是人力不可抗拒的自然災害，也有可能是一些人爲的惡意攻擊。
2. 只讀的從數據庫可以分擔主數據庫的部分負載
像生成報表等一些只讀的操作，完全可以通過訪問從數據庫來完成，從而降低主數據庫的負載。對於筆者來說，這是使用 Active Geo-Replication 的重要目的。讀過前文的朋友知道，筆者是在維護一箇舊的系統，不是必須要做的事情，筆者是不願意去優化那些已經跑了很多年的、慢吞吞的、很複雜的報表查詢操作的。現在好了，只需要把這些查詢定向到備份用的從數據庫就可以了，結果就是所有操作的性能都會有所提升。
更進一步，還可以把從數據庫與主數據庫設置在同一區域中，然後實現對讀操作的負載平衡，詳情請參考 MSDN。當然這並不會增加應用程序的容災能力。
3. 數據庫遷移
通過使用 Active Geo-Replication，我們可以用最短的時間完成數據庫的遷移工作，其實就是創建一個從數據庫的過程。
4. 應用程序升級的回退備份
我們可以創建一個從數據庫作爲應用程序升級失敗後回退用的備份。這裏可能會讓人迷惑，因爲主從數據庫是有同步關係的，在升級主數據庫的過程中從數據庫肯定會被同步，它又如何能夠作爲備份呢？真相是這樣的：在從數據庫創建後可以讓它斷開與主數據庫的主從關係，斷開後就不會再被同步，所以可以起到備份的作用。
三、Active Geo-Replication的主要功能
前面我們介紹了 Active Geo-Replication 相比傳統備份方法的一些優勢，接下來我們一起看看它都有哪些主要功能。
1. 自動進行的異步複製
我們只能爲已經存在的數據庫添加從數據庫，並且只能把從數據庫添加到和主數據庫不同的 Azure SQL Database server 中。被創建的從數據庫會使用主數據庫中的數據進行填充，這個過程稱爲播種（seeding）。播種完成後，主數據庫中的更新就會以異步複製的方式，自動同步到從數據庫中。
2. 支持最多四個從數據庫
兩個或兩個以上的從數據庫可以顯著的增強主數據庫的容災能力。當有多個從數據庫存在時，即便其中的一個從數據庫發生了故障，也不影響主數據庫的抗災能力。注意，當你配備多個從數據庫作爲備份時，也是有成本的，需要根據具體需求確定從數據庫的個數。
3. 從數據庫是隻讀的
應用程序可以把一些只讀的操作放在從數據庫上，並且可以使用不同的用戶權限去操作從數據庫。此處我們可能會關注主從數據庫同步的性能，當我們在從數據庫上執行操作時，會不會影響主數據庫到從數據庫的同步。按照 MS 的說法是不會的，對從數據庫的讀操作使用了一種稱爲快照隔離模式（snapshot isolation mode）的高大上方法，能夠在讀操作的同時，不影響主數據庫到從數據庫的同步。
4. 可以使用 elastic database pool
Active Geo-Replication 可以像普通數據庫一樣被配置到 elastic database pool 中。
5. 從數據庫可以設置爲與主數據庫不同的配置
對於作爲備份存在的從數據庫而言，如果保持資源類型和主數據庫一致是相當奢侈的。好在 MS 也爲我們提前想好了，把從數據庫的資源類型設置的低一點可以爲我們節省不少的預算。但這樣也可能會帶來一點問題，就是主從數據庫的同步延遲會增加。具體情況取決於你的應用。
6. 用戶可控的災難恢復
一個從數據庫可以在任何時刻被切換成主數據庫。同時，原來的主數據庫會成爲從數據庫。
當災難發生在主數據庫上時，我們可以把一個從數據庫切換成主數據庫，程序只需要重新配置數據庫的鏈接信息即可。再次強調，這個操作需要用戶使用寫程序等方式來完成。
7. 同步防火牆和認證信息
傳統 sql server 的登錄用戶都是在 database server 級別設置的，這在數據庫同步的應用場景中，可能會帶來一些不便。比如從數據庫所在的 database server 上是否設置了相同的用戶登錄信息；如果沒有，當主從數據庫切換後，應用程序訪問數據庫時就可能碰到登錄問題。
爲了解決這一問題，新的 sql server 支持數據庫級別的用戶訪問控制。用戶不需要有登錄 sql server 的權限，只要能夠訪問某個數據庫就可以了，並且用戶的信息是保存在數據庫的配置文件中的，可以隨數據庫一起復制。
同理，防火牆的規則也可以設置在數據庫上。
8. 使用 PowerShell 進行管理
可以使用 Azure Resource Manager (ARM) APIs 通過 PowerShell 管理 Active Geo-Replication。
四、總結
Active Geo-Replication 在提供數據庫備份的同時，也增加了很多附加的價值，爲我們的應用程序和維護帶來了更多的靈活性。如果使用得當，可以通過很少的成本增加來創造大量的價值。
