SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Database の Standard の geo レプリケーションについて

leave a comment

ぶちぞーさんの SQL Database の geo レプリケーション で紹介されていますが、geo レプリケーションをきちんと見たことがなかったため、触ってみたいと思います。

直近の情報については、以下が MS のドキュメントとなっています。
General availability: Azure SQL Database geo-replication enhancements
Spotlight on new capabilities of Azure SQL Database geo-replication
Transact-SQL を使用して Azure SQL Database の geo レプリケーションを構成する
Geo レプリケーションを使用してビジネス継続性を実現するクラウド アプリケーションの設計
ビジネス継続性の概要
Azure SQL Database を障害から回復する
アプリケーションのローリング アップグレード中の Azure SQL Database の中断を最小限にする
Geo-Replication Dynamic Management Views and Functions (Azure SQL Database)
 

■はじめに

Standard の SQL Database では、読み取り不可のセカンダリデータベースを「標準 geo レプリケーション」として 1 個追加することができます。
標準 geo レプリケーションについては、機能がリリースされた際のドキュメントが Azure SQL Database Standard Geo-Replication になるかと。

 

ビジネス継続性の概要 に記載されていますが、障害発生時の目標として以下のような内容があります。

障害復旧 (DR): アプリケーションの通常のビジネス機能を復旧するプロセス。

推定復旧時間 (ERT): 復元またはフェールオーバーの要求の後に完全に使用可能になるデータベースの推定時間。

目標復旧時間 (RTO) – 破壊的なイベントの後に、アプリケーションが完全に復旧する前の最大許容時間。RTO は障害時において失われる可用性の最大量を計測します。

目標復旧時点 (RPO) – 破壊的なイベントの後に完全に回復する時点までに、アプリケーションが失うことができる最終更新 (間隔) の最大量。RPO は障害時において失われるデータの最大量を計測します。

各パフォーマンスレベルでは、上記の目標に対して以下のような指標が設定されています。

image

Standard の場合、標準 geo レプリケーションでは、

  • フェールオーバー時の推定復旧時間が 30 秒未満
  • データベースの障害が発生した場合の目標復旧時点が 5 秒未満

として定義が行われています。

これは、Premium レベルでも同様となっており、Standard と Premium で同様の内容となっています。

Standard では、読み取り可能なアクティブ geo レプリケーションは使用することができませんので、そこで機能差はあります。
アクティブ geo レプリケーションについては、Spotlight on SQL Database Active Geo-Replication を見るとよいかと。 

標準 geo レプリケーションと、アクティブ geo レプリケーションには追加で料金が発生し、料金については SQL Database の価格 に記載されており、方式に応じて価格に差が出るようになっています。

 

■標準 geo レプリケーションの構成

環境の構成図については、Azure SQL Database Standard Geo-Replication が、基本的な構成については、SQL Database の価格 の以下の記載が参考になります。

標準 geo レプリケーション

標準 geo レプリケーションでは、同じ地域内で 800 km 以上離れている、事前にペアに指定された Azure リージョンにオフライン セカンダリ データベースが作成されます。セカンダリ標準 geo レプリケーション データベースの価格は、プライマリ データベースの価格の 0.75 倍です。プライマリとオフライン セカンダリの間の geo レプリケーション トラフィックのコストは、オフライン セカンダリのコストに含まれています。標準の geo レプリケーションは、Standard レベルと Premium レベルのデータベースで利用できます。

これについては、Azure ポータルから geo レプリケーションを設定する際にも確認ができます。
Standard の geo レプリケーションの場合は、ペアとなるリージョン以外を選択すると、下の画像のようにエディションを変更してくださいというメッセージが表示されます。

image

 

基本的な設定としては、以下のようになるかと。

  • ペアとなるリージョン
  • 異なるサーバー名の SQL Database
  • Stanadard の同一または、異なる価格レベル
  • 同一名のデータベース

先日のアップデートで異なる価格レベルのデータベースをセカンダリとして設定できるようになったため、

  • プライマリ : S1
  • セカンダリ : S0

というような設定をすることが可能となりました。

フェールオーバーは、異なるサーバーにコピーされているデータベースをアクセス可能な状態にする操作となりますので、フェールオーバー後は接続先の変更が必要となるかと。

 

設定後の進捗状況については、sys.dm_operation_status から確認をすることができます。
以下は設定をした際の情報となりますが、初期の動作については、

  • ALTER DATABASE を実行することで、セカンダリを設定
  • セカンダリをデータベースコピーで作成

というような動作を行っているようですね。

image

プライマリとセカンダリは、異なるサーバーとなるため、ファイアウォールの設定も個別に設定する必要があるようですので、セカンダリを作成した際には、両環境に同一の設定をするように意識をする必要があるかと。
これについては、「ログイン」も同様となるようです。
SQL Server の AlwaysOn でも同様となるのですが、geo レプリケーションについては、ユーザーデータベース間の同期となるため、master データベース内に保存されているオブジェクト (今回のケースでは ログイン) は同期が行われません。
そのため、新規のログインを作成する際は、各サーバーでログインを作成するというステップを踏む必要があります。

この制約を緩和するためには、以下のようなデータベース内に存在するオブジェクトの利用を検討する必要が出てくるようですね。

セカンダリを設定すると、sys.geo_replication_links  から情報を確認することが可能となります。

image

現在の標準 geo レプリケーションは手動でフェールオーバーを実施することができます。
セカンダリのサーバーの master から、Transact-SQL を使用して Azure SQL Database の geo レプリケーションを構成する  の操作を実施することで、フェールオーバーが可能です。
# T-SQL 以外の方法も提供されています。

この時の操作を dm_operation_status から確認すると以下のようになっています。
image

一度、データベースコピーを中断し、フェールオーバーをして再開するというような動作を実施しているようですね。

geo レプリケーションのデータ複製の仕組みが気になったのですが、SQL Database のデータベースコピー機能をベースとしているのでしょうかね。
sys.dm_database_copies  にいくつかの記述がありました。
AlwaysOn のようなログベースの複製ではなく、他の複製方式を使用することで、異なる価格レベルの環境間での複製のラグを抑えている感じなのでしょうか。

Share

Written by Masayuki.Ozawa

12月 31st, 2015 at 3:41 pm

Posted in SQL Database

Tagged with

Leave a Reply