將資料庫資源遷移至全域 Azure
重要
自 2018 年 8 月起,我們尚未接受新客戶,或將任何新功能和服務部署到原始 Microsoft Cloud 德國位置。
根據客戶需求的演進,我們最近 在德國推出 兩個新的數據中心區域,提供客戶數據落地、Microsoft 全球雲端網路的完整連線,以及市場競爭定價。
此外,我們在 2020 年 9 月 30 日宣佈 Microsoft Cloud Germany 即將於 2021 年 10 月 29 日關閉。 您可以在這裡取得更多詳細數據: https://www.microsoft.com/cloud-platform/germany-cloud-regions。
藉由立即 移 轉,利用我們新德國數據中心區域所提供的功能、企業級安全性和全方位功能。
本文提供可協助您將 Azure 資料庫資源從 Azure 德國移轉至全域 Azure 的資訊。
SQL Database
若要移轉較小的 Azure SQL 資料庫工作負載,而不讓移轉的資料庫保持在線狀態,請使用導出函式來建立 BACPAC 檔案。 BACPAC 檔案是壓縮 (壓縮) 檔案,其中包含來自 SQL Server 資料庫的元數據和數據。 建立 BACPAC 檔案之後,您可以使用 AzCopy) 並使用 import 函式重建資料庫,將檔案複製到目標環境 (。 請注意下列考慮:
- 若要讓匯出交易一致,請確定下列其中一個條件成立:
- 匯出期間不會發生寫入活動。
- 您可以從 SQL 資料庫的交易一致複本匯出。
- 若要匯出至 Azure Blob 記憶體,BACPAC 檔案大小限製為 200 GB。 針對較大的 BACPAC 檔案,導出至本機記憶體。
- 如果從 SQL Database 匯出作業所花費的時間超過 20 小時,可能會取消作業。 如需如何提升效能的秘訣,請參閱下列文章。
注意
匯出作業之後 連接字串 變更,因為伺服器的 DNS 名稱會在匯出期間變更。
其他資訊:
- 瞭解如何 將資料庫導出至 BACPAC 檔案。
- 瞭解如何 將 BACPAC 檔案匯入資料庫。
- 檢閱 Azure SQL 資料庫檔。
注意
建議您使用 Azure Az PowerShell 模組來與 Azure 互動。 請參閱安裝 Azure PowerShell 以開始使用。 若要瞭解如何遷移至 Az PowerShell 模組,請參閱將 Azure PowerShell 從 AzureRM 遷移至 Az。
使用主動式異地復寫移轉 SQL Database
對於對 BACPAC 檔案而言太大的資料庫,或從一個雲端移轉至另一個雲端,並在最短停機時間下保持在線狀態,您可以設定從 Azure 德國到全域 Azure 的作用中異地複寫。
重要
只有在使用 Transact-SQL (T-SQL) 來設定作用中異地復寫以將資料庫移轉至全域 Azure 才支援,而且在移轉之前,您必須要求啟用訂用帳戶以支援移轉至全域 Azure。 若要提交要求,您必須 使用此支援要求連結。
注意
Azure 全球雲端區域德國中西部和德國北部是使用 Azure 德國雲端進行主動式異地複寫的支持區域。 如果需要替代的全域 Azure 區域作為最終資料庫 () 目的地,在移轉至全域 Azure 之後的建議是設定從德國西部或德國北部到必要的 Azure 全域雲端區域的額外異地復寫連結。
如需作用中異地復寫成本的詳細資訊,請參閱 Azure SQL 資料庫定價中的作用中異地復寫一節。
使用主動式異地復寫移轉資料庫需要全域 Azure 中的 Azure SQL 邏輯伺服器。 您可以使用入口網站、Azure PowerShell、Azure CLI 等來建立伺服器,但只支援使用 Transact-SQL (T-SQL) 設定從 Azure 德國移轉至全域 Azure 的作用中異地複寫。
重要
在雲端之間移轉時,主要 (Azure 德國) 和次要 (全域 Azure) 伺服器名稱前置詞必須不同。 如果伺服器名稱相同,執行 ALTER DATABASE 語句將會成功,但移轉將會失敗。 例如,如果主伺服器名稱 myserver
的前置詞 (myserver.database.cloudapi.de
) ,全域 Azure 中輔助伺服器名稱的前置詞不能是 myserver
。
語句 ALTER DATABASE
可讓您使用目標端的完整 DNS 伺服器名稱,在全域 Azure 中指定目標伺服器。
ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
-
sourcedb
代表 Azure 德國 Azure SQL 伺服器中的資料庫名稱。 -
public-server.database.windows.net
代表全域 Azure 中存在的 Azure SQL 伺服器名稱,其中應移轉資料庫。 需要命名空間 「database.windows.net」 請將 public-server 取代為全域 Azure 中邏輯 SQL 伺服器的名稱。 全域 Azure 中的伺服器必須與 Azure 德國的主伺服器名稱不同。
此命令會在裝載要移轉之本機資料庫的 Azure 德國伺服器上的 master 資料庫上執行。
T-SQL start-copy API 會在該伺服器的 master 資料庫中尋找具有相同 SQL 登入/使用者名稱的使用者,以驗證公用雲端伺服器中的登入使用者。 此方法與雲端無關;因此,T-SQL API 可用來啟動跨雲端複本。 如需本主題的許可權和詳細資訊,請參閱 建立和使用作用中異地複 寫和 ALTER DATABASE (Transact-SQL) 。
除了指出全域 Azure 中 Azure SQL 邏輯伺服器的初始 T-SQL 命令延伸模組之外,作用中異地複寫程式的其餘部分與本機雲端中的現有執行相同。 如需建立作用中異地復寫的詳細步驟,請參閱 建立和使用主動式異地複 寫,但例外狀況是輔助資料庫是在全域 Azure 中建立的次要邏輯伺服器中建立。
當輔助資料庫存在於全域 Azure (作為其 Azure 德國資料庫在線複本) 之後,客戶可以使用 ALTER DATABASE T-SQL 命令來起始從 Azure 德國到全域 Azure 的資料庫故障轉移, (請參閱下表) 。
故障轉移之後,一旦輔助資料庫成為全域 Azure 中的主資料庫,您就可以停止作用中的異地復寫,並隨時移除 Azure 德國端的輔助資料庫, (請參閱下表,以及圖表) 中的步驟。
故障轉移之後,Azure 德國的輔助資料庫會繼續產生成本,直到刪除為止。
ALTER DATABASE
使用 命令是設定作用中異地復寫以將 Azure 德國資料庫移轉至全域 Azure 的唯一方式。沒有 Azure 入口網站、Azure Resource Manager、PowerShell 或 CLI 可用來設定此移轉的作用中異地複寫。
若要將資料庫從 Azure 德國移轉至全域 Azure:
例如,選擇 Azure 德國中的用戶資料庫
azuregermanydb
在全域 Azure 中建立邏輯伺服器 (公用雲端) ,例如
globalazureserver
。 完整網域名稱 (FQDN) 為globalazureserver.database.windows.net
。在 Azure 德國的伺服器上執行此 T-SQL 命令,以啟動從 Azure 德國到全域 Azure 的作用中異地複寫。 請注意,完整 DNS 名稱會用於公用伺服器
globalazureserver.database.windows.net
。 這是表示目標伺服器位於全域 Azure,而不是 Azure 德國。ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];
當復寫準備好將讀寫工作負載移至全域 Azure 伺服器時,請在全域 Azure 伺服器上執行此 T-SQL 命令,以起始 容錯移轉 至全域 Azure。
ALTER DATABASE [azuregermanydb] FAILOVER;
在故障轉移程式之前或之後,可以終止作用中的異地復寫連結。 在 容錯移轉 之後執行下列 T-SQL 命令,會移除異地復寫連結,並將全域 Azure 中的資料庫移除為讀寫複本。 它應該在目前異地主資料庫的邏輯伺服器上執行 (,也就是在全域 Azure 伺服器) 上。 這將會完成移轉程式。
ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];
在 容錯移轉 之前執行下列 T-SQL 命令也會停止移轉程式,但在此情況下,Azure 德國的資料庫會維持讀寫複本。 此 T-SQL 命令也應該在目前異地主資料庫的邏輯伺服器上執行,在此案例中為 Azure 德國伺服器。
ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];
您也可以使用主動式異地復寫來遵循下列步驟,將 Azure SQL 資料庫從 Azure 德國移轉至全域 Azure。
如需詳細資訊,下表指出用於管理故障轉移的 T-SQL 命令。 Azure 德國與全域 Azure 之間的跨雲端主動異地復寫支援下列命令:
命令 | 描述 |
---|---|
ALTER DATABASE | 使用 ADD SECONDARY ON SERVER 引數,針對現有資料庫建立次要資料庫並開始資料複寫 |
ALTER DATABASE | 使用 FAILOVER 或 FORCE_FAILOVER_ALLOW_DATA_LOSS,將次要資料庫切換為主要資料庫以便開始容錯移轉 |
ALTER DATABASE | 使用 REMOVE SECONDARY ON SERVER,來終止 SQL Database 和指定次要資料庫間的資料複寫。 |
主動式異地復寫監視系統檢視
命令 | 描述 |
---|---|
sys.geo_replication_links | 針對 Azure SQL Database 伺服器上的每個資料庫,傳回所有現有複寫連結的相關資訊。 |
sys.dm_geo_replication_link_status | 針對指定的 SQL Database,取得上次複寫時間、上次複寫延遲,以及複寫連結的其他相關資訊。 |
sys.dm_operation_status | 顯示所有資料庫作業的狀態,包括複寫連結的狀態。 |
sp_wait_for_database_copy_sync | 讓應用程式等到使用中輔助資料庫複寫並認可所有已認可的交易為止。 |
移轉 SQL Database 長期保留備份
使用異地復寫或 BACPAC 檔案移轉資料庫不會複製長期保留備份,資料庫可能位於 Azure 德國。 若要將現有的長期保留備份移轉至目標全域 Azure 區域,您可以使用 COPY 長期保留備份程式。
注意
這裡記載的 LTR 備份複製方法只能將 LTR 備份從 Azure 德國複製到全域 Azure。 不支援使用這些方法複製 PITR 備份。
必要條件
- 您要複製 LTR 備份的目標資料庫,在全域 Azure 中必須存在,才能開始複製備份。 建議您先使用 主動式異地復 寫來移轉源資料庫,然後起始 LTR 備份複本。 這可確保資料庫備份會複製到正確的目的地資料庫。 如果您透過卸除資料庫的 LTR 備份複製,則不需要此步驟。 複製已卸除資料庫的 LTR 備份時,將會在目標區域中建立虛擬 DatabaseID。
- 安裝此 PowerShell Az 模組
- 開始之前,請確定訂用帳戶或資源群組範圍授與必要的 Azure RBAC 角色。 注意:若要存取屬於已卸載伺服器的 LTR 備份,必須在該伺服器的訂用帳戶範圍內授與許可權。 .
限制
- 不支援故障轉移群組。 這表示移轉 Azure 德國資料庫的客戶 () 必須在故障轉移期間管理連接字串本身。
- 不支援 Azure 入口網站、Azure Resource Manager API、PowerShell 或 CLI。 這表示每個 Azure 德國移轉都必須透過 T-SQL 管理主動式異地複寫設定和故障轉移。
- 客戶無法在全域 Azure 中為 Azure 德國的資料庫建立多個異地次要資料庫。
- 建立異地次要複本必須從 Azure 德國區域起始。
- 客戶只能將資料庫從 Azure 德國移轉至全球 Azure。 目前不支援其他跨雲端移轉。
- Azure 德國用戶資料庫中的 Azure AD 使用者會移轉,但無法在移轉資料庫所在的新 Azure AD 租使用者中使用。 若要啟用這些使用者,必須使用新移轉資料庫所在的新 Azure AD 租使用者中可用的目前 Azure AD 使用者手動卸載和重新建立。
使用 PowerShell 複製長期保留備份
引進了新的 PowerShell 命令 Copy-AzSqlDatabaseLongTermRetentionBackup ,可用來將長期保留備份從 Azure 德國複製到 Azure 全球區域。
- 使用備份名稱複製 LTR 備份 下列範例示範如何使用backupname,將LTR備份從 Azure 德國複製到 Azure 全域區域。
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"
Copy-AzSqlDatabaseLongTermRetentionBackup
-Location $location
-ResourceGroupName $sourceRGName
-ServerName $sourceServerName
-DatabaseName $sourceDatabaseName
-BackupName $backupName
-TargetDatabaseName $targetDatabaseName
-TargetSubscriptionId $targetSubscriptionId
-TargetResourceGroupName $targetRGName
-TargetServerFullyQualifiedDomainName $targetServerFQDN
- 使用備份 resourceID 複製 LTR 備份 下列範例示範如何使用備份 resourceID,將 LTR 備份從 Azure 德國複製到 Azure 全域區域。 此範例也可用來複製已刪除資料庫的備份。
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All
# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId
# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"
Copy-AzSqlDatabaseLongTermRetentionBackup
-ResourceId $resourceID
-TargetDatabaseName $targetDatabaseName
-TargetSubscriptionId $targetSubscriptionId
-TargetResourceGroupName $targetRGName
-TargetServerFullyQualifiedDomainName $targetServerFQDN
限制
- 還原時間點 (PITR) 備份只會在主資料庫上執行,這是設計方式。 使用異地DR從 Azure 德國移轉資料庫時,PITR 備份會在故障轉移後於新的主要複本上開始發生。 不過,Azure 德國) 上一個主要複本上現有的 PITR 備份 (將不會移轉。 如果您需要 PITR 備份來支援任何時間點還原案例,您需要從 Azure 德國的 PITR 備份還原資料庫,然後將復原的資料庫遷移至全域 Azure。
- 長期保留原則不會與資料庫一起移轉。 如果您在 Azure 德國的資料庫上有 長期保留 (LTR) 原則,您必須在移轉之後,手動複製並重新建立新資料庫的 LTR 原則。
要求存取權
若要使用異地復寫將資料庫從 Azure 德國移轉至全域 Azure,您必須啟用 Azure 德國中的 訂用帳戶,才能成功設定跨雲端移轉。
若要啟用 Azure 德國訂用帳戶,您必須使用下列連結來建立移轉支援要求:
流覽至下列 移轉支援要求。
在 [基本] 索引標籤上,輸入 異地DR移 轉作為 [摘要],然後選取 [ 下一步:解決方案]
檢閱 建議的步驟,然後選取 [ 下一步:詳細數據]。
在詳細數據頁面上,提供下列專案:
- 在 [描述] 方塊中,輸入要移轉至的全域 Azure 訂用帳戶標識碼。 若要將資料庫移轉至多個訂用帳戶,請新增您要移轉資料庫之全域 Azure 識別符的清單。
- 提供聯繫人資訊:名稱、公司名稱、電子郵件或電話號碼。
- 完成窗體,然後選取 [ 下一步:檢閱 + 建立]。
檢閱支援要求,然後選取 [ 建立]。
一旦處理要求,您就會連絡。
Azure Cosmos DB
您可以使用 Azure Cosmos DB 資料遷移工具將資料遷移至 Azure Cosmos DB。 Azure Cosmos DB 數據遷移工具是開放原始碼解決方案,可將數據從不同的來源匯入 Azure Cosmos DB,包括:JSON 檔案、MongoDB、SQL Server、CSV 檔案、Azure 數據表記憶體、Amazon DynamoDB、HBase 和 Azure Cosmos 容器。
Azure Cosmos DB 資料遷移工具可作為圖形化介面工具或命令行工具使用。 原始程式碼可在 Azure Cosmos DB 資料遷移工具 GitHub 存放庫中取得。 Microsoft 下載中心提供 工具的編譯版本 。
若要移轉 Azure Cosmos DB 資源,建議您完成下列步驟:
- 檢閱應用程式運行時間需求和帳戶設定,以判斷最佳動作計劃。
- 執行數據遷移工具,將帳戶組態從 Azure 德國複製到新區域。
- 如果可能使用維護期間,請執行資料遷移工具,將數據從來源複製到目的地。
- 如果使用維護時段不是選項,請執行此工具,將資料從來源複製到目的地,然後完成下列步驟:
- 使用設定驅動方法來變更應用程式中的讀取/寫入。
- 完成第一次同步處理。
- 設定累加同步處理,並跟上變更摘要。
- 指向新帳戶並驗證應用程式。
- 停止對舊帳戶的寫入、驗證已攔截變更摘要,然後將寫入指向新帳戶。
- 停止工具並刪除舊的帳戶。
- 執行工具,以驗證數據在舊帳戶和新帳戶之間是否一致。
其他資訊:
- 若要瞭解如何使用數據遷移工具,請參閱教學課程 :使用數據遷移工具將數據遷移至 Azure Cosmos DB。
- 若要瞭解 Cosmos DB,請參閱 歡迎使用 Azure Cosmos DB。
Azure Cache for Redis
如果您想要將 Azure Cache for Redis 實例從 Azure 德國移轉至全域 Azure,則有幾個選項。 您選擇的選項取決於您的需求。
選項 1:接受數據遺失,建立新的實例
當下列兩個條件都成立時,此方法最合理:
- 您使用 Azure Cache for Redis 作為暫時性數據快取。
- 您的應用程式會自動在新區域中重新填入快取數據。
若要移轉數據遺失並建立新的實例:
- 在新的目標區域中建立新的 Azure Cache for Redis 實例。
- 更新您的應用程式以在新區域中使用新的實例。
- 刪除來源區域中的舊 Azure Cache for Redis 實例。
選項 2:將資料從來源實例複製到目標實例
Azure Cache for Redis 小組的成員撰寫了開放原始碼工具,可將數據從某個 Azure Cache for Redis 實例複製到另一個實例,而不需要匯入或導出功能。 如需工具的相關信息,請參閱下列步驟中的步驟 4。
若要將數據從來源實例複製到目標實例:
- 在來源區域中建立 VM。 如果您的數據集 Azure Cache for Redis 很大,請確定您選取相當強大的 VM 大小,以將複製時間降到最低。
- 在目標區域中建立新的 Azure Cache for Redis 實例。
- 從 目標 實例排清數據。 (確定 不要 從 來源 實例排清。需要排清,因為複製工具 不會覆寫 目標位置中的現有索引鍵。)
- 使用下列工具自動將數據從來源 Azure Cache for Redis 實例複製到目標 Azure Cache for Redis 實例:工具來源和工具下載。
注意
此程式可能需要很長的時間,視數據集的大小而定。
選項 3:從來源實例匯出,匯入至目的地實例
此方法會利用只能在進階層中使用的功能。
若要從來源實例匯出並匯入至目的地實例:
在目標區域中建立新的進階層 Azure Cache for Redis 實例。 使用與來源 Azure Cache for Redis 實例相同的大小。
從來源快取導出數據 ,或使用 Export-AzRedisCache PowerShell Cmdlet。
注意
匯出 Azure 記憶體帳戶必須與快取實例位於相同的區域中。
例如,使用 AzCopy) ,將導出的 Blob 複製到目的地區域中的記憶體帳戶 (。
重新設定您的應用程式以使用目標 Azure Cache for Redis 實例。
選項 4:將數據寫入兩個 Azure Cache for Redis 實例,從一個實例讀取
針對此方法,您必須修改您的應用程式。 從其中一個快取實例讀取時,應用程式必須將數據寫入多個快取實例。 如果儲存在 Azure Cache for Redis 中的數據符合下列準則,這個方法就很合理:
- 數據會定期重新整理。
- 所有數據都會寫入目標 Azure Cache for Redis 實例。
- 您有足夠的時間來重新整理所有資料。
其他資訊:
PostgreSQL 和 MySQL
如需詳細資訊,請參閱 PostgreSQL 和 MySQL 的一節中的文章。
下一步
瞭解下列服務類別中移轉資源的工具、技術和建議: