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

[アーティクル]
07/01/2024

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

Note

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

前提条件

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

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

ワークロードを停止する

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

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

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

SQL Server Management Studio (SSMS)
PowerShell

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

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

注意事項

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

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

SSMS を開き、いずれかのレプリカに接続します。
オブジェクトエクスプローラーで、レプリケーションされたデータベースを右クリックし、Azure SQL Managed Instance のリンクにマウスポインターを合わせ、[フェールオーバー…] を選択して、SQL Server と Managed Instance 間のフェールオーバー ウィザードを開きます。同じデータベースから複数のリンクがある場合は、オブジェクトエクスプローラーの [Always On 可用性グループ] の下にある [可用性グループ] を展開し、フェールオーバーするリンクの分散型可用性グループを右クリックします。 [フェールオーバー...] を選択すると、その特定のリンクに対する SQL Server と Managed Instance の間のフェールオーバー ウィザードが開きます。
概要ページで、次へを選択します。
[フェールオーバーの種類の選択] ページには、各レプリカ、選択したデータベースのロール、サポートされているフェールオーバーの種類の詳細が表示されます。任意のレプリカからフェールオーバーを開始できます。強制フェールオーバーを選択した場合は、データ損失の可能性があることを受け入れるために、ボックスをチェックする必要があります。 [次へ] を選択します。

Note

Azure SQL Managed Instance に移行する場合は、[計画フェールオーバー] を選択します。
[Azure とリモートインスタンスへの署名] ページで、次の操作を行います。
1. [サインイン] を選択して資格情報を入力し、Azure アカウントにサインインします。
2. 前のページで選択したフェールオーバーの種類に基づき、[サインイン] オプションの動作が変わります。 計画フェールオーバーでは、リモートインスタンス (SQL Server または SQL Managed Instance) へのサインインが必須です。 強制フェールオーバーでは、次の 2 つのシナリオがサポートされているため、署名は省略可能です。
  - 真のディザスターリカバリー: 通常、プライマリインスタンスは実際の障害発生時に使用できないため、サインインすることはできません。ユーザーはすぐにセカンダリインスタンスにフェールオーバーして、それを新しいプライマリインスタンスにする必要があります。障害が解決されると、両方のレプリカがプライマリロール (スプリットブレインシナリオ) となるため、リンクは不整合な状態になります。
  - ディザスターリカバリードリル: データ損失の可能性があるため、強制フェールオーバーでディザスターリカバリードリルを実行することはお勧めしません。ただし、ドリル時にはプライマリインスタンスが使用可能であるため、サインインがサポートされ、スプリットブレインシナリオを回避するために両方のレプリカのロールを反転することができます。
SQL Server 2022 以前のバージョンでは、[フェールオーバー後の操作] ページにおいて、オプションおよび、プライマリインスタンスに接続できたかどうかの結果が異なります。
- SQL Server 2022 では、レプリカ間のレプリケーションを停止すると、フェールオーバーの完了後にリンクと分散型可用性グループを削除することができます。リンクを維持し、レプリカ間でデータのレプリケーションを続行する場合は、ボックスをオフチェックのままにします。リンクを削除する場合は、データベースを Azure にレプリケーションするためだけに作成した可用性グループが不要になった場合は、このボックスをチェックして可用性グループを削除することもできます。シナリオに合ったチェックボックスをオンにし、[次へ] を選択します。
- SQL Server 2019 以前のバージョンの場合、リンクを削除するオプションは既定でチェックされています。SQL Managed Instance にフェールオーバーするとレプリケーションが停止し、リンクが接続解除され、分散型可用性グループが削除されるため、リンクをチェック解除することはできません。リンクが削除されることを理解したことを示すチェックボックスをオンにし、[次へ] を選択します。
- (省略可) 前のページで SQL Server インスタンスにサインインできた場合は、[クリーンアップ] セクションのチェックボックスをオンにして、強制フェールオーバー後に SQL Server インスタンスの可用性グループを削除することもできます。
[要約] ページでアクションを確認します。必要に応じて、[スクリプト] を選択してスクリプトを生成し、後で同じリンクを使用してデータベースのフェールオーバーを行えるようにします。データベースのフェールオーバーを行う準備ができたら、[完了] を選択します。
すべての手順が完了すると、[結果] ページで、正常に完了したアクションの横にチェックマークが表示されます。これで、ウィンドウを終了できます。

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

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

重要

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

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

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

次の方法で共有

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

前提条件

ワークロードを停止する

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

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

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

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

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

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

フィードバック

フィードバック

その他のリソース

次の方法で共有

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

前提条件

ワークロードを停止する

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

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

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

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

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