リンクのフェールオーバー - Azure SQL Managed Instance

適用対象: Azure SQL Managed Instance

この記事では、ディザスター リカバリーや移行を目的として SQL Server Management Studio (SSMS) または PowerShell を使用し、SQL Server と Azure SQL Managed Instance 間でリンクされたデータベースをフェールオーバーする方法を説明します。

前提条件

リンクを通じてデータベースをセカンダリ レプリカにフェールオーバーするには、次の前提条件を満たす必要があります。

• 有効な Azure サブスクリプション アカウントがない場合は、無料アカウントを作成してください。
• 必要なサービス更新プログラムがインストールされている SQL Server のサポート対象バージョン。
• リンク がプライマリ レプリカとセカンダリ レプリカの間で構成されます。
• リンクをフェールオーバーするには、SQL Server 2022 CU13 (KB5036432) 以降の Transact-SQL を使用します。

ワークロードを停止する

データベースをセカンダリ レプリカにフェールオーバーする準備ができたら、まず、メンテナンス時間中にプライマリ レプリカ上のアプリケーション ワークロードを停止します。 これにより、データベース レプリケーションがセカンダリに追いつくことができるため、データを失うことなくセカンダリにフェールオーバーできます。 フェールオーバーする前に、アプリケーションがプライマリにトランザクションをコミットしていないことを確認します。

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

Transact-SQL (T-SQL)、SQL Server Management Studio または PowerShell を使用して、リンクされたデータベースをフェールオーバーできます。

Transact-SQL

リンクをフェールオーバーするには、SQL Server 2022 CU13 (KB5036432) 以降の Transact-SQL を使用します。

リンクの計画フェールオーバーを行うには、プライマリ レプリカで次の T-SQL コマンドを使用します。

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

強制フェールオーバーを行うには、セカンダリ レプリカで次の T-SQL コマンドを使用します。

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

SQL Server Management Studio (SSMS)

SSMS の SQL Server とマネージド インスタンス間のフェールオーバー ウィザードを使用して、プライマリ レプリカからセカンダリ レプリカにデータベースをフェールオーバーします。

プライマリ レプリカまたはセカンダリ レプリカから計画フェールオーバーを実行できます。 強制フェールオーバーを実行するには、セカンダリ レプリカに接続します。

注意事項

• フェールオーバーを行う前に、レプリケーションされたデータベースが完全に追いつき、フェールオーバーによるデータ損失を防ぐために、ソース データベース上のワークロードを停止します。 強制フェールオーバーを実行している場合は、データが失われる可能性があります。
• SQL Server 2019 以前のバージョンのデータベースをフェールオーバーすると、2 つのレプリカ間のリンクが解除され、削除されます。 初期プライマリにフェールバックすることはできません。

データベースをフェールオーバーするには、次の手順に従います。

1. SSMS を開き、いずれかのレプリカに接続します。

2. オブジェクト エクスプローラーで、レプリケーションされたデータベースを右クリックし、Azure SQL Managed Instance のリンクにマウス ポインターを合わせ、[フェールオーバー…] を選択して、SQL Server と Managed Instance 間のフェールオーバー ウィザードを開きます。 同じデータベースから複数のリンクがある場合は、オブジェクト エクスプローラーの [Always On 可用性グループ] の下にある [可用性グループ] を展開し、フェールオーバーするリンクの分散型可用性グループを右クリックします。 [フェールオーバー...] を選択すると、その特定のリンクに対する SQL Server と Managed Instance の間のフェールオーバー ウィザードが開きます。

   

3. 概要ページで、次へを選択します。

4. [フェールオーバーの種類の選択] ページには、各レプリカ、選択したデータベースのロール、サポートされているフェールオーバーの種類の詳細が表示されます。 任意のレプリカからフェールオーバーを開始できます。 強制フェールオーバーを選択した場合は、データ損失の可能性があることを受け入れるために、ボックスをチェックする必要があります。 [次へ] を選択します。

   Note

   Azure SQL Managed Instance に移行する場合は、[計画フェールオーバー] を選択します。

