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

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

それではまいります。

自動シード処理とは

セカンダリ レプリカの自動シード処理 – SQL Server Always On | Microsoft Docs

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

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

従来のセカンダリレプリカの初期化手順

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

チュートリアル:SQL Server Always On 可用性グループを構成する – SQL Server on Azure VMs | Microsoft Docs

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

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

チュートリアル:SQL Server Always On 可用性グループを構成する – SQL Server on Azure VMs | Microsoft Docs

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

[最初のデータの同期を選択] ページ (可用性グループ ウィザード) – SQL Server Always On | Microsoft Docs

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

利用の前提条件

自動シード処理を使用して、可用性グループを初期化する – SQL Server Always On | Microsoft Docs

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

完全復旧モデル

パフォーマンス

セカンダリ レプリカの自動シード処理 – SQL Server Always On | Microsoft Docs

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

可用性グループの圧縮の調整 – SQL Server Always On | Microsoft Docs

同期レプリカを使用した可用性グループのログ ストリーム圧縮を有効にします。 この機能は、圧縮によって待機時間が追加されるため、同期レプリカでは既定で無効にされています。 非同期レプリカのログ ストリーム圧縮は同期レプリカに対しては既定で有効にされています。

自動シード処理を使用して、可用性グループを初期化する – SQL Server Always On | Microsoft Docs

プライマリ レプリカに対して自動シード処理時のデータ ストリームの圧縮を有効にするには、トレース フラグ 9567 を設定します。 これにより自動シード処理の転送時間が大幅に減少する一方、CPU 使用率が大きくなります。 

以下のMS公式Blogにパフォーマンス検証の結果が公開されていた。

SQLSweet16!, Episode 2: Availability Groups Automatic Seeding – Microsoft Tech Community

  • 115GBのデータベースを従来のバックアップ-復元を行う方法と比較したところ、半分以下の時間に短縮された
上記記事より引用
  • データ圧縮によって通信量を大幅に削減できる
上記記事より引用

実際に使ってみた

今回は可用性グループを新規作成するシナリオでこの機能を試してみました。

事前に適当なデータベースを作って、完全バックアップを取得した上で、可用性グループの新規作成を行います。

セカンダリレプリカとするインスタンスを追加し・・・

自動シード処理(Automatic Seeding)を選択するだけ。

あとは自動的に構成が完了。

構成後、セカンダリレプリカが同期状態になり、Seeding ModeもAutomaticになっていることが確認できました。

ちなみに、ファイル共有をみてみると、想定の通りバックアップファイルは配置されていませんでした。(キャプチャで見えているMyDB1は、自動シードではない、従来のバックアップと復元方式を利用して可用性グループを構成したもの。こちらはファイル共有にファイルが配置されます)

簡単ではありますが自動シード処理を試してみました。

以上、自動シード処理でできることのまとめでした。少しでも参考になりましたら幸いです。

おしまい

この記事を気に入っていただけたらシェアをお願いします!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

ABOUT US
Yuu113
初めまして。ゆうたろうと申します。 兵庫県出身、東京でシステムエンジニアをしております。現在は主にデータ分析、機械学習を活用してビジネスモデリングに取り組んでいます。 日々学んだことや経験したことを整理していきたいと思い、ブログを始めました。旅行、カメラ、IT技術、江戸文化が大好きですので、これらについても記事にしていきたいと思っています。