【５分で流し読み】SQL Server AlwaysOn可用性グループの自動シード処理でできることを理解する

こんばんは。今回はAlwaysOn可用性グループの自動シード処理機能について勉強したので、調べて分かったことなどをまとめておきたいと思います。

それではまいります。

Contents

自動シード処理とは

SQL Server 2016から導入された機能
可用性グループのセカンダリレプリカの初期化を自動的に行うことで可用性グループの作成を大幅に楽にする機能
この機能以前は、セカンダリレプリカの初期化を行うためには、取得した完全バックアップをファイル共有に配置し、それをセカンダリレプリカ側で取得・復元を行う必要があった（ため、データI/Oが多く発生してパフォーマンス的によろしくないこともあった）
可用性グループの最初の作成時や可用性データベースの追加時に動作する機能

上の記事と、以下で紹介する公式ブログ記事を読んで、以下のように理解した。（つまりファイル共有いらない？）（違ったらごめんなさい、指摘いただけましたら幸いです）

こちらのチュートリアルの手順が、従来の手順かと思います。以下のように、セカンダリレプリカの初回の同期（初期化）のため、完全バックアップを取得してファイル共有に配置、それをセカンダリに復元、というステップを踏む必要がありました。

プライマリデータベースの完全バックアップを作成
可用性グループを作成
- セカンダリレプリカを追加
- データ同期を設定（例えば完全同期オプションを選択した場合、先ほど取得したバックアップがセカンダリに復元され、同期される）

従来のデータ同期ウィザードの画面

なお、上記各同期オプションの説明の詳細は以下。

自動シード処理は、これら既存の３つの選択肢に加えて利用可能になったオプションのようです。上のチュートリアルのキャプチャは古いようで、最新（バージョン 17以降）のSSMSを利用して可用性グループを作成しようとすると、ちゃんと「自動シード処理」のオプションも選択できるようになっていました。

完全復旧モデルであること（ただし、これは自動シード以前のAlwaysOn可用性グループを構成するための前提条件になっている）
SQL Server 2016ではデータとログファイルのパスが、可用性グループに参加しているすべての SQL Server インスタンスで同じである必要がある（SQL Server 2017では異なるパスでも利用できるが同じパスを利用することが推奨されている）
データベースミラーリングエンドポイントとして利用するポートが、Windowsファイアウォールで開放されていること（これもAlwaysOn可用性グループ構成の前提条件になっている）

完全復旧モデル

上の公式Docsもありますが、下の記事の方が分かりやすくまとめられていて役立ちました。

最大５つのデータベースまで処理できる
自動シード処理はシングルスレッドプロセス（ので、自動シード処理対象のデータベースの数が多いとその分処理時間が長くなっていく）
自動シードは、ミラーリングエンドポイントを介したネットワーク通信によって同期を実現するため、以下のような場合には最適なパフォーマンスが得られない可能性がある
- データベースのサイズが巨大（例だと5TB）、ネットワーク速度が遅い（例だと1Gb/秒）、２つのサイト間の物理的距離が離れている（例だと1000マイル）
ので、そういう場合はこの機能の利用はむいてないよ
データを圧縮することでネットワーク通信量を削減することができるが、既定で使用不可、トレースフラグ9567を利用する必要がある

トレースフラグ9567