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

  • [アーティクル]

適用対象:Azure SQL Managed Instance

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

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

Note

  • SQL Server Management Studio (SSMS) を使用してリンクを構成することもできます。
  • 初期プライマリとして Azure SQL Managed Instance を構成することは現在プレビュー段階であり、SQL Server 2022 CU10 以降でのみサポートされています。

概要

リンク機能を使用して、最初のプライマリからセカンダリ レプリカにデータベースをレプリケーションします。 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 リンク ウィザードを使用して、リンクを作成するスクリプトを生成することを強くお勧めします。 [新しい Managed Instance リンク] ウィンドウの [概要] ページで、[完了] ではなく [スクリプト] を選択します。

前提条件

Note

リンクの一部の機能は一般提供されていますが、一部は現在プレビュー段階です。 詳細については、「バージョンのサポート可能性」を確認してください。

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

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

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

アクセス許可

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

用語と名前付け規則

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

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

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

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

Note

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

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

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

Note

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

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

重要

このスクリプトから自動生成される証明書名を使用することを強くお勧めします。 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

次に、次の 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 例を参照してください。

注意

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

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

  • <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 で次のコードを実行します。 置換前のコード:

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

重要

証明書の名前は、SQL Managed Instance (FQDN) でなければならず、変更してはいけません。 カスタム名を使用すると、リンクは動作しなくなります。

-- 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 にインポートすることが必要です。

注意事項

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 = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3

    --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 exsits.'
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 = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D0

    --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 exsits.'
GO

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

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

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

既存の可用性グループがない場合、または 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 暗号化が有効になっています。

既存のエンドポイントを変更する

Note

新しいミラーリングエンドポイントを作成したばかりの場合は、この手順をスキップしてください。 既存の可用性グループと既存のデータベース ミラーリング エンドポイントを使用する場合にのみ、この手順を使用します。

リンクに既存の可用性グループを使用する場合、または既存のデータベース ミラーリング エンドポイントがある場合は、まず、それがリンクに関する次の必須条件を満たしているかどうかを確認します。

  • 種類は 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 の間のデータベース リンクごとに新しい分散型可用性グループを作成します。

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

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

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

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

次に、次のスクリプトを使用して SQL Server に可用性グループを作成します。 置換前のコード:

  • <AGName> は可用性グループの名前に。 Managed Instance リンクでは、可用性グループごとに 1 つのデータベースが必要です。 データベースが複数ある場合は、複数の可用性グループを作成する必要があります。 各可用性グループに付ける名前を、対応するデータベースを反映する名前 (例: AG_<db_name>) にすることを検討してください。
  • <DatabaseName> はレプリケートするデータベースの名前に。
  • <SQLServerName>を、前の手順で取得した SQL Server インスタンスの名前にする。
  • <SQLServerIP> は SQL Server IP アドレスに。 代わりの方法として、解決可能な SQL Server ホスト コンピューター名を使用できますが、その名前が SQL Managed Instance 仮想ネットワークから解決可能であることを確認する必要があります。
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGName>]
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>)。
  • <AGName> は前の手順で作成した可用性グループの名前に。
  • <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'<AGName>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<ManagedInstanceName>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      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 コマンドを使用します。

プロセスを簡単にするには、Azure portal にサインインし、Azure Cloud Shell から次のスクリプトを実行します。 置換前のコード:

  • <ManagedInstanceName> はマネージド インスタンスの短い名前に。
  • <AGName> は SQL Server で作成された可用性グループの名前に。
  • <DAGName> は SQL Server で作成された分散型可用性グループの名前に。
  • <DatabaseName> は SQL Server の可用性グループでレプリケートされたデータベースに。
  • <SQLServerIP> を、お使いの SQL Server の IP アドレスにする。 マネージド インスタンスから、指定する 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
$AGName = "<AGName>"

# 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 $AGName -SecondaryAvailabilityGroupName $ManagedInstanceName |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

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

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

ワークロードを停止する

データベースをセカンダリ レプリカにフェールオーバーするには、まず、メンテナンス時間中にプライマリのアプリケーション ワークロードを停止します。 これにより、データベース レプリケーションはセカンダリに追いつくことができるため、データを失うことなく Azure に移行またはフェールオーバーできます。 プライマリ データベースは Always On 可用性グループに含まれていますが、読み取り専用モードに設定することはできません。 フェールオーバーの前に、アプリケーションがプライマリ レプリカにトランザクションをコミットしていないことを確認する必要があります。

レプリケーション モードを切り替える

既定では、SQL Server と SQL Managed Instance の間のレプリケーションは非同期です。 データベースをセカンダリにフェイルオーバーする前に、リンクを同期モードに切り替えます。 ネットワーク距離が大きい同期レプリケーションを行うと、プライマリ レプリカでトランザクションが遅くなる可能性があります。

