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

[アーティクル]
09/10/2024

この記事では、ディザスターリカバリーや移行を目的として 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 を使用して、リンクされたデータベースをフェールオーバーできます。

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

フェールオーバーするには、まず、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 の同期モードに切り替えます。

注意

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

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

次の方法で共有

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

前提条件

ワークロードを停止する

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

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

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

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

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

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

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

フィードバック

その他のリソース

次の方法で共有

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

前提条件

ワークロードを停止する

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

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

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

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

関連するコンテンツ

フィードバック

その他のリソース