共用方式為


使用指令碼設定連結 - Azure SQL 受控執行個體

適用於:Azure SQL 受控執行個體

本文教會您如何使用 Transact-SQL 和 PowerShell 或 Azure CLI 指令碼來設定 SQL Server 與 Azure SQL 受控執行個體之間的連結。 透過連結,來自初始主要複本的資料庫會以近乎即時的方式複寫到次要複本。

在建立連結之後,您就可以容錯移轉至次要複本,以便進行移轉或災害復原。

注意

概觀

使用連結功能,將資料庫從初始主複本複寫到次要複本。 針對 SQL Server 2022,初始主要複本可以是 SQL Server 或 Azure SQL 受控執行個體。 針對 SQL Server 2019 與舊版,初始主要複本必須是 SQL Server。 在設定連結之後,會將初始主要複本的資料庫複寫到次要複本。

您可選擇在主要與次要複本之間的混合式環境保留連結以便連續複寫資料,也可將資料庫容錯移轉至次要複本、移轉至 Azure 或進行災害復原。 針對 SQL Server 2019 與舊版,容錯移轉至 Azure SQL 受控執行個體會中斷連結,且不支援容錯回復。 使用 SQL Server 2022 時,您可以選擇維護連結,並在兩個復本之間來回容錯回復。

如果您打算僅使用次要受控執行個體進行災害復原,您可藉由啟用混合式容錯移轉權益來節省授權成本。

使用本文指示,在 SQL Server 與 Azure SQL 受控執行個體之間手動設定連結。 在建立連結之後,來源資料庫就會在目標次要複本產生唯讀複本。

提示

為簡化搭配您環境的正確參數使用 T-SQL 指令碼,強烈建議使用 SQL Server Management Studio (SSMS) 中的受控執行個體連結精靈產生指令碼以建立連結。 在 [新增受控執行個體連結] 視窗的 [摘要] 頁面上,選取 [指令碼] 而不是 [完成]。

必要條件

若要複寫您的資料庫,必須符合下列必要條件:

請考慮下列事項:

  • 連結功能針對每個連結支援一個資料庫。 若要複寫一個執行個體上的多個資料庫,請針對每個資料庫建立一個連結。 例如,若要將 10 個資料庫複寫到 SQL 受控執行個體,請建立 10 個連結。
  • SQL Server 與 SQL 受控執行個體之間的定序應該相同。 定序中的不符可能會導致伺服器名稱大小寫不符,而無法成功從 SQL Server 連線到 SQL 受控執行個體。
  • 初始 SQL Server 主要備份錯誤 1475 表示您必須建立完整備份而不使用 COPY ONLY 選項來啟動新的備份鏈結。
  • 若要建立從 SQL 受控執行個體至 SQL Server 2022 的連結或容錯移轉,您的受控執行個體必須已設定 SQL Server 2022 更新原則。 已使用一律保持最新更新原則設定的執行個體,不支援從 SQL 受控執行個體至 SQL Server 2022 的資料複寫和容錯移轉。
  • 雖然您可以建立從 SQL Server 2022 至已設定一律保持最新的更新原則的 SQL 受控執行個體的連結,但容錯移轉至 SQL 受控執行個體之後,將無法再複寫資料或容錯回復至 SQL Server 2022。

權限

在 SQL Server 上,您應具備 sysadmin 權限。

在 Azure SQL 受控執行個體上,您應為 SQL 受控執行個體參與者的成員,或具備自訂角色的下列權限:

Microsoft.Sql/ resource 必要權限
Microsoft.Sql/managedInstances /read、/write
Microsoft.Sql/managedInstances/hybridCertificate /action
Microsoft.Sql/managedInstances/databases /read、/delete、/write、/completeRestore/action、/readBackups/action、/restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read、/write、/delete、/setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /read、/write、/delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write、/delete、/read

詞彙和命名慣例

當您執行本使用者指南中的指令碼時,請務必不要將 SQL Server 和 SQL 受控執行個體名稱誤認為其完整網域名稱 (FQDN)。 下表說明各種名稱確切代表的意思,以及如何取得其值:

詞彙 Description 查明方式
初始主要複本 1 您一開始建立連結以將資料庫複寫至次要複本的 SQL Server 或 SQL 受控執行個體。
主要複本 目前裝載主要資料庫的 SQL Server 或 SQL 受控執行個體。
次要複本 從目前主要復本接收近乎即時的複寫資料的 SQL Server 或 SQL 受控執行個體。
SQL Server 名稱 簡短、單字詞的 SQL Server 名稱。 例如:sqlserver1 從 T-SQL 執行 SELECT @@SERVERNAME
SQL Server FQDN SQL Server 的完整網域名稱 (FQDN)。 例如:sqlserver1.domain.com 如果您使用 Azure 虛擬機器 (VM),請參閱您的內部部署網路 (DNS) 設定或伺服器名稱。
SQL 受控執行個體名稱 簡短、單字詞的 SQL 受控執行個體名稱。 例如:managedinstance1 請參閱 Azure 入口網站中的受控執行個體名稱。
SQL 受控執行個體 FQDN SQL 受控執行個體的完整網域名稱 (FQDN)。 例如:managedinstance1.6d710bcf372b.database.windows.net 請參閱 Azure 入口網站中 SQL 受控執行個體概觀頁面上的主機名稱。
可解析的網域名稱 可解析為 IP 位址的 DNS 名稱。 例如,執行 nslookup sqlserver1.domain.com 應傳回 IP 位址,例如 10.0.0.1。 從命令提示字元執行 nslookup 命令。
SQL Server IP SQL Server 的 IP 位址。 如果 SQL Server 有多個 IP,請選擇可從 Azure 存取的 IP 位址。 在執行 SQL Server 的主機 OS 中,從命令提示字元執行 ipconfig 命令。

1 從 SQL Server 2022 CU10 開始,支援將 Azure SQL 受控執行個體 設定為初始主要複本。

設定資料庫復原和備份

如果您的初始主要複本為 SQL Server,則透過連結複寫的資料庫必須處於完整復原模式,且至少有一個備份。 由於 Azure SQL 受控執行個體會自動進行備份,如果 SQL 受控執行個體是您的初始主要複本,請略過此步驟。

針對您想要複寫的所有資料庫,在 SQL Server 上執行下列程式碼。 將 <DatabaseName> 取代為實際的資料庫名稱。

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

如需詳細資訊,請參閱建立完整資料庫備份

注意

此連結僅支援使用者資料庫的複寫。 不支援系統資料庫的複寫。 若要複寫執行個體層級物件 (儲存在 mastermsdb 資料庫中),建議您透過指令碼找出這些物件,並在目的地執行個體上執行 T-SQL 指令碼。

在執行個體之間建立信任

首先,您必須在兩個執行個體之間建立信任,並保護用來跨網路通訊和加密資料的端點。 分散式可用性群組會使用現有可用性群組的資料庫鏡像端點,而不是擁有自己的專用端點。 因此,必須透過可用性群組資料庫鏡像端點,在兩個執行個體之間設定安全性和信任。

注意

連結以一律開啟可用性群組技術為基礎。 資料庫鏡像是特殊目的之端點,專門由可用性群組用來接收其他伺服器執行個體的連線。 資料庫鏡像端點一詞不應與舊版 SQL Server 資料庫鏡像功能誤用。

憑證式信任是保護 SQL Server 和 SQL 受控執行個體之資料庫鏡像端點的唯一支援方式。 如果您有使用 Windows 驗證的現有可用性群組,您必須將憑證式信任新增至現有的鏡像端點作為次要驗證選項。 如本文稍後所示,您可以使用 ALTER ENDPOINT 陳述式來完成這項作業。

重要

系統會產生具有到期日期和時間的憑證。 這些憑證必須在到期前更新並輪替。

以下列出了保護 SQL Server 和 SQL 受控執行個體上資料庫鏡像端點的程序概觀:

  1. 在 SQL Server 上產生憑證,並取得其公開金鑰。
  2. 取得 SQL 受控執行個體憑證的公開金鑰。
  3. 在 SQL Server 與 SQL 受控執行個體之間交換公開金鑰。
  4. 將 Azure 信任的根憑證授權單位金鑰匯入至 SQL Server

下列各節會詳細描述這些步驟。

在 SQL Server 上建立憑證,並將其公開金鑰匯入至 SQL 受控執行個體

首先,如果 master 資料庫中還沒有資料庫主要金鑰,請建立一個。 在以下指令碼中插入您的密碼代替 <strong_password>,並將密碼存放在機密且安全的地方。 在 SQL Server 上執行此 T-SQL 指令碼:

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

然後,在 SQL Server 上產生驗證憑證。 在下列指令碼中,取代:

  • @cert_expiry_date 取代為所需憑證到期日 (未來日期)。

記錄此日期並設定提醒,以便在 SQL Server 憑證到期日期之前輪替 (更新),確保連結能夠持續作業。

重要

強烈建議您使用從此指令碼自動產生的憑證名稱。 雖然允許在 SQL Server 上自訂您自己的憑證名稱,但此名稱不應包含任何 \ 字元。

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

然後,在 SQL Server 上使用下列 T-SQL 查詢來確認已建立憑證:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

在查詢結果中,您會看到該憑證已使用主要金鑰進行加密。

現在,您可以取得 SQL Server 上所產生憑證的公開金鑰:

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

儲存輸出中的 SQLServerCertNameSQLServerPublicKey 值,因為您將在下一個步驟匯入憑證時需要這項資訊。

首先,請確定您已登入 Azure,並已選取裝載受控執行個體的訂用帳戶。 如果您的帳戶有多個 Azure 訂用帳戶,選取正確的訂用帳戶特別重要。

<SubscriptionID> 取代為您的 Azure 訂用帳戶 ID。

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

然後使用 New-AzSqlInstanceServerTrustCertificate PowerShell 或 az sql mi partner-cert create Azure CLI 命令,將驗證憑證的公開金鑰從 SQL Server 上傳至 Azure,例如下列 PowerShell 範例。

填寫必要的使用者資訊,複製、貼上這些資訊,然後執行指令碼。 將:

  • <SQLServerPublicKey> 取代為二進位格式的 SQL Server 憑證公開部分,這是您在上一個步驟中記錄的資訊。 這是開頭為 0x 的長字串值。
  • <SQLServerCertName> 取代為您在上一個步驟中記錄的 SQL Server 憑證名稱。
  • <ManagedInstanceName> 取代為您的受控執行個體簡短名稱。
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded 

此作業的結果會是已上傳至 Azure 的 SQL Server 憑證摘要。

如果需要查看上傳至受控執行個體的所有 SQL Server 憑證,請在 Azure Cloud Shell 中使用 Get-AzSqlInstanceServerTrustCertificate PowerShell 或 az sql mi partner-cert list Azure CLI 命令。 若要移除上傳至 SQL 受控執行個體的 SQL Server 憑證,請在 Azure Cloud Shell 中使用 Remove-AzSqlInstanceServerTrustCertificate PowerShell 或 az sql mi partner-cert delete Azure CLI 命令。

從 SQL 受控執行個體取得憑證公開金鑰,並將其匯入至 SQL Server

保護連結端點的憑證會在 Azure SQL 受控執行個體上自動產生。 從 SQL 受控執行個體取得憑證公開金鑰,並使用 Get-AzSqlInstanceEndpointCertificate PowerShell 或 az sql mi endpoint-cert show Azure CLI 命令將其匯入 SQL Server,例如下列 PowerShell 範例。

警告

使用 Azure CLI 時,您若在後續步驟中使用 PublicKey 輸出,必須手動新增 0x 至 PublicKey 輸出的前端。 例如,PublicKey 看起來會像 “0x3082033E30...”。

執行下列指令碼。 將:

  • <SubscriptionID> 取代為您的 Azure 訂閱識別碼。
  • <ManagedInstanceName> 取代為您的受控執行個體簡短名稱。
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string   

複製整個 PublicKey 輸出 (以 0x 開頭),因為您將在下個步驟中需要這項資訊。

或者,如果您在複製並貼上公開金鑰時遇到問題,您也可以在受控執行個體上執行 T-SQL 命令 EXEC sp_get_endpoint_certificate 4,以取得連結端點的公開金鑰。

接下來,將所取得受控執行個體安全性憑證的公開金鑰匯入至 SQL Server。 在 SQL Server 上執行下列查詢,以建立 MI 端點憑證。 將:

  • <ManagedInstanceFQDN> 取代為受控執行個體的完整網域名稱。
  • <PublicKey> 取代為您在上一個步驟中取得的 PublicKey 值 (從 Azure Cloud Shell 取得,以 0x 開頭)。 您不需要使用引號。

重要

憑證的名稱必須是 SQL 受控執行個體 FQDN,且不應修改。 如果使用自訂名稱,連結將無法運作。

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey> 

將 Azure 信任的根憑證授權單位金鑰匯入至 SQL Server

您必須將 Microsoft 和 DigiCert 憑證授權單位 (CA) 的公開根憑證金鑰匯入至 SQL Server,您的 SQL Server 才能信任 Azure 針對 database.windows.net 網域所核發的憑證。

警告

確定 PublicKey 以 0x 開頭。 如果還沒有,您可能需要手動將其新增至 PublicKey 的開頭。

首先,在 SQL Server 上匯入 Microsoft PKI 根授權認證:

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3300D06092A864886F70D01010C05003065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F726974792032303137301E170D3139313231383232353132325A170D3432303731383233303032335A3065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F72697479203230313730820222300D06092A864886F70D01010105000382020F003082020A0282020100CA5BBE94338C299591160A95BD4762C189F39936DF4690C9A5ED786A6F479168F8276750331DA1A6FBE0E543A3840257015D9C4840825310BCBFC73B6890B6822DE5F465D0CC6D19CC95F97BAC4A94AD0EDE4B431D8707921390808364353904FCE5E96CB3B61F50943865505C1746B9B685B51CB517E8D6459DD8B226B0CAC4704AAE60A4DDB3D9ECFC3BD55772BC3FC8C9B2DE4B6BF8236C03C005BD95C7CD733B668064E31AAC2EF94705F206B69B73F578335BC7A1FB272AA1B49A918C91D33A823E7640B4CD52615170283FC5C55AF2C98C49BB145B4DC8FF674D4C1296ADF5FE78A89787D7FD5E2080DCA14B22FBD489ADBACE479747557B8F45C8672884951C6830EFEF49E0357B64E798B094DA4D853B3E55C428AF57F39E13DB46279F1EA25E4483A4A5CAD513B34B3FC4E3C2E68661A45230B97A204F6F0F3853CB330C132B8FD69ABD2AC82DB11C7D4B51CA47D14827725D87EBD545E648659DAF5290BA5BA2186557129F68B9D4156B94C4692298F433E0EDF9518E4150C9344F7690ACFC38C1D8E17BB9E3E394E14669CB0E0A506B13BAAC0F375AB712B590811E56AE572286D9C9D2D1D751E3AB3BC655FD1E0ED3740AD1DAAAEA69B897288F48C407F852433AF4CA55352CB0A66AC09CF9F281E1126AC045D967B3CEFF23A2890A54D414B92AA8D7ECF9ABCD255832798F905B9839C40806C1AC7F0E3D00A50203010001A3543052300E0603551D0F0101FF040403020186300F0603551D130101FF040530030101FF301D0603551D0E0416041409CB597F86B2708F1AC339E3C0D9E9BFBB4DB223301006092B06010401823715010403020100300D06092A864886F70D01010C05000382020100ACAF3E5DC21196898EA3E792D69715B813A2A6422E02CD16055927CA20E8BAB8E81AEC4DA89756AE6543B18F009B52CD55CD53396D624C8B0D5B7C2E44BF83108FF3538280C34F3AC76E113FE6E3169184FB6D847F3474AD89A7CEB9D7D79F846492BE95A1AD095333DDEE0AEA4A518E6F55ABBAB59446AE8C7FD8A2502565608046DB3304AE6CB598745425DC93E4F8E355153DB86DC30AA412C169856EDF64F15399E14A75209D950FE4D6DC03F15918E84789B2575A94B6A9D8172B1749E576CBC156993A37B1FF692C919193E1DF4CA337764DA19FF86D1E1DD3FAECFBF4451D136DCFF759E52227722B86F357BB30ED244DDC7D56BBA3B3F8347989C1E0F20261F7A6FC0FBB1C170BAE41D97CBD27A3FD2E3AD19394B1731D248BAF5B2089ADB7676679F53AC6A69633FE5392C846B11191C6997F8FC9D66631204110872D0CD6C1AF3498CA6483FB1357D1C1F03C7A8CA5C1FD9521A071C193677112EA8F880A691964992356FBAC2A2E70BE66C40C84EFE58BF39301F86A9093674BB268A3B5628FE93F8C7A3B5E0FE78CB8C67CEF37FD74E2C84F3372E194396DBD12AFBE0C4E707C1B6F8DB332937344166DE8F4F7E095808F965D38A4F4ABDE0A308793D84D00716245274B3A42845B7F65B76734522D9C166BAAA8D87BA3424C71C70CCA3E83E4A6EFB701305E51A379F57069A641440F86B02C91C63DEAAE0F84

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exists.'
GO

然後,在 SQL Server 上匯入 DigiCert PKI 根授權憑證:

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D09FAE5300D06092A864886F70D01010B05003061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F74204732301E170D3133303830313132303030305A170D3338303131353132303030305A3061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F7420473230820122300D06092A864886F70D01010105000382010F003082010A0282010100BB37CD34DC7B6BC9B26890AD4A75FF46BA210A088DF51954C9FB88DBF3AEF23A89913C7AE6AB061A6BCFAC2DE85E092444BA629A7ED6A3A87EE054752005AC50B79C631A6C30DCDA1F19B1D71EDEFDD7E0CB948337AEEC1F434EDD7B2CD2BD2EA52FE4A9B8AD3AD499A4B625E99B6B00609260FF4F214918F76790AB61069C8FF2BAE9B4E992326BB5F357E85D1BCD8C1DAB95049549F3352D96E3496DDD77E3FB494BB4AC5507A98F95B3B423BB4C6D45F0F6A9B29530B4FD4C558C274A57147C829DCD7392D3164A060C8C50D18F1E09BE17A1E621CAFD83E510BC83A50AC46728F67314143D4676C387148921344DAF0F450CA649A1BABB9CC5B1338329850203010001A3423040300F0603551D130101FF040530030101FF300E0603551D0F0101FF040403020186301D0603551D0E041604144E2254201895E6E36EE60FFAFAB912ED06178F39300D06092A864886F70D01010B05000382010100606728946F0E4863EB31DDEA6718D5897D3CC58B4A7FE9BEDB2B17DFB05F73772A3213398167428423F2456735EC88BFF88FB0610C34A4AE204C84C6DBF835E176D9DFA642BBC74408867F3674245ADA6C0D145935BDF249DDB61FC9B30D472A3D992FBB5CBBB5D420E1995F534615DB689BF0F330D53E31E28D849EE38ADADA963E3513A55FF0F970507047411157194EC08FAE06C49513172F1B259F75F2B18E99A16F13B14171FE882AC84F102055D7F31445E5E044F4EA879532930EFE5346FA2C9DFF8B22B94BD90945A4DEA4B89A58DD1B7D529F8E59438881A49E26D56FADDD0DC6377DED03921BE5775F76EE3C8DC45D565BA2D9666EB33537E532B6

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exists.'
GO

最後,使用下列動態管理檢視 (DMV) 來確認所有建立的憑證:

-- Run on SQL Server
SELECT * FROM sys.certificates

驗證憑證

建立憑證之後,驗證 MI 端點憑證已正確設定。

首先,判斷匯出 MI 憑證的 certificate_id,方式是取代 <ManagedInstanceFQDN> 的值,然後在 SQL Server 上執行下列查詢:

-- Run on SQL Server 
USE MASTER 
GO 

SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

接下來,驗證憑證,方式是取代上一個查詢結果中的 <certificate_id> 值,然後在 SQL Server 上執行下列查詢:

-- Run on SQL Server 

USE MASTER 
GO 

EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Commands completed successfully. Completion time: … 的回應表示 MI 端點憑證已成功驗證。

如果您遇到錯誤,請卸除憑證,然後遵循從 SQL 受控執行個體取得憑證公開金鑰,並將其匯入至 SQL Server 一節中的步驟,以重新匯入憑證。

若要卸除憑證,請在 SQL Server 上執行下列查詢:

-- Run on SQL Server 

USE MASTER 
GO 

DROP CERTIFICATE [<ManagedInstanceFQDN>] 
GO 

保護資料庫鏡像端點

如果您在 SQL Server 上沒有現有的可用性群組或資料庫鏡像端點,則下一個步驟是在 SQL Server 上建立資料庫鏡像端點,並使用先前產生的 SQL Server 憑證進行保護。 如果您確實有現有的可用性群組或鏡像端點,請跳至更改現有的端點一節。

在 SQL Server 上建立及保護資料庫鏡像端點

若要確認您尚未建立現有的資料庫鏡像端點,請使用下列指令碼:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

如果先前的查詢未顯示現有資料庫的鏡像端點,請在 SQL Server 上執行下列指令碼,取得先前產生的 SQL Server 憑證名稱。

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

儲存來自輸出的 SQLServerCertName,因為您將在下一個步驟中需要這項資訊。

使用下列指令碼在連接埠 5022 上建立新的資料庫鏡像端點,並使用 SQL Server 憑證保護該端點。 將:

  • <SQL_SERVER_CERTIFICATE> 取代為您在上一個步驟中取得的 SQLServerCertName 名稱。
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

在 SQL Server 上執行下列指令碼來驗證已建立鏡像端點:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

成功建立的端點 state_desc 資料行應處於 STARTED 狀態。

已建立新的鏡像端點,並啟用憑證驗證和 AES 加密。

更改現有的端點

注意

如果您剛建立新的鏡像端點,請略過此步驟。 只有在要搭配現有的資料庫鏡像端點使用現有的可用性群組時,才使用此步驟。

如果您針對連結使用現有的可用性群組,或如果有現有的資料庫鏡像端點,請先驗證其符合連結的下列必要條件:

  • 類型必須是 DATABASE_MIRRORING
  • 連線驗證必須是 CERTIFICATE
  • 必須啟用加密。
  • 加密演算法必須是 AES

在 SQL Server 上執行下列查詢,檢視現有資料庫鏡像端點的詳細資料:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

如果輸出顯示現有 DATABASE_MIRRORING 端點的 connection_auth_desc 不是 CERTIFICATE 或 encryption_algorthm_desc 不是 AES,則「必須更改端點以符合需求」。

在 SQL Server 上,會針對可用性群組和分散式可用性群組使用相同的資料庫鏡像端點。 如果您的 connection_auth_desc 端點是 NTLM (Windows 驗證) 或 KERBEROS,而且需要對現有的可用性群組使用 Windows 驗證,則可以將驗證選項切換為 NEGOTIATE CERTIFICATE,藉此更改端點以使用多個驗證方法。 這項變更可讓現有的可用性群組使用 Windows 驗證,同時對 SQL 受控執行個體使用憑證驗證。

同樣地,如果加密不包含 AES,而且您需要 RC4 加密,則可以更改端點以使用這兩種演算法。 如需更改端點的可能選項詳細資料,請參閱 sys.database_mirroring_endpoints 的文件頁面

下列指令碼示範如何更改 SQL Server 上的現有資料庫鏡像端點。 將:

  • <YourExistingEndpointName> 取代為您現有的端點名稱。
  • <SQLServerCertName> 取代為已產生的 SQL Server 憑證名稱 (在上述先前的步驟之一中取得)。

根據您的特定設定,您可能需要進一步自訂指令碼。 您也可以使用 SELECT * FROM sys.certificates 來取得 SQL Server 上建立的憑證名稱。

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

執行 ALTER 端點查詢並將雙重驗證模式設定為 Windows 和憑證之後,請在 SQL Server 上再次使用此查詢來顯示資料庫鏡像端點的詳細資料:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

您已成功修改 SQL 受控執行個體連結的資料庫鏡像端點。

在 SQL Server 上建立可用性群組

如果您沒有現有的可用性群組,下一個步驟是在 SQL Server 上建立一個,不論其是否將為初始主要複本。

注意

如果您的來源執行個體已經有已存在的可用性群組,請略過本節。

如果您的 SQL 受控執行個體是初始主要複本 (從 SQL Server 2022 CU10 才開始支援),則建立可用性群組的命令會有所不同。

雖然可以為同一個資料庫建立多個連結,但連結只支援每個連結複寫一個資料庫。 如果您想要為相同資料庫建立多個連結,請針對所有連結使用相同的可用性群組,然後針對 SQL Server 與 SQL 受控執行個體之間的每個資料庫連結建立新的分散式可用性群組。

如果 SQL Server 是您的初始主要複本,請為連結建立具有下列參數的可用性群組:

  • 初始主要伺服器名稱
  • 資料庫名稱
  • MANUAL 的容錯移轉模式
  • AUTOMATIC 的植入模式

首先,執行下列 T-SQL 陳述式來查明您的 SQL Server 名稱:

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName 

然後,使用下列指令碼在 SQL Server 上建立可用性群組。 將:

  • <AGNameOnSQLServer> 取代為 SQL Server 上的可用性群組名稱。 受控執行個體連結針對每個可用性群組需要一個資料庫。 針對多個資料庫,您必須建立多個可用性群組。 請考慮命名每個可用性群組,使其名稱反映對應的資料庫 (例如 AG_<db_name>)。
  • <DatabaseName> 取代為您要複寫的資料庫名稱。
  • <SQLServerName> 取代為您在上一個步驟中取得的 SQL Server 執行個體名稱。
  • <SQLServerIP> 取代為 SQL Server IP 位址。 您可以使用可解析的 SQL Server 主機電腦名稱作為替代名稱,但必須確定該名稱可從 SQL 受控執行個體虛擬網路進行解析。
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

重要

若是 SQL Server 2016,請從上述 T-SQL 陳述句中刪除 WITH (CLUSTER_TYPE = NONE)。 若是其他較新 SQL Server 版本,則保持原樣。

接下來,在 SQL Server 上建立分散式可用性群組。 如果您計劃建立多個連結,則即使您是為同一個資料庫建立多個連結,也需要為每個連結建立一個分散式可用性群組。

取代下列值,然後執行 T-SQL 指令碼來建立分散式可用性群組。

  • <DAGName> 取代為您的分散式可用性群組名稱。 由於您可以透過為每個連結建立一個分散式可用性群組來為同一個資料庫設定多個連結,因此請考慮據此命名每個分散式可用性群組,例如 DAG1_<db_name>DAG2_<db_name>
  • <AGNameOnSQLServer> 取代為您在上一個步驟中建立的可用性群組名稱。
  • <AGNameOnSQLMI> 取代為 SQL 受控執行個體上的可用性群組名稱。 此名稱在 SQL MI 每個區域中必須是唯一的。 請考慮命名每個可用性群組,使其名稱反映對應的資料庫 (例如 AG_<db_name>_MI)。
  • <SQLServerIP> 取代為上一個步驟中 SQL Server 的 IP 位址。 您可以使用可解析的 SQL Server 主機電腦名稱作為替代名稱,但請確定該名稱可以從 SQL 受控執行個體虛擬網路解析 (需要針對受控執行個體的子網路設定自訂 Azure DNS)。
  • <ManagedInstanceName> 取代為您的受控執行個體簡短名稱。
  • <ManagedInstanceFQDN> 取代為您的 SQL 受控執行個體完整網域名稱。
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<AGNameOnSQLMI>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

驗證可用性群組

使用下列指令碼,列出 SQL Server 執行個體上的所有可用性群組和分散式可用性群組。 此時,可用性群組的狀態必須是 connected,而分散式可用性群組的狀態必須是 disconnected。 分散式可用性群組只有在已與 SQL 受控執行個體聯結時,其狀態才會變成 connected

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

或者,您可以使用 SSMS 物件總管來尋找可用性群組和分散式可用性群組。 展開 [Always On 高可用性] 資料夾,然後展開 [可用性群組] 資料夾。

最後,您可以建立連結。 命令會依據作為初始主要複本的執行個體而有所不同。 使用 New-AzSqlInstanceLink PowerShell 或 az sql mi link create Azure CLI 命令來建立連結,例如本節中的 PowerShell 範例。 Azure CLI 目前不支援從 SQL 受控執行個體主要複本建立連結。

如果您需要查看受控執行個體上的所有連結,請在 Azure Cloud Shell 中使用 Get-AzSqlInstanceLink PowerShell 或 az sql mi link show Azure CLI 命令。

為簡化此程序,請登入 Azure 入口網站,並從 Azure Cloud Shell 執行下列指令碼。 將:

  • <ManagedInstanceName> 取代為您的受控執行個體簡短名稱。
  • <AGNameOnSQLServer> 取代為 SQL Server 上建立的可用性群組名稱。
  • <AGNameOnSQLMI> 取代為 SQL 受控執行個體上建立的可用性群組名稱。
  • <DAGName> 取代為 SQL Server 上建立的分散式可用性群組名稱。
  • <DatabaseName> 取代為 SQL Server 可用性群組中複寫的資料庫。
  • <SQLServerIP> 取代為您 SQL Server 的 IP 位址。 提供的 IP 位址必須可由受控執行個體存取。

注意

如果您想要建立已存在的可用性群組連結,請在提供 <SQLServerIP> 參數時提供接聽程式的IP位址。

#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGNameOnSQLServer -SecondaryAvailabilityGroupName $AGNameOnSQLMI |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

此作業的結果會是建立連結要求成功執行的時間戳記。

若要確認 SQL 受控執行個體與 SQL Server 之間的連線,請在 SQL Server 上執行下列查詢。 連線不是即時作業。 DMV 最多可能需要一分鐘的時間才會開始顯示成功的連線。 請持續重新整理 DMV,直到 SQL 受控執行個體複本的連線顯示為 CONNECTED 為止。

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

建立連線之後,在初始植入階段移動和還原資料庫的完整備份時,SSMS 中的 [物件總管] 可能一開始會在處於 [還原中] 狀態的次要複本上顯示複寫的資料庫。 還原資料庫之後,複寫必須更新以讓兩個資料庫處於同步狀態。 初始植入完成之後,資料庫將不再處於 [還原中] 狀態。 植入小型資料庫的速度,可能會快到讓您無法在 SSMS 中看到初始 [還原中] 狀態。

重要

  • 除非 SQL Server 與 SQL 受控執行個體之間存在網路連線,否則連結將無法運作。 若要針對網路連線進行疑難排解,請執行測試網路連線中的步驟。
  • 在 SQL Server 上定期備份記錄檔。 如果使用的記錄空間達到 100%,在降低使用的空間之前,會停止複寫到 SQL 受控執行個體。 強烈建議您藉由設定每日作業來自動執行記錄備份。 如需詳細資料,請參閱備份 SQL Server 上的記錄檔

進行第一個交易記錄備份

如果 SQL Server 是初始主要複本,當 Azure SQL 受控執行個體上的資料庫不再處於正在還原...狀態時,在初始植入完成之後,請務必在 SQL Server 上進行第一個交易記錄備份。 然後定期進行 SQL Server 交易記錄備份,以在 SQL Server 處於主要角色時,將過多的記錄成長降至最低。

如果 SQL 受控執行個體是主要複本,您不需要採取任何動作,因為 Azure SQL 受控執行個體會自動進行記錄備份。

如果您想卸除連結,可能是因為不再需要連結,或因為連結處於無法修復的狀態且需要重新建立連結,您可以使用 PowerShell 和 T-SQL 來執行此動作。

首先,使用 Remove-AzSqlInstanceLink PowerShell 命令卸除連結,類似以下範例:

Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force 

然後,執行下列 T-SQL 指令碼在 SQL Server 上卸除分散式可用性群組。 使用分散式可用性群組 (用來建立連結的群組) 的名稱取代 <DAGName>

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO 

最後,如果您不再使用可用性群組,您可以選擇移除它。 若執行此動作,請使用可用性群組的名稱取代 <AGName>,然後在相應執行個體上執行:

DROP AVAILABILITY GROUP <AGName>  
GO 

疑難排解

如果您在建立連結時遇到錯誤訊息,則請檢閱查詢輸出視窗中的錯誤訊息以取得詳細資訊。

若要使用連結:

若要深入了解連結:

針對其他複寫和移轉案例,請考慮: