先日 Azure Database Migration Service を使用した SQL Server から SQL Server on Azure VM への移行で今後期待したい改善 として、Azure DMS についての投稿を書きました。
2023/1/28 時点では、DMS のデフォルトの動作では、移行先のデータベースとして可用性グループに参加させるデータベースを想定して作業を実施した場合、いくつかのポイントがあります。
本投稿では、DMS を使用して移行先のデータベースを可用性グループにする場合のポイントをまとめておきたいと思います。
Contents
移行先で可用性グループを使用したデータベースとして移行を行う際に意識すること
可用性グループのデータベースの初期化としては、
- 各可用性レプリカでデータベースをリストア中の状態にし、結合時に最終同期を行う
- 可用性データベースの登録時に、自動シードで初期同期を実行する
の 2 種類を選択することができます。
空のデータベース / サイズの小さいデータベース / 可用性グループ化にある程度のダウンタイムが許容される というような場合には「2.」の自動シードを使用するのがシンプルな作業となります。
しかし、データベースのサイズが大きい / 可用性グループ化のダウンタイムを最小にしたい というような場合には「1.」による可用性グループ化を前提としておく必要が出てきます。
可用性グループのデータベースとして、データベースの移行を行う場合の注意点としては「可用性グループに参加しているデータベース (可用性データベース) はリストアを行うことができない」という点です。
可用性データベースとして含まれているデータベースはリストアを行うことはできないため、「1.」による作業を実施する場合には、この制約を意識して移行方法を検討する必要があります。
可用性グループ化をダウンタイムを短くして実行するためには
それでは、可用性グループ化を行う際にダウンタイムを短くして「1.」の作業を実行するためにはどうすればよいでしょうか？
シンプルな作業で実行するためには、次のような手順が良いのではないでしょうか。
- 可用性グループを可用性データベースを含めない状態で作成
- 各レプリカでデータベースバックアップ / ログバックアップを継続してリストアする
- 可用性グループ化をしていないデータベースの状態で継続的にリストア
- 最終的なトランザクションログのバックアップをリストアした後に、プライマリとなるデータベーでのみ「WITH RECOVERY」の状態でリストアする
- 他のレプリカについては「WITH NORECOVERY」状態で保持する
- プライマリレプリカとなるサーバーで可用性データベースにデータベースを追加し、可用性グループに結合を行う
- 自動シードとは異なり、各レプリカにデータベースのリストアが行われているので、可用性グループ化を短時間で実施することができる
DMS を使用して手順を実施する場合にはどうするか？
それでは、上記の手順を DMS を使用して実行する場合にはどうすればよいでしょうか？
2023/1/28 時点の DMS による通常の移行手順では次のような動作が行われます。
- 移行を完了した際には、次の操作が行われる
- WITH RECOVERY 状態となり、WITH NORECOVERY 状態で固定はできない
- NEW_BROKER が指定され、Service Broker 識別子が各データベースで変わる
- 移行をキャンセルした際には、データベースがドロップされる
- 処理中のタスクがあると DMS のリソースを削除することはできないため、タスクは完了またはキャンセルをする必要がある
これらの動作は、データベースを可用性グループ化するのには大きな制限となります。
それでは、DMS を使用して、可用性グループ化したいデータベースを移行する場合にはどうすればよいでしょうか？
DMS を使用して可用性グループ化したいデータベースを移行する場合には「DMS はトランザクションログバックアップの定期的なリストアのみで使用し、移行の完了以降は手動で実施する」必要があるかと思います。
それでは、実際に DMS を使用して可用性グループ化したいデータベースを移行する際の作業を整理したいと思います。
1. 空の可用性グループを作成する
可用性グループは可用性データベースを含まない状態でも作成することができますので、事前にデータベースを追加していない可用性グループを作成しておきます。
データベースを含まない可用性グループはウィザードでは作成ができないため、ダミーのデータベースを作成しておき、そのデータベースを使用して可用性グループをウィザードで作成し、作成後に可用性データベースを削除するという手順でも問題ありません。
次のような状態となっている可用性グループを事前に準備しておき、移行を完了させるタイミングでは可用性グループの作成は行わず、データベースの追加のみを行うのがシンプルな手順となります。
2. 初期データベースの移行
DMS によるデータベースの移行は、一つの移行元から複数の移行先に対してデータベースのリストアを行うことができます。
そのため、可用性グループの各可用性レプリカに移行元のデータベースを同時に継続したリストアを行うことができます。
リストアが完了したトランザクションログについては、各移行タスクの状態で確認することができますので必要なトランザクションログのバックアップのリストアがすべて完了 (Restored になっている) になっている状態まで、初期データベースの移行を勧めていきます。
3. プライマリレプリカで DMS を使用しないで一括移行の完了タスク相当の作業を実行する
冒頭に記載した Azure Database Migration Service を使用した SQL Server から SQL Server on Azure VM への移行で今後期待したい改善 のとおり、DMS で一括移行の完了タスクを実行すると、Service Broker 識別子が可用性レプリカごとに異なってしまい、可用性グループへの結合時にエラーとなり、可用性データベースの同期を行うことができません。
そのため、プライマリレプリカとして使用するインスタンスで、次のクエリを手動で実行して、DMS を使用せずに初期データベースの移行を完了させます。
RESTORE DATABASE [<DB Name>] WITH RECOVERY, KEEP_CDC, KEEP_REPLICATION
このクエリを実行することで DMS を介さずに「復元しています」の状態を解除することができます。
セカンダリレプリカについては、可用性レプリカとして結合する際に「復元しています」の状態を解除するため、プライマリ以外のレプリカについては「復元しています」の状態を維持 (RESTORE DATABASE を明示的に実行しない) した状態とします。
4. プライマリレプリカで復元を完了したデータベースを可用性グループ化する
復元していますの状態を解除したデータベースであれば、可用性データベースに追加することができますので、上述の作業を実施したデータベースを可用性グループに追加します。
各可用性レプリカには、データベースは復元中の除隊にしてありますので、データ同期設定については、「結合のみ」を選択して、データベースの追加を行います。
これにより、各レプリカにリストアされているデータベースを活用しながら最終的な可用性データベース化が行われますので、イチから可用性データベースの同期を実行するより、短時間でデータベースが同期された状態を作ることができます。
想定した手順が実行できていれば、次の画像のようにデータベースが同期された状態とすることができます。
5. DMS のクリーンアップ
Azrue の DMS のリソースですが、実行中の移行タスクが存在した状態では、リソースを削除することができません。
そのため、DMS のリソースを削除するためには、何らかの方法でリソースを削除できる状態まで移行タスクの状態を遷移させる必要があります。
将来的には移行タスクは削除ができるようになるようですが、現時点では削除はできず、移行タスクで実行できるのは次の 2 種類の操作となります。
- 一括移行を完了する
- 移行のキャンセル
私が検証した範囲ではこの中でリソースを削除できる状態までタスクを遷移させることができるのは「プライマリレプリカとなっている状態で以降のキャンセルを実行しエラー状態にする」という方法のみとなっていました。(セカンダリレプリカでキャンセルを実行してもタスクはエラーとならず残存した状態となっていました)
今回は vm-SQL-01 / vm-SQL-02 という 2 台で可用性グループを組んでいるのですが、この環境で移行をキャンセルさせる場合は次の手順を実行します。
- vm-SQL-01 をプライマリレプリカにする
- Azure Data Studio で vm-SQL-01 の移行タスクをキャンセルする
- データベースは可用性グループ化されているため DROP DATABASE はエラーとなり、タスクも終了した状態となる
(DMS のタスクとしては、The operation was canceled by another conflicting operation. でエラーとなる)
- vm-SQL-02 をプライマリレプリカにする
- vm-SQL-02 で移行のキャンセルを実行する
- vm-SQL-02 のタスクがエラーとなり、全タスクで終了時間が設定されている状態となる
この状態になると、実行中の移行タスクが存在しない状態となりますので、Azure の DMS のリソースを削除することが可能となります。
まとめ
現状、移行後に可用性グループ化したいデータベースを DMS を使用して移行する場合は、DMS と手動実行の操作を組み合わせることで、可用性グループによるデータベースの同期の処理時間を抑えて、データベースの移行を行うことができそうです。
SQL Server では、
というようなデータベースの同期テクノロジを使用することもできます。
現状の DMS では制御できる操作が少なく、要件に合わないというようなことがある場合には、これら方法を使用して移行を行うことも検討するとよいのではないでしょうか。