以前から調べていたのですが、まとめられていなかったので。
詳細については SQL Server 2016 DTC Support In Availability Groups が公開されている情報で、一番まとまっているかと思います。
High Availability Enhancements / Enhanced Always On Availability Groups in SQL Server 2016 に記載されていますが SQL Server 2016 の AlwaysOn 可用性グループでは分散トランザクションがサポートされるようになっています。
Always On Availability Groups supports distributed transactions and the DTC on Windows Server 2016. For more information, see Support for distributed transactions.
以前からの分散トランザクションの制約ついては、
データベースミラーリングをクロスデータベース トランザクション または分散トランザクションと併用する場合の問題 データベースミラーリング (DBM) 利用時のアプリケーション設計・実装の注意点
を確認しておくと良いかと思います。
SQL Server 2016 の実装については、上記の実装を踏襲しつつ、インダウトなトランザクションの解決方法が変わっているという形になるかと思いますので。
# 従来までの一律ロールバックが、トランザクションの状態を確認して、整合性を保つようになっているのかと思いますが、実動作レベルでそこまで確認ができていません。
サポートされる構成の詳細については、Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server) に記載されており、SQL Server 2016 ではこのドキュメントが更新されています。
サポートされる実行環境としては以下となります。
- Windows Server 2012 R2 + KB3090973
- Windows Server 2016
また、SQL Server 2016 では、データベース間のトランザクションと分散トランザクションがサポートされるようになっていますが、現状サポートされるのは限定的なサポートとなっています。
AlwaysOn 可用性グループにおけるデータベースをまたがるトランザクションについては、
- 同一のインスタンス内のデータベースをまたがるトランザクション (同一インスタンス内のクロスデータベーストランザクション) はサポートされない
という制限があり、同一の可用性グループ内のデータベースについても制限が適用され、同一可用性グループ内の分散トランザクションはサポートされません。
これは、以下のようなクエリがサポートされないということになります。
BEGIN TRAN SET XACT_ABORT ON DECLARE @id uniqueidentifier = (SELECT NEWID()) INSERT INTO AGDB02.dbo.agdb02_tbl VALUES(@id) INSERT INTO TESTDB01.dbo.TESTDB_Tbl VALUES(@id) COMMIT TRAN
サポートされるようになったトランザクションは、
- 異なるインスタンスに配置されたデータベースに対しての分散トランザクション
となります。
# データベースミラーリングについては、サポートされません。
異なるインスタンスに配置されているデータベースに対して、以下のようなクエリがサポートされるのが、SQL Server 2016 の可用性グループの機能拡張となります。
クエリベースで実行する場合、
- リンクサーバーを使用した他のインスタンスのデータベースとのクロスデータベーストランザクションがサポートされる
という感じでしょうか。
BEGIN DISTRIBUTED TRAN SET XACT_ABORT ON DECLARE @id uniqueidentifier = (SELECT NEWID()) INSERT INTO AGDB02.dbo.agdb02_tbl VALUES(@id) INSERT INTO [SQL-02].LocalDB.dbo.local_tbl VALUES(@id) COMMIT TRAN
これを使用可能にするために SQL Server 2016 の可用性グループの設定として「WITH DTC_SUPPORT = PERDB」を指定する必要がありますが、現状は可用性グループを作成するときにのみ指定することが可能で、設定を変更するためには可用性グループを再作成する必要があります。
「WITH DTC_SUPPORT = PERDB」を設定した際の動作については、SQL Server 2016 DTC Support In Availability Groups に記載されており、分散トランザクションやリソースマネージャーについては 分散トランザクション (データベース エンジン) / リソース マネージャの実装 を、DTC の設定については Unable to begin a distributed transaction を参考にするとよいかと思います。
# 私が使っている環境では、「msdtc -uninstall」「msdtc -install」を実行しないと動作がいまいちな環境がありました。
今回はプライマリレプリカ / セカンダリレプリカで以下のような設定を行っています。
設定を有効にした場合、プライマリで可用性グループ内のデータベースがオンラインになった際に、可用性データベースのブートページにリソースマネージャーの ID が登録され、ERRORLOG やイベントログから確認することができます。
Initializing Microsoft Distributed Transaction Coordinator (MS DTC) resource manager [b27c7f18-05d4-4961-8ad0-f8d20c02af9c] for server instance SQL-01. This is an informational message only. No user action is required. サーバー インスタンス SQL-01 の Microsoft 分散トランザクション コーディネーター (MS DTC) リソース マネージャー [b27c7f18-05d4-4961-8ad0-f8d20c02af9c] を初期化しています。これは通知専用メッセーです。ユーザー操作は必要ありません。 Attempting to recover in-doubt distributed transactions involving Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required. Microsoft 分散トランザクション コーディネーター (MS DTC) に関連する、状態が不明な分散トランザクションを復旧しようとしています。このメッセージは情報提供だけを目的としています。ユーザー操作は不要です。
また、DBTABLE からブートページに登録されていることが確認できます。
左がプライマリレプリカ / 右がセカンダリレプリカの実行結果となりますが、プライマリレプリカでのみ登録されていることが確認できますね。
これにより、可用性グループのフェールオーバー時に、インダウトな分散トランザクション (状態が不明なトランザクション) の解決が行われるようです。
# リソースマネージャーが可用性データベースを認識できるようになり、それに関連づいている分散トランザクションの解決を実施してくれるイメージなんですかね。
分散トランザクションの最中に、SQL-01 → SQL-02 にフェールオーバーが発生した場合に、以下のようなログが出力され、インダウトなトランザクションの復旧の実施が行われるようです。
このようなログは「WITH DTC_SUPPORT = NONE」となっている状態では出力されておらず、分散トランザクションにおけるインダウト状態を解消するための処理になるかと思います。
Recovery of any in-doubt distributed transactions involving Microsoft Distributed Transaction Coordinator (MS DTC) has completed. This is an informational message only. No user action is required. Microsoft 分散トランザクション コーディネーター (MS DTC) に関連する、状態が不明な分散トランザクションの復旧が完了しました。このメッセージは情報提供だけを目的としています。ユーザー操作は不要です。
初期の設定が正常に行われていないと、Distributed Transaction Coordinator のサービスを再起動した後に分散トランザクションが正常に動作しないケースがありましたので、
- MSDTC のサービスを再起動した後も正常に分散トランザクションが実行できる
という確認はしておいた方がよさそうですね。
正常に動作する場合は、MSDTC のサービスが無効な状態でなければ、DTC を使用する必要が発生したタイミングでサービスを起動させ、再確立が行われますので。
The connection has been lost with Microsoft Distributed Transaction Coordinator (MS DTC). Recovery of any in-doubt distributed transactions involving Microsoft Distributed Transaction Coordinator (MS DTC) will begin once the connection is re-established. This is an informational message only. No user action is required. Microsoft 分散トランザクション コーディネーター (MS DTC) との接続が失われました。接続の再確立後に、Microsoft 分散トランザクション コーディネーター (MS DTC) に関係する、状態が不明な分散トランザクションの復旧が開始されます。このメッセージは情報提供だけを目的としています。ユーザー操作は不要です。
MSDTC を使用した仕組みとなっているため、フェールオーバー時に DTC にアクセスできる状態かどうかによってもこのあたりの動作は変わってくるそうです。
現在の Windows Server では、クラスター化された DTC とローカルの DTC の 2 種類を使用することができるかと思います。
クラスター化された DTC の場合、DTC のログは共有ディスクに保存されているため、予期せぬシャットダウンが旧プライマリで発生した場合、DTC のリソースがフェールオーバーし、以前のトランザクションで使用されていたログにアクセスができる状態のため、復旧が可能です。
しかし、ローカルの DTC の場合は、予期せぬシャットダウンが、旧プライマリで発生した場合、DTC のログにアクセスすることができないため、復旧作業を実施することができません。
このような状態を解消するためには、DTC のリソースをクラスター化するか、リモートの DTC を使用するような構成をとる必要があるようです。
Resolving DTC Related Waits and Tuning Scalability of DTC
また、DTC を使用していて、インダウトなトランザクションが発生した場合の既定の操作については、in-doubt xact resolution サーバー構成オプション を元に動作するようですので、この辺の設定も併せて確認をしておくと良いかと。
これらの動作を確認する場合、MSDTC のログも併せて確認をすることになるかと思いますが、それについては The hidden tool ? MSDTC Transaction Tracing から確認することができます。
msdtcvtr.bat を実行するためには、Tracefmt.exe が必要となるのですが、インストール方法については Where do I get tracefmt.exe? And how do I read my MSDTC traces? を見るとわかるかと。
Windows Server 2016 TP5 に XP の Tracefmt.exe が動作しましたので、下位バージョンのものでも一応、動作しそうです。
2016/2 時点の情報となるようですが、Availability Groups 2016: Quais sao as novidades? を見ていたところ、以下の一文が記載されていました。
Full support is planned for an upcoming Service Pack Full support is planned for an upcoming Service Pack
今後の SP で、分散トランザクションの実装が変わる計画があるかも知れませんので、マイナーバージョンアップの情報が公開された際には、この辺はウォッチしておくとよさそうですね。