非同期モードから同期モードに切り替えるには、SQL Managed Instance と SQL Server の両方でレプリケーション モードを変更する必要があります。

レプリケーション モードを切り替える (SQL Managed Instance)

SQL Managed Instance でレプリケーション モードを切り替えるには、Azure PowerShell または Azure CLI を使います。

まず、確実に Azure にログインし、Select-AzSubscription PowerShell コマンドまたは az account set Azure CLI コマンドを使用して Azure CLI マネージド インスタンスがホストされているサブスクリプションを選択しているようにします。 アカウントに複数の Azure サブスクリプションがある場合は、適切なサブスクリプションを選択することが特に重要です。

次の PowerShell サンプルでは、<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

フェールオーバーするリンクの名前がわかっていることを確認します。 Get-AzSqlInstanceLink PowerShell コマンドまたは az sql mi link list Azure CLI コマンドを使用できます。

SQL Managed Instance 上のすべてのアクティブなリンクの一覧を表示するには、次の PowerShell スクリプトを使います。 <ManagedInstanceName> をマネージド インスタンスの短い名前に置き換えます。

# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO LIST ALL LINKS ON MANAGED INSTANCE
# ===== Enter user variables here ====

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

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

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

# List all links on the specified managed instance
Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName

前のスクリプトの出力から、フェールオーバーするリンクの Name プロパティを記録します。

次に、Update-AzSqlInstanceLink PowerShell コマンドまたは az sql mi link update Azure CLI コマンドを使用して、識別されたリンクの SQL Managed Instance でレプリケーション モードを非同期から同期に切り替えます。

次の PowerShell サンプルでは、次のように置き換えます。

  • <ManagedInstanceName> はマネージド インスタンスの短い名前に。
  • <DAGName> は、前の手順で見つかったリンクの名前に (前の手順の Name プロパティ)。
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO SWITCH LINK REPLICATION MODE (ASYNC\SYNC)
# ===== Enter user variables here ====

# Enter the link name 
$LinkName = "<DAGName>"  

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

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

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

# Update replication mode of the specified link
Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName |
-Name $LinkName -ReplicationMode "Sync"

前のコマンドで表示される操作の概要で、プロパティ ReplicationMode が Sync になっていれば、成功したことがわかります。

操作を元に戻す必要がある場合は、前記のスクリプトで -ReplicationMode の文字列 Sync を Async に置き換えて実行し、レプリケーション モードを切り替えます。

レプリケーション モードを切り替える (SQL Server)

SQL Server 上の分散型可用性グループのレプリケーション モードを非同期から同期に変更するには、SQL Server で次の T-SQL スクリプトを使用します。次に置き換えます。

  • <DAGName> は分散型可用性グループの名前に (リンクの作成に使用される)。
  • <AGName> は SQL Server で作成された可用性グループの名前に (リンクの作成に使用される)。
  • <ManagedInstanceName> マネージド インスタンスの名前。
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

リンクのレプリケーション モードが正常に変更されたことを確認するには、次の動的管理ビューを使用します。 結果は SYNCHRONOUS_COMIT 状態を示します。

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

SQL Managed Instance と SQL Server の両方が同期モードに切り替わり、2 つのインスタンス間のレプリケーションが同期されるようになりました。 この状態を元に戻す必要がある場合は、同じ手順を実行し、SQL Server と SQL Managed Instance の両方の状態を async に設定します。

SQL Server と SQL Managed Instance の両方で LSN 値を確認する

フェールオーバーまたは移行を完了するには、レプリケーションが終了していることを確認します。 そのためには、SQL Server と SQL Managed Instance の両方のログ レコードでログ シーケンス番号 (LSN) が同じであることを確認する必要があります。

最初は、プライマリの LSN がセカンダリの LSN よりも高くなると予想されます。 ネットワーク待ち時間が原因で、レプリケーションがプライマリよりも多少遅れる可能性があります。 プライマリのワークロードは停止されているため、LSN が一定期間後に一致し、変更を停止することを想定してください。

SQL Server に対して次の T-SQL クエリを使用し、最後に記録されたトランザクション ログの LSN を読み取ります。 置換前のコード:

  • <DatabaseName> をデータベース名に置き換え、最後に書き込まれた LSN 番号を検索します。
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

SQL Managed Instance に対して次の T-SQL クエリを使用し、データベースの最後に書き込まれた LSN を読み取ります。 <DatabaseName> を、SQL Database の名前に置き換えます。

このクエリは General Purpose の SQL Managed Instance で動作します。 Business Critical の SQL Managed Instance の場合は、スクリプトの最後にある and drs.is_primary_replica = 1 のコメントを解除する必要があります。 Business Critical サービス レベルでは、このフィルターによって、詳細はプライマリ レプリカからのみ読み取られます。

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

または、Get-AzSqlInstanceLink PowerShell コマンドまたは az sql mi link show Azure CLI コマンド を使って、前の T-SQL クエリと同じ情報を提供する SQL Managed Instance 上のリンクの LastHardenedLsn プロパティをフェッチすることもできます。

重要

プライマリでワークロードが停止したことを再度確認します。 SQL Server と Managed Instance SQL の両方で LSN が一致していることを確認し、しばらくの間、一致したまま変更されないことを確認します。 双方のインスタンスの LSN が安定している場合は、末尾のログがセカンダリにレプリケートされており、ワークロードが実質的に停止していることを示します。

データベースのフェールオーバー

PowerShell を使用して、リンクを維持したまま SQL Server 2022 と SQL Managed Instance の間でデータベースをフェールオーバーする場合、または任意のバージョンの SQL Server のデータ損失を伴うフェールオーバーを実行する場合は、SSMS の SQL Server と Managed Instance 間のフェールオーバー ウィザードを使用して、環境のスクリプトを生成します。 プライマリ レプリカまたはセカンダリ レプリカから計画フェールオーバーを実行できます。 強制フェールオーバーを実行するには、セカンダリ レプリカに接続します。

SQL Server のバージョンに関係なく、データベースのフェールオーバーまたは移行時にリンクを中断してレプリケーションを停止するには、Remove-AzSqlInstanceLink PowerShell コマンドまたは az sql mi link delete Azure CLI コマンドを使用します。

注意

  • フェールオーバーする前に、ソース データベースのワークロードを停止して、レプリケートされたデータベースで、データが失われることなく完全にキャッチアップおよびフェールオーバーできるようにします。 強制フェールオーバーを実行した場合、または LSN が一致する前にリンクを切断すると、データが失われる可能性があります。
  • SQL Server 2019 以前のバージョンのデータベースをフェールオーバーすると、2 つのレプリカ間のリンクが解除され、削除されます。 初期プライマリにフェールバックすることはできません。
  • SQL Server 2022 とのリンクを維持しつつ、データベースをフェールオーバーすることは現在プレビュー段階です。

次のサンプル スクリプトでは、リンクを解除し、レプリカ間のレプリケーションを終了し、両方のインスタンスでデータベースの読み取り/書き込みを行います。 置換前のコード:

  • <ManagedInstanceName> マネージド インスタンスの名前。
  • <DAGName> をフェールオーバーするリンクの名前 (前に実行した Get-AzSqlInstanceLink コマンドからのプロパティ Name の出力)。
# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

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

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

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

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

フェールオーバーが成功すると、リンクは切断されて、存在しなくなります。 SQL Server データベースと SQL Managed Instance データベースは両方とも、読み取り/書き込みワークロードを実行できます。 これらは完全に独立しています。 アクティブに使用するデータベースにアプリケーション接続文字列を再ポイントします。

重要

SQL Managed Instance へのフェールオーバーが成功した後、アプリケーションの接続文字列が SQL マネージド インスタンスの FQDN を指すように手動で設定し直し、移行またはフェールオーバー プロセスを完了して、Azure での実行を続けます。

可用性グループをクリーン アップする

SQL Server 2022 でフェールオーバーしてもリンクが解除されるわけではないため、リンクと可用性グループはそのままにしておくことができます。

リンクを解除する場合、または SQL Server 2019 以前のバージョンでフェールオーバーする場合は、分散型可用性グループを削除して SQL Server からリンク メタデータを削除する必要があります。 ただし、可用性グループを SQL Server に保持することもできます。

可用性グループ リソースをクリーンアップするには、次の値を置き換え、サンプル コードを実行します。次のコードでは次のように置き換えます。

  • <DAGName> は SQL Server の分散型可用性グループの名前に (リンクの作成に使用される)。
  • <AGName> は SQL Server の可用性グループの名前に (リンクの作成に使用される)。
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

トラブルシューティング

このセクションでは、リンクの構成と使用に関する問題に対処するためのガイダンスを提供します。

エラー

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

リンクの操作中にエラーが発生すると、失敗した手順でクエリの実行が停止します。 エラー状態が解決したら、コマンドをもう一度実行して、操作を続行します。

強制フェールオーバー後の一貫性のない状態

強制フェールオーバーを使用すると、プライマリ レプリカとセカンダリ レプリカの間で一貫性のない状態が発生し、両方のレプリカが同じ役割となるスプリット ブレイン シナリオが発生する可能性があります。 1 つのレプリカを手動でプライマリとして指定し、もう一方のレプリカをセカンダリとして指定することで、ユーザーが状況を解決するまで、データ レプリケーションはこの状態では失敗します。

関連するコンテンツ

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