5. [Azure とリモート インスタンスへの署名] ページで、次の操作を行います。

   1. [サインイン] を選択して資格情報を入力し、Azure アカウントにサインインします。
   2. 前のページで選択したフェールオーバーの種類に基づき、[サインイン] オプションの動作が変わります。 計画フェールオーバーでは、リモート インスタンス (SQL Server または SQL Managed Instance) へのサインインが必須です。 強制フェールオーバーでは、次の 2 つのシナリオがサポートされているため、署名は省略可能です。
      • 真のディザスター リカバリー: 通常、プライマリ インスタンスは実際の障害発生時に使用できないため、サインインすることはできません。ユーザーはすぐにセカンダリ インスタンスにフェールオーバーして、それを新しいプライマリ インスタンスにする必要があります。 障害が解決されると、両方のレプリカがプライマリ ロール (スプリットブレイン シナリオ) となるため、リンクは不整合な状態になります。
      • ディザスター リカバリー ドリル: データ損失の可能性があるため、強制フェールオーバーでディザスター リカバリー ドリルを実行することはお勧めしません。 ただし、ドリル時にはプライマリ インスタンスが使用可能であるため、サインインがサポートされ、スプリット ブレイン シナリオを回避するために両方のレプリカのロールを反転することができます。

6. SQL Server 2022 以前のバージョンでは、[フェールオーバー後の操作] ページにおいて、オプションおよび、プライマリ インスタンスに接続できたかどうかの結果が異なります。

   • SQL Server 2022 では、レプリカ間のレプリケーションを停止すると、フェールオーバーの完了後にリンクと分散型可用性グループを削除することができます。 リンクを維持し、レプリカ間でデータのレプリケーションを続行する場合は、ボックスをオフチェックのままにします。 リンクを削除する場合は、データベースを Azure にレプリケーションするためだけに作成した可用性グループが不要になった場合は、このボックスをチェックして可用性グループを削除することもできます。 シナリオに合ったチェック ボックスをオンにし、[次へ] を選択します。
   • SQL Server 2019 以前のバージョンの場合、リンクを削除するオプションは既定でチェックされています。SQL Managed Instance にフェールオーバーするとレプリケーションが停止し、リンクが接続解除され、分散型可用性グループが削除されるため、リンクをチェック解除することはできません。 リンクが削除されることを理解したことを示すチェック ボックスをオンにし、[次へ] を選択します。
   • (省略可) 前のページで SQL Server インスタンスにサインインできた場合は、[クリーンアップ] セクションのチェック ボックスをオンにして、強制フェールオーバー後に SQL Server インスタンスの可用性グループを削除することもできます。

7. [要約] ページでアクションを確認します。 必要に応じて、[スクリプト] を選択してスクリプトを生成し、後で同じリンクを使用してデータベースのフェールオーバーを行えるようにします。 データベースのフェールオーバーを行う準備ができたら、[完了] を選択します。

8. すべての手順が完了すると、[結果] ページで、正常に完了したアクションの横にチェック マークが表示されます。 これで、ウィンドウを終了できます。

SQL Server 2022 のリンクを維持する場合、セカンダリは新しいプライマリになり、リンクはまだアクティブのままで、セカンダリにフェールバックできます。

SQL Server 2019 以前のバージョンを使用している場合、または SQL Server 2022 のリンクを削除することを選択した場合、リンクは削除され、フェールオーバーの完了後に存在しなくなります。 それぞれのレプリカ上のソース データベースとターゲット データベースは両方、読み取り/書き込みワークロードを実行できます。 これらは完全に独立しています。

重要

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

PowerShell

フェールオーバーするには、まず、Transact-SQL (T-SQL) を使用して SQL Server インスタンスのレプリケーション モードを切り替える必要があります。

その後、PowerShell を使用してロールをフェールオーバーおよび切り替えることができます。

レプリケーション モードの切り替え (SQL MI へのフェールオーバー)

既定では、SQL Server と SQL Managed Instance の間のレプリケーションは非同期です。 SQL Server から Azure SQL Managed Instance にフェールオーバーする場合は、データベースをフェールオーバーする前に、Transact-SQL (T-SQL) を使用してリンクを SQL Server の同期モードに切り替えます。

Note

• SQL Managed Instance から SQL Server 2022 へのフェールオーバーを行う場合、このステップを省略します。
• ネットワーク距離が大きい同期レプリケーションを行うと、プライマリ レプリカでトランザクションが遅くなる可能性があります。

分散型可用性グループのレプリケーション モードを非同期から同期に変更するには、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_COMMIT 状態を示します。

-- 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 Server が同期コミット モードに切り替わり、2 つのインスタンス間のレプリケーションが同期されるようになりました。 この状態を元に戻す必要がある場合は、同じ手順に従って、AVAILABILITY_MODE を ASYNCHRONOUS_COMMIT に設定します。

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 つのレプリカ間のリンクが解除され、削除されます。 初期プライマリにフェールバックすることはできません。

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

• <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 上に可用性グループを保持できますが、SQL Server からリンク メタデータを削除するには、分散可用性グループを削除する必要があります。 SSMS ではこのアクションが実行されるため、この追加の手順は、PowerShell を使用してフェールオーバーする場合にのみ必要です。

分散型可用性グループを削除するには、次の値を置き換えてからサンプルの T-SQL コードを実行します。

• <DAGName> は SQL Server の分散型可用性グループの名前に (リンクの作成に使用される)。

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

フェールオーバー後のデータベースを確認する

SQL Server 2022 の場合、リンクを維持した場合は、SQL Server Management Studio のオブジェクト エクスプローラーの Availability Groups で分散可用性グループが存在することを確認できます。

フェールオーバー中にリンクを削除した場合は、オブジェクト エクスプローラーを使用すると分散型可用性グループがなくなったことを確認できます。 可用性グループを保持した場合、データベースは同期されたままとなります。

フェールオーバー後のクリーンアップ

[フェールオーバーの成功後にリンクを削除する] が選択されていない限り、SQL Server 2022 でフェールオーバーしてもリンクは解除されません。 フェールオーバー後もリンクは維持され、可用性グループと分散型可用性グループはアクティブなままとなります。 これ以外の操作は必要ありません。

リンクを削除すると、分散型可用性グループのみが削除され、可用性グループはアクティブなままとなります。 可用性グループを保持するか、削除するかを決定できます。

可用性グループを削除する場合は、次の値を置き換えてからサンプルの T-SQL コードを実行します。

• <AGName> は SQL Server の可用性グループの名前に (リンクの作成に使用される)。

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

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

強制フェールオーバー後、両方のレプリカがプライマリ ロールに存在するスプリット ブレイン シナリオが発生し、リンクが不整合な状態のままになる場合があります。 これは、障害発生時にセカンダリ レプリカにフェールオーバーした後、プライマリ レプリカがオンラインに戻った場合に発生する可能性があります。

まず、スプリット ブレイン シナリオに陥っているかを確認します。 これには、SQL Server Management Studio (SSMS) または Transact-SQL (T-SQL) を使用します。

SSMS で SQL Server と SQL Managed Instance の両方に接続し、オブジェクト エクスプローラーで、[Always On 高可用性] の [可用性グループ] ノードの下にある [可用性レプリカ] を展開します。 2 つの異なるレプリカが (プライマリ) としてリストされている場合は、スプリット ブレイン シナリオに陥っている状態です。

または、SQL Server と SQL Managed Instance の両方で、次の T-SQL スクリプトを実行して、レプリカのロールを確認することもできます。

-- Execute on SQL Server and SQL Managed Instance 

declare @link_name varchar(max) = '<DAGName>' 
USE MASTER 
GO

SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 and ag.name = @link_name 
GO

両方のインスタンスで [Link role] 列に異なるプライマリがリストされている場合は、スプリット ブレイン シナリオに陥っている状態です。

スプリット ブレイン状態を解決するには、まず元のプライマリレプリカのバックアップを作成します。 元のプライマリが SQL Server の場合は、ログ末尾のバックアップを実行します。 元のプライマリが SQL Managed Instance の場合は、コピーのみの完全バックアップを実行します。 バックアップが完了したら、以前は元のプライマリだったが、新しいセカンダリになるレプリカのセカンダリ ロールに分散型可用性グループを設定します。

たとえば、実際の障害が発生した場合、SQL Server ワークロードを Azure SQL Managed Instance に強制フェールオーバーし、SQL Managed Instance でワークロードを実行し続ける場合は、SQL Server でログ末尾のバックアップを実行し、次の例のように、SQL Server のセカンダリ ロールに分散可用性グループを設定します。

--Execute on SQL Server 
USE MASTER

ALTER availability group [<DAGName>] 
SET (role = secondary) 
GO 

次に、以下の例のようにリンクを使用して、SQL Managed Instance から SQL Server への計画的な手動フェールオーバーを実行します。

--Execute on SQL Managed Instance 
USE MASTER

ALTER availability group [<DAGName>] FAILOVER 
GO 

関連するコンテンツ

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

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

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

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

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

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