azure sql 地理複製如何在內部工作？
我的公司遷移到 azure 並開始使用 azure Sql 數據庫和地理複製。
對於我們的本地伺服器，我們嚴重依賴 Microsoft 事務複製來移動數據。現在我們在本地伺服器（發布者）和 azure sql db 之間設置事務複製。然後我們發現事務複製本身在 azure 上不斷消耗 100% DTU（我們使用的是 125 DTU P1）。
我們將它升級到 250 DTU，並且複制更快樂。但是，我們不確定不斷更新到更高的 DTU 是否是個好主意。所以我們這樣做了：
- 創建了兩個 125DTU 伺服器。
- 在本地伺服器和伺服器 A 之間設置事務複製。
- 在伺服器 A 和伺服器 B 之間設置異地複制。
- 我們的客戶將使用伺服器 B。
好處是 heo 複製不會觸發 100% DTU 限制，當我們將此提升到 Microsoft 支持時，他也表示這是一個好主意。支持人員還表示，sql geo複製比事務複製效率高得多。
然而，當我們問他內部使用了哪種技術 azure geo-replication 以及為什麼它比舊的事務複製更好時，他只是給出了一些行銷回复：
異地複制利用 SQL Server 的 Always On 技術，使用快照隔離將主數據庫上已送出的事務非同步複製到輔助數據庫。例如，對您的主數據庫的影響是最小的，因為此過程在執行自動備份的相同上下文中執行。
就個人而言，我真的不明白為什麼地理複製比回復中的舊複製更好。有人知道一些技術細節嗎？
正如支持人員告知的那樣，Azure SQL 數據庫的異地複制使用一種特殊的 Always On 可用性組來複製數據。在您的問題的上下文中，“特殊風味”並不重要，因此我將根據“複製與可用性組”來回答，因為它也適用於您的情況。
複製
SQL Server 事務複製是一種在數據庫之間複製特定數據的方法。預設情況下，它將在發布者和訂閱者之間複製數據更改。Distributor 有一個 Log Reader Agent，它讀取 Publisher 的事務日誌，並將其轉換為單獨的更新語句，通過 Distribution Agent 發送給訂閱者。
在發布伺服器上更新 1,000 行的單個更新語句將在訂閱伺服器上生成 1,000 條單獨的更新語句，根據 PK 進行逐行更新。
有其他選擇，但在大多數情況下，這是人們使用的配置，因為它是預設行為。（例如，您可以將儲存過程執行配置為複制，這樣訂閱伺服器就不會逐行複制數據更新，而是再次執行儲存過程……您可能沒有這樣做。）
正如您可以想像的那樣，訂閱者的這種逐行更新可能效率低下。訂閱伺服器上的每個單獨更新都會很快，因為它是基於主鍵的單行更新——但逐行與基於集合的操作並不總是理想的。
可用性組
可用性組 (AG) 以不同的方式處理事情。使用 AG，可以複製整個數據庫，而不僅僅是特定數據。複製方法包括寫入輔助伺服器上的事務日誌，然後在輔助伺服器上重做事務。這兩個步驟通常被稱為“發送”和“重做”階段。
其工作原理的簡化版本：主伺服器上“發送”的成本本質上只是它必須在本地寫入事務日誌，並將相同的確切資訊發送到輔助伺服器以獲取事務日誌的副本。輔助伺服器上“重做”的成本本質上只是處理該事務的方式與在主伺服器上處理的方式相同。