スクリプト - Azure SQL Managed Instance を使用してリンクを構成する

適用対象: Azure SQL Managed Instance

この記事では、Transact-SQL と PowerShell または Azure CLI スクリプトを使用して SQL Server と Azure SQL Managed Instance の間のリンクを構成する方法について説明します。 リンクを使用すると、初期プライマリのデータベースが準リアルタイムでセカンダリ レプリカにレプリケーションされます。

リンクが作成されたら、移行またはディザスター リカバリーのためにセカンダリ レプリカにフェールオーバーできます。

概要

リンク機能を使用して、最初のプライマリからセカンダリ レプリカにデータベースをレプリケーションします。 SQL Server 2022 の場合、初期プライマリは SQL Server または Azure SQL Managed Instance のいずれかになります。 SQL Server 2019 以前のバージョンの場合、初期プライマリは SQL Server である必要があります。 リンクが構成されると、初期プライマリのデータベースがセカンダリ レプリカにレプリケーションされます。

プライマリ レプリカとセカンダリ レプリカ間のハイブリッド環境での継続的なデータ レプリケーション用のリンクをそのままにするか、データベースをセカンダリ レプリカにフェールオーバーし、Azure に移行したり、ディザスター リカバリーを行ったりするかを選択できます。 SQL Server 2019 以前のバージョンでは、Azure SQL Managed Instance にフェールオーバーするとリンクが切断されます。フェールバックはサポートされていません。 SQL Server 2022 では、リンクを維持して 2 つのレプリカ間で双方向にフェールバックするオプションがあります。

セカンダリ マネージド インスタンスをディザスター リカバリーにのみ使用する場合は、ハイブリッド フェールオーバー特典をアクティブ化することで、ライセンス コストを節約できます。

この記事の手順を使用して、SQL Server と Azure SQL Managed Instance の間のリンクを手動で設定します。 リンクが作成されると、ソースのデータベースはターゲットのセカンダリ レプリカ上の読み取り専用コピーを取得します。

前提条件

データベースをレプリケートするには、次の前提条件を満たす必要があります。

• 有効な Azure サブスクリプション アカウントがない場合は、無料アカウントを作成してください。
• 必要なサービス更新プログラムがインストールされている SQL Server のサポート対象バージョン。
• Azure SQL Managed Instance。 ない場合はこれを開始します。
• PowerShell モジュール Az.SQL 3.9.0 以降、または Azure CLI 2.47.0 以降。 または、Web ブラウザーからオンラインで Azure Cloud Shell を使用してコマンドを実行することをお勧めします。これは、常に最新のモジュール バージョンで更新されているからです。
• 適切に準備された環境。

以下、具体例に沿って説明します。

• リンク機能では、リンクごとに 1 つのデータベースをサポートします。 1 つのインスタンスで複数のデータベースをレプリケートするには、個々のデータベースごとにリンクを作成します。 たとえば、10 個のデータベースを SQL Managed Instance にレプリケートするには、10 個のリンクを作成します。
• 照合順序は、SQL Server と SQL Managed Instance 間で同じにする必要があります。 照合順序が一致していないとサーバー名の大文字と小文字が一致せず、SQL Server から SQL Managed Instance に正常に接続できません。
• 最初の SQL Server プライマリで発生するエラー 1475 は、COPY ONLY オプションを指定せずに完全バックアップを作成することで新しいバックアップ チェーンを開始する必要があることを示します。
• SQL Managed Instance から SQL Server 2022 へのリンクまたはフェールオーバーを確立するには、SQL Server 2022 更新ポリシーを使用して Managed Instance を構成する必要があります。 SQL Managed Instance から SQL Server 2022 へのデータ レプリケーションとフェールオーバーは、Always-up-to-date 更新ポリシーを使用して構成されたインスタンスではサポートされていません。
• SQL Server 2022 から Always-up-to-date 更新ポリシーを使用して構成された SQL Managed Instance へのリンクを確立できますが、SQL Managed Instance にフェールオーバーした後は、データをレプリケートしたり、SQL Server 2022 にフェールバックしたりできなくなります。

アクセス許可

SQL Server の場合、sysadmin アクセス許可が必要です。

Azure SQL Managed Instance の場合、SQL Managed Instance 共同作成者のメンバーであるか、次のカスタム ロールのアクセス許可を持っている必要があります。

用語と名前付け規則

このユーザー ガイドのスクリプトを実行するとき、重要なのは SQL Server や SQL Managed Instance の名前を完全修飾ドメイン名 (FQDN) と間違わないようにすることです。 次の表で、さまざまな名前が正確に表している内容とそれらの値の取得方法を説明します。

¹ Azure SQL Managed Instance を初期プライマリとして構成することがサポートされるのは SQL Server 2022 CU10 移行です。

データベースの復旧とバックアップを設定する

SQL Server が初期プライマリの場合、リンクを介してレプリケートされるすべてのデータベースは、完全復旧モデルであり、少なくとも 1 つのバックアップを持っている必要があります。 Azure SQL Managed Instance はバックアップを自動的に取得するため、SQL Managed Instance が初期プライマリである場合は、この手順をスキップします。

レプリケートするすべてのデータベースに対して、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

詳細については、「データベースの完全バックアップの作成」を参照してください。

インスタンス間の信頼を確立する

まず、2 つのインスタンス間で信頼を確立し、ネットワーク上でのデータの通信と暗号化に使用されるエンドポイントをセキュリティで保護することです。 分散可用性グループでは、独自の専用エンドポイントを持つのではなく、既存の可用性グループのデータベース ミラーリング エンドポイントを使用します。 そのため、可用性グループ データベース ミラーリング エンドポイントを介して 2 つのインスタンス間にセキュリティ (信頼) を構成する必要があります。

証明書ベースの信頼は、SQL Server および SQL Managed Instance のデータベース ミラーリング エンドポイントをセキュリティで保護するためにサポートされている唯一の方法です。 既存の可用性グループが Windows 認証を使用している場合、証明書ベースの信頼を、セカンダリ認証オプションとして既存のミラーリング エンドポイントに追加する必要があります。 これを行うには、この記事で後述するように、ALTER ENDPOINT ステートメントを使用します。

以下に、SQL Server と SQL Managed Instance 両方のデータベース ミラーリング エンドポイントをセキュリティで保護するプロセスの概要を示します。

1. SQL Server で証明書を生成して、その公開キーを取得します。
2. SQL Managed Instance 証明書の公開キーを取得します。
3. 公開キーを SQL Server と SQL Managed Instance との間で交換します。
4. Azure の信頼されたルート証明機関のキーを SQL Server にインポートする

以下のセクションでは、これらの手順について説明します。

SQL Server で証明書を作成し、その公開キーを SQL Managed Instance にインポートします

最初に、master データベースにデータベース マスター キーを作成します (まだ存在しない場合)。 次のスクリプトの <strong_password> の代わりにご自分のパスワードを挿入し、機密情報として安全な場所に保管します。 この T-SQL スクリプトを SQL Server で実行します。

-- 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 サーバー証明書をローテーション (更新) するように自己通知を設定します。

-- 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

次に、次の T-SQL クエリを SQL Server で使用して、証明書が作成されたことを確認します。

-- 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;

出力の SQLServerCertName と SQLServerPublicKey の値を保存します。これは、証明書のインポート時、次の手順で必要になります。

まず、確実に 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 コマンドを使用して、次の PowerShell サンプルなどの認証証明書の公開キーを SQL Server から Azure にアップロードします。

必要なユーザー情報を入力し、コピーして貼り付けてから、スクリプトを実行します。 置換前のコード:

• <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 Managed Instance から証明書公開キーを取得して SQL Server にインポートする

リンクのエンドポイントをセキュリティ保護するための証明書は、Azure SQL Managed Instance 上で自動生成されます。 SQL Managed Instance から証明書の公開キーを取得し、PowerShell コマンド Get-AzSqlInstanceEndpointCertificate、または Azure CLI コマンド az sql mi endpoint-cert show を使用して SQL Server にインポートします。次の PowerShell 例を参照してください。

次のスクリプトを実行します。 置換前のコード:

• <SubscriptionID> は Azure サブスクリプション ID に。
• <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 で始まる) 全体をコピーします。これは、次の手順で必要になります。

または、PublicKey をコピーして貼り付ける際に問題が発生する場合、マネージド インスタンスで T-SQL コマンド EXEC sp_get_endpoint_certificate 4 を実行して、リンクのエンドポイントの公開キーを取得することもできます。

次に、マネージド インスタンス セキュリティ証明書の取得した公開キーを SQL Server にインポートします。 SQL Server で次のクエリを実行して、MI エンドポイント証明書を作成します。 置換前のコード:

• <ManagedInstanceFQDN> を、マネージド インスタンスの完全修飾ドメイン名にする。
• <PublicKey>を、前の手順で (Azure Cloud Shell から) 取得した PublicKey 値 (0x で始まる) にします。 引用符を使用する必要はありません。

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

Azure の信頼されたルート証明機関のキーを SQL Server にインポートする

お使いの SQL Server で、Azure から発行される database.windows.net ドメインの証明書を信頼するには、Microsoft および DigiCert 証明機関 (CA) のパブリック ルート証明書キーを SQL Server にインポートすることが必要です。

まず、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 エンドポイント証明書が正しく構成されていることを検証します。

まず、<ManagedInstanceFQDN> の値を置き換えて、エクスポートされた MI 証明書の certificate_id を確認します。次に、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 Managed Instance から証明書の公開キーを取得して SQL Server にインポートする 」セクションの手順に従って、証明書を再インポートします。

証明書を削除するには、SQL Server で次の SQL クエリを実行します。

-- 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 Managed Instance で証明書認証を使用できるようになります。

同様に、暗号化に AES が含まれておらず、RC4 暗号化を必要とする場合は、両方のアルゴリズムを使用するようにエンドポイントを変更することができます。 エンドポイントを変更するために使用できるオプションの詳細については、sys.database_mirroring_endpoints のドキュメント ページを参照してください

次のスクリプトは、SQL Server 上の既存のデータベース ミラーリング エンドポイントを変更する方法の例です。 置換前のコード:

• <YourExistingEndpointName> は既存のエンドポイント名に。
• <SQLServerCertName>を、生成された SQL Server 証明書の名前 (上記の手順の 1 つで取得) にする。

特定の構成に応じて、スクリプトをさらにカスタマイズすることが必要になる場合があります。 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 Managed Instance リンクのデータベース ミラーリング エンドポイントが正常に変更されました。

SQL Server 上で可用性グループを作成する

既存の可用性グループがない場合は、いずれかが最初の プライマリになるかは関係なく、次の手順で SQL Server に 1 つ作成します。

可用性グループを作成するコマンドは、SQL Managed Instance が初期プライマリであり、SQL Server 2022 CU10 以降でのみサポートされている場合は異なります。

同じデータベースに対して複数のリンクを確立することができますが、リンクはリンクごとに 1 つのデータベースのレプリケーションのみをサポートします。 同じデータベースに複数のリンクを作成する場合は、すべてのリンクに同じ可用性グループを使用しますが、SQL Server と SQL Managed Instance の間のデータベース リンクごとに新しい分散型可用性グループを作成します。

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

-- 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

-- 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

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

-- Run on SQL Server 
-- Create the availability group on SQL Server 

CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>] 
WITH (CLUSTER_TYPE = NONE) 
FOR  
REPLICA ON N'<SQLServerName>' 
WITH ( 
    ENDPOINT_URL = N'TCP://<SQLServerIP>:5022', 
    FAILOVER_MODE = MANUAL, 
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
    SEEDING_MODE = AUTOMATIC); 

GO 

-- Run on SQL Server 
-- Grant permission to the availability group to create databases 

ALTER AVAILABILITY GROUP [<AGNameOnSQLServer>] GRANT CREATE ANY DATABASE; 

-- 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>];Database=[<DatabaseName>]', 
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, 
      FAILOVER_MODE = MANUAL, 
      SEEDING_MODE = AUTOMATIC 
    ); 
GO 

可用性グループを確認する

次のスクリプトを使用して、SQL Server インスタンス上のすべての可用性グループと分散型可用性グループを一覧表示します。 この時点で、可用性グループの状態は connected である必要があり、分散型可用性グループの状態は disconnected である必要があります。 分散型可用性グループの状態は、SQL Managed Instance と結合されたときに初めて 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 高可用性] フォルダー、[可用性グループ] フォルダーの順に展開します。

リンクの作成

ここでようやく、リンクを作成できます。 コマンドは、どのインスタンスが初期プライマリであるかによって異なります。 このセクションの PowerShell の例のように、New-AzSqlInstanceLink PowerShell コマンドまたは az sql mi link create Azure CLI コマンドを使用してリンクを作成します。 SQL Managed Instance プライマリからのリンクの作成は、現在、Azure CLI ではサポートされていません。

マネージド インスタンス上のすべてのリンクを表示する必要がある場合は、Azure Cloud Shell で Get-AzSqlInstanceLink PowerShell コマンド、または az sql mi link show Azure CLI コマンドを使用します。

#  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

#  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>" 

# Enter the Azure subscription ID 
$SubscriptionID = "<SubscriptionID>" 
 
# ==== Do not customize the following cmdlet ==== 

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

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

# Create Azure REST API request header 
$azProfile = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile 
$currentAzureContext = Get-AzContext 
$profileClient = New-Object Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient($azProfile) 
$token = $profileClient.AcquireAccessToken($currentAzureContext.Tenant.TenantId) 
$authToken = $token.AccessToken 
$headers = @{ } 
$headers.Add('Authorization', 'Bearer ' + $authToken)  

# Build Azure REST API URI 
$uri = "https://management.azure.com/subscriptions/"+$SubscriptionID+"/resourceGroups/"+$ResourceGroup+"/providers/Microsoft.Sql/managedInstances/"+$ManagedInstanceName+"/distributedAvailabilityGroups/"+$DAGName+"?api-version=2023-05-01-preview" 

# Build Azure REST API request body 
$body = "{ 
'properties': { 
    'Databases': [{ 
            'databaseName': '$DatabaseName' 
        } 
    ], 
    'PartnerEndpoint': '$DestinationIP', 
    'InstanceAvailabilityGroupName': '$AGNameOnSQLMI', 
    'PartnerAvailabilityGroupName': '$AGNameOnSQLServer', 
    'FailoverMode': 'Manual', 
    'SeedingMode': 'Automatic', 
    'InstanceLinkRole': 'Primary' 

}}" 

 
# Send link creation request to Azure REST API 
Invoke-RestMethod -Method PUT -Headers $headers -Uri $uri -ContentType 'application/json' -Body $body 

この操作の結果は、リンク作成要求が正常に実行されたことを示すタイム スタンプです。

リンクを確認する

SQL Managed Instance と SQL Server の間で接続が確立されたことを確認するには、SQL Server で次のクエリを実行します。 接続は瞬時には行われません。 DMV で接続成功が表示されるまでに最大で 1 分かかることがあります。 SQL Managed Instance のレプリカの接続が [接続済み] と表示されるまで、DMV を更新し続けてください。

-- 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 の オブジェクト エクスプローラーには、当初、レプリケートされたデータベースが [復元しています] の状態でセカンダリ レプリカに表示されます。初期シード処理フェーズでは、データベースの完全バックアップを移動および復元するためです。 データベースが復元されたら、レプリケーションで 2 つのデータベースを同期状態にする必要があります。 初期シード処理が終了すると、データベースは [復元しています] ではなくなります。 小規模なデータベースの場合、シード処理はすぐに済むため、SSMS に初期の [復元しています] の状態が表示されないことがあります。

最初のトランザクション ログ バックアップを実行する

SQL Server が初期プライマリである場合は、初期シード処理が完了した後、つまり Azure SQL Managed Instance 上のデータベースが "復元中..." の状態でなくなったときに、SQL Sever で最初のトランザクション ログ バックアップを実行することが重要です。 その後、SQL Server トランザクション ログ バックアップを定期的に実行し、SQL Server がプライマリ ロールにあるときの過剰なログの増加を最小限に抑えます。

SQL Managed Instance がプライマリである場合は、Azure SQL Managed Instance がログ バックアップを自動的に実行するため、何も行う必要はありません。

リンクを削除する

リンクが不要になった、または回復不可能な状態で再作成する必要があるために、リンクを削除する場合は、PowerShell と T-SQL を使用して削除できます。

まずは次の例のように、Remove-AzSqlInstanceLink PowerShell コマンドを使用して、リンクを削除します。

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

そして、SQL Server で次の T-SQL スクリプトを実行して、分散型可用性グループを削除します。 <DAGName> をリンクの作成に使用した分散型可用性グループの名前に置き換えます。

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO 

最後に、可用性グループを使用しなくなった場合は、必要に応じて削除できます。 これを行うには、<AGName> を可用性グループの名前に置き換え、それぞれのインスタンスで実行します。

DROP AVAILABILITY GROUP <AGName>  
GO 

トラブルシューティング

リンクの作成時にエラー メッセージが表示された場合は、クエリ出力ウィンドウでエラー メッセージの詳細を確認してください。

関連するコンテンツ

リンクを使用するには、次を参照してください。

• Managed Instance リンク用に環境を準備する
• SSMS を使用して SQL Server と SQL Managed Instance の間のリンクを構成する
• リンクをフェールオーバーする
• リンクを使用して移行する
• リンクを維持するためのベスト プラクティス

リンクの詳細については、次を参照してください。

• Managed Instance リンクの概要
• Managed Instance リンクを使用したディザスター リカバリー

他のレプリケーション シナリオについては、以下を検討してください。

• SQL Managed Instance でのトランザクション レプリケーション
• ログ再生サービス (LRS)