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

適用対象:Azure SQL Managed Instance

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

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

注意

概要

リンク機能を使用して、最初のプライマリからセカンダリ レプリカにデータベースをレプリケーションします。 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の間のリンクを手動で設定します。 リンクが作成されると、ソースのデータベースはターゲットのセカンダリ レプリカ上の読み取り専用コピーを取得します。

ヒント

環境に適したパラメーターで T-SQL スクリプトを簡単に使用できるように、SQL Server Management Studio (SSMS) の Managed Instance リンク ウィザードを使用して、リンクを作成するスクリプトを生成することを強くお勧めします。 New Managed Instance ウィンドウSummary ページで、Finish の代わりに Script を選択します。

前提条件

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

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

  • リンク機能では、リンクごとに 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 2025 へのリンクを確立するには、SQL Managed Instance を SQL Server 2025 更新ポリシー で構成する必要があります。 SQL Server 2025 へのデータ レプリケーションとフェールオーバー from SQL Managed Instance は、不一致の更新ポリシーで構成されたインスタンスではサポートされていません。
  • SQL Managed Instance から SQL Server 2022 へのリンクを確立するには、SQL Managed Instance を SQL Server 2022 更新ポリシー で構成する必要があります。 SQL Server 2022 へのデータ レプリケーションとフェールオーバー from SQL Managed Instance は、不一致の更新ポリシーで構成されたインスタンスではサポートされていません。
  • サポートされているバージョンのSQL Serverから、Always-up-to-date 更新ポリシーで構成されたSQL managed instanceへのリンクを確立できますが、SQL Managed Instanceへのフェールオーバー後は、データをレプリケートしたり、SQL Server インスタンスにフェールバックしたりできなくなります。

アクセス許可

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

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

Microsoft。Sql/ リソース 必要な権限
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

用語と名前付け規則

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

用語 説明 探し出す方法
初期プライマリ 1 データベースをセカンダリ レプリカにレプリケートするためのリンクを最初に作成したSQL ServerまたはSQL Managed Instance。
プライマリ レプリカ 現在プライマリ データベースをホストしているSQL ServerまたはSQL Managed Instance。
セカンダリ レプリカ 現在のプライマリ レプリカからほぼリアルタイムでレプリケートされたデータを受信しているSQL ServerまたはSQL Managed Instance。
SQL Server名 短い 1 単語のSQL Server名。 例: sqlserver1 T-SQL から SELECT @@SERVERNAME を実行します。
SQL ServerのFQDN SQL ServerのFQDN(完全修飾ドメイン名)。 例: sqlserver1.domain.com オンプレミスのネットワーク (DNS) 構成を確認するか、Azure仮想マシン (VM) を使用している場合はサーバー名を確認します。
SQL Managed Instance 名 短い 1 単語のSQL Managed Instance名。 例: managedinstance1 Azure ポータルでマネージド インスタンスの名前を確認します。
SQL Managed Instance の FQDN SQL マネージド インスタンスの完全修飾ドメイン名 (FQDN) 例: managedinstance1.6d710bcf372b.database.windows.net Azure ポータルのSQL Managed Instance概要ページでホスト名を確認します。
解決可能なドメイン名 IP アドレスに解決可能な DNS 名。 たとえば、実行中の nslookup sqlserver1.domain.com から、10.0.0.1 などの IP アドレスが返されるはずです。 コマンド プロンプトから nslookup コマンドを実行します。
SQLサーバーのIP SQL Serverの IP アドレス。 SQL Serverに複数の IP がある場合は、Azureからアクセスできる IP アドレスを選択します。 SQL Serverを実行しているホスト OS のコマンド プロンプトから ipconfig コマンドを実行します。

1 初期プライマリとしてのAzure SQL Managed Instanceの構成は、SQL Server 2022 CU10 以降でサポートされています。

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

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

リンクを作成すると、プライマリ レプリカとセカンダリ レプリカの間の初期シード処理が行われます。そのためには、プライマリ レプリカ上のデータベースの完全バックアップを作成し、セカンダリ レプリカに転送し、そこで復元します。 完全バックアップを実行するときは、 WITH CHECKSUM オプションを使用して、バックアップが有効であり、破損していないことを確認することをお勧めします。 詳細については、「BACKUP (Transact-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

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

注意

このリンクでは、ユーザー データベースのレプリケーションのみをサポートしています。 システム データベースのレプリケーションはサポートされていません。 (master または msdb データベースに格納されている) インスタンス レベルのオブジェクトをレプリケートするには、それらのスクリプトを作成し、レプリケート先のインスタンスで T-SQL スクリプトを実行することをお勧めします。

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

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

注意

このリンクは、Always On 可用性グループ テクノロジに基づきます。 データベース ミラーリング エンドポイントの用途は特殊で、可用性グループによって、他のインスタンスからの接続を受信するためにのみ使用されます。 データベース ミラーリング エンドポイントという用語は、従来の SQL Server データベース ミラーリング機能と間違えてはなりません。

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

重要

証明書は、有効期限の日付と時刻を設定して生成します。 有効期限切れになる前に更新とローテーションを行う必要があります。

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

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

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

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

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

重要

このスクリプトから自動生成された証明書名を使用することを強くお勧めします。 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 コマンドのいずれかを使用して、次の 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 powerShell または az sql mi endpoint-cert show Azure CLI コマンドを使用してSQL Serverにインポートします。

注意事項

Azure CLIを使用する場合は、後の手順で使用するときに、PublicKey 出力の先頭に 0x を手動で追加する必要があります。 たとえば、PublicKey は "0x3082033E30.." のようになります。

次のスクリプトを実行します。 置換してください。

  • Azure サブスクリプション ID を<SubscriptionID>に置き換えてください。
  • <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 の値を <PublicKey> に設定します (Azure Cloud Shell で 0x から始まります)。 引用符を使用する必要はありません。

重要

証明書の名前はSQL Managed Instance FQDN である必要があり、変更しないでください。 カスタム名を使用すると、リンクは動作しなくなります。

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

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

Azure信頼されたルート証明機関 (CA) キーをSQL Serverにインポートすることは、SQL ServerがAzureによって発行されたSQL Managed Instance公開キー証明書を信頼するために必要です。

必要なルート CA キーは、Azure証明機関の詳細からダウンロードできます。 少なくとも、DigiCert Global Root G2 および Microsoft RSA Root Certificate Authority 2017 証明書をダウンロードし、SQL Server インスタンスにインポートします。 ただし、数か月以上リンクを実行する予定の場合は、「Root Certificate Authorities」セクションに記載されている 7 つの証明書をすべてダウンロードしてインポートし、信頼された CA リストAzure更新した場合に中断が発生しないようにします。

注意

SQL Managed Instance公開キー証明書の証明書パスのルート証明書は、Azure信頼されたルート証明機関 (CA) によって発行されます。 特定のルート CA は、Azure が信頼された CA リストを更新する時、時間の経過とともに変化する可能性があります。 セットアップを簡略化するために、Azure ルート証明機関に記載されているすべてのルート CA 証明書をインストールします。 以前にインポートしたSQL Managed Instance公開キーの発行者を識別することで、必要な CA キーのみをインストールできます。

サンプルの C:\Path\To\<name of certificate>.crt パスなど、SQL Server インスタンスにローカルに証明書を保存し、次のTransact-SQL スクリプトを使用してそのパスから証明書をインポートします。 <name of certificate> を、DigiCert Global Root G2Microsoft RSA Root Certificate Authority 2017 などの実際の証明書名に置き換えます。

-- Run on SQL Server
-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'<name of certificate>')
BEGIN
    PRINT 'Creating <name of certificate> certificate.'
    CREATE CERTIFICATE [<name of certificate>] FROM FILE = 'C:\Path\To\<name of certificate>.crt'

    --Trust certificates issued by <name of certificate> root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('<name of certificate>')
    --For government cloud, use the corresponding SQL Database DNS suffix, e.g. '*.database.usgovcloudapi.net', '*.database.chinacloudapi.cn' etc.
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate <name of certificate> already exists.'
GO

注意

SQL Server環境に存在しない sp_certificate_add_issuer ストアド プロシージャは、SQL Server インスタンスに appropriate サービス更新プログラムがインストールされていないことを示します

最後に、次の動的管理ビュー (DMV) を使用して、作成されたすべての証明書を確認します。

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

証明書チェーンを検証する

証明書に対するスケジュールされた変更や意図しない変更により、リンクが低下する可能性があります。 中断を回避するには、SQL Serverで証明書チェーンを定期的に検証することが重要です。

前のセクションで説明したように、新しいリンクを構成している場合、または最近証明書をインポートした場合は、この手順をスキップします。

データベース ミラーリング エンドポイントをセキュリティで保護する

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 の値を保存します。これは、次の手順で必要になります。

次のスクリプトを使用して、ポート <EndpointPort> に新しいデータベース ミラーリング エンドポイントを作成し、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=<EndpointPort>, 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_descCERTIFICATE でないか、または encryption_algorithm_descAES でないことが出力に示されている場合、"要件を満たすようにエンドポイントを変更する必要があります"。

SQL Serverでは、可用性グループと分散型可用性グループの両方に同じデータベース ミラーリング エンドポイントが使用されます。 connection_auth_desc エンドポイントが NTLM (Windows authentication) または KERBEROS であり、既存の可用性グループに対してWindows authenticationが必要な場合は、認証オプションを NEGOTIATE CERTIFICATE に切り替えることで、複数の認証方法を使用するようにエンドポイントを変更できます。 この変更により、既存の可用性グループはWindows authenticationを使用しながら、SQL Managed Instanceに証明書認証を使用できるようになります。

同様に、暗号化に 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=<EndpointPort>, 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で作成します。

注意

既に可用性グループがある場合は、このセクションをスキップしてください。

可用性グループを作成するコマンドは、SQL Managed Instanceが初期プライマリであり、SQL Server 2022 CU10

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

SQL Serverが初期プライマリの場合は、リンクの次のパラメーターを使用して可用性グループを作成します。

  • 初期プライマリ サーバー名
  • データベース名
  • MANUAL のフェールオーバー モード
  • AUTOMATIC のシード処理モード

まず、次の T-SQL ステートメントを実行して、SQL Server名を確認します。

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

次に、次のスクリプトを使用して、SQL Serverに可用性グループを作成します。 置換してください。

  • <AGNameOnSQLServer>、SQL Serverの可用性グループの名前を指定します。 Managed Instance リンクには、可用性グループごとに 1 つのデータベースが必要です。 データベースが複数ある場合は、複数の可用性グループを作成する必要があります。 各可用性グループに付ける名前を、対応するデータベースを反映する名前 (例: AG_<db_name>) にすることを検討してください。
  • <DatabaseName> はレプリケートするデータベースの名前に。
  • <SQLServerName>前の手順で取得したSQL Server インスタンスの名前を指定します。
  • SQL Server IP アドレスを持つ <SQLServerIP>。 代わりに解決可能なSQL Serverホスト コンピューター名を使用できますが、SQL Managed Instance仮想ネットワークから名前が解決可能であることを確認する必要があります。
-- 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>:<EndpointPort>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

重要

SQL Server 2016 の場合は、上記の T-SQL ステートメントから WITH (CLUSTER_TYPE = NONE) を削除します。 以降のすべてのSQL Serverバージョンについては、as-is のままにします。

次に、SQL Serverで分散型可用性グループを作成します。 複数のリンクを作成する場合は、同じデータベースに複数のリンクを確立している場合でも、リンクごとに分散型可用性グループを作成する必要があります。

次の値を置き換え、T-SQL スクリプトを実行して分散型可用性グループを作成します。

  • <DAGName> に分散型可用性グループの名前を設定します。 各リンクに分散型可用性グループを作成することで、同じデータベースに複数のリンクを構成できるため、それに応じて各分散型可用性グループに名前を付けることを検討します (例: DAG1_<db_name>DAG2_<db_name>)。
  • <AGNameOnSQLServer> は前の手順で作成した可用性グループの名前に。
  • <AGNameOnSQLMI>、SQL Managed Instanceの可用性グループの名前を指定します。 名前は SQL MI ごとに一意である必要があります。 各可用性グループに付ける名前を、対応するデータベースを反映する名前 (例: AG_<db_name>_MI) にすることを検討してください。
  • <SQLServerIP>前の手順のSQL Serverの IP アドレスを指定します。 代わりに解決可能なSQL Serverホスト コンピューター名を使用できますが、名前がSQL Managed Instance仮想ネットワークから解決可能であることを確認します (マネージド インスタンスのサブネット用にカスタム Azure DNSを構成する必要があります)。
  • <ManagedInstanceName> をマネージド インスタンスの短縮名とします。
  • <ManagedInstanceFQDN> を使用して、マネージド インスタンスの完全修飾ドメイン名を指定します。
-- 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>:<EndpointPort>',
      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 である必要があります。 分散型可用性グループの状態が connected に移行するのは、SQL Managed Instanceに参加した後だけです。

-- 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 Object Explorerを使用して、可用性グループと分散型可用性グループを検索することもできます。 [Always On 高可用性] フォルダー、[可用性グループ] フォルダーの順に展開します。

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

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

プロセスを簡略化するには、Azure ポータルにサインインし、Azure Cloud Shellから次のスクリプトを実行します。 置換してください。

  • <ManagedInstanceName> をマネージド インスタンスの短縮名とします。
  • <AGNameOnSQLServer>、SQL Serverに作成された可用性グループの名前を指定します。
  • <AGNameOnSQLMI>、SQL Managed Instance に作成された可用性グループの名前を指定します。
  • <DAGName>、SQL Serverに作成された分散型可用性グループの名前を指定します。
  • SQL Serverの可用性グループにレプリケートされたデータベースと<DatabaseName>を使用します。
  • SQL ServerのIPアドレスに<SQLServerIP>を置き換えてください。 マネージド インスタンスから、指定する IP アドレスにアクセスできる必要があります。

注意

既に存在する可用性グループへのリンクを確立する場合は、 <SQLServerIP> パラメーターを指定するときにリスナーの IP アドレスを指定します。 すべての可用性グループ ノードとSQL Managed Instanceの間で信頼が確立されていることを確認してください (「インスタンス間の信頼の確立」セクションを参照してください)。

#  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 + ":<EndpointPort>"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $SourceIP -InstanceLinkRole Secondary

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

SQL Managed InstanceとSQL Serverの間の接続を確認するには、SQL Serverで次のクエリを実行します。 接続は瞬時には行われません。 DMV で接続成功が表示されるまでに最大で 1 分かかることがあります。 SQL Managed Instance レプリカの接続が CONNECTED と表示されるまで、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 のObject Explorerは、最初のシードフェーズでデータベースの完全バックアップが移動および復元されるときに、Restoring 状態のセカンダリ レプリカ上のレプリケートされたデータベースを最初に表示することがあります。 データベースが復元されたら、レプリケーションで 2 つのデータベースを同期状態にする必要があります。 初期シード処理が終了すると、データベースは復元状態が解除されます。 小規模なデータベースの場合、シード処理はすぐに済むため、SSMS に初期の [復元しています] の状態が表示されないことがあります。

重要

  • SQL ServerとSQL Managed Instanceの間にネットワーク接続が存在しない限り、リンクは機能しません。 ネットワーク接続のトラブルシューティングを行うには、「ネットワーク接続をテストする」の手順に従ってください。
  • SQL Serverでログ ファイルの定期的なバックアップを作成します。 使用されるログ領域が 100% に達した場合、SQL Managed Instanceへのレプリケーションは、領域の使用が減るまで停止します。 毎日のジョブを設定して、ログ バックアップを自動化することを強くお勧めします。 詳細については、「 SQL Serverを参照してください。

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

SQL Server が初期のプライマリである場合、データベースの初期シード処理が完了し、Azure SQL Managed Instance 上でデータベースが Restoring... 状態でなくなった後に、最初の トランザクション ログのバックアップを SQL Server で取得することが重要です。 次に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 

トラブルシューティング

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

リンクの使用については、以下を参照してください。

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

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