Azure SQL Database 地理レプリケーションの新機能のご紹介


このポストは、11 月 10 日に投稿された Spotlight on new capabilities of Azure SQL Database geo-replication の翻訳です。

昨年の SQL Database 地理レプリケーションのリリース以来、皆様からのフィードバックを基に機能の改善に努めてきました。そして今回、地理レプリケーションの新たな機能強化を発表しました。これまで不便だった部分の改善に加えて、新しい機能もいくつか実装されています。V12 データベースでは、次のような機能が提供されます。

  • T-SQL による地理レプリケーションのサポート
  • フェールオーバーとフェールバック
  • セキュリティ資格情報とファイアウォール ルールの同期機能
  • エラスティック プール内データベースの地理レプリケーションの完全サポート
  • セカンダリ データベースのパフォーマンス レベルの構成
  • Azure Resource Manager API とロールベース セキュリティのサポート
  • 同期的 PowerShell コマンドレット

T-SQL による地理レプリケーションのサポート

地理レプリケーションの構成やフェールオーバーの開始に T-SQL を使用できるようになりました。この場合のコマンドは SQL 認証を必須としているので、既存の PowerShell コマンドレットのようにサブスクリプション証明書を使用することはありません。このため特に、プライマリ サーバーとは別の Azure サブスクリプションにセカンダリ論理サーバーを配置する場合に便利です。新しい T-SQL 構文の詳細については、「Transact-SQL で Azure SQL Database の地理レプリケーションを構成する (英語)」の記事を参照してください。各 T-SQL コマンドには同等の機能の PowerShell コマンド (英語) または REST API (機械翻訳) が存在します。

フェールオーバーとフェールバック

新しいフェールオーバー コマンドでは、レプリケーションの関係を維持したままデータベースの役割を簡単に切り替えられます。実際の障害発生時には、コマンドを「unplanned」(計画外) オプションで実行し、セカンダリをプライマリに即時に昇格させることができます。障害の発生した元のプライマリは、修復されて再び利用可能になると、自動的にセカンダリとして設定され、新しいプライマリからの最新の情報で更新されます。特性としてレプリケーションは非同期であるので、計画外フェールオーバー時は、最新の変更がセカンダリに複製される前にプライマリが停止する可能性があり、その場合はわずかながらデータが喪失します。

もう 1 つの強化機能は、複数のセカンダリ データベースの自動管理です。複数のセカンダリを持つプライマリでフェールオーバーが発生すると、システムによってレプリケーションの関係が自動的に再構成され、新しく昇格したプライマリに残りのセカンダリがリンクされます。このとき、ユーザーの介入は必要ありません。

以下の図は、障害発生時に Azure ポータルを使用して地理レプリケーション データベースをフェールオーバーする方法を示しています。Azure ポータルを使用した地理レプリケーションの詳細については、こちらの記事 (英語) を参照してください。

障害が修復された後、アプリケーションを元のプライマリ拠点に戻すことが必要になる場合があります。その場合は、フェールオーバー コマンドを「planned」(計画内) オプションで実行します。計画フェールオーバーを有効化する方法については、「Transact-SQL で Azure SQL Database の地理レプリケーションを構成する (英語)」と「PowerShell で Azure SQL Database の地理レプリケーションを構成する (英語)」を参照してください。

災害復旧のテスト

前述の「planned」モードでフェールオーバー コマンドを実行した場合、データベースのセカンダリとプライマリの役割はデータが完全に同期された後で切り替えられます。計画フェールオーバーの場合、データの喪失が発生することはなく、プライマリ データベースは常に保護された状態のまま保たれます。このため、このコマンドは運用環境で災害復旧のテストを行うときにも使用できます。

資格情報とファイアウォール ルールの同期維持

地理レプリケーションされているデータベースにはデータベース ファイアウォール ルールの使用が推奨されます。このルールはデータベースと共に複製されるので、すべてのセカンダリ データベースがプライマリと同じファイアウォール ルールを持つことが保証されます。このため、プライマリ データベースとセカンダリ データベースをホストしているサーバーの両方について手動でファイアウォール ルールを構成または維持管理する必要はありません。

同様に、データ アクセスに包含データベース ユーザーを使用することにより、プライマリ データベースとセカンダリ データベースが常に同じユーザー資格情報を持つことが保証されます。こうすることにより、フェールオーバー時にログインやパスワードの不一致で処理が中断することがなくなります。

Azure Active Directory (AAD) を追加で利用することにより、プライマリ データベースとセカンダリ データベースの両方へのユーザー アクセスを管理できます。データベースごとにそれぞれの資格情報を管理する必要はありません。

エラスティック プール内のデータベースの地理レプリケーション

Standard または Premium の Elastic Database Pool 内のすべてのデータベースに対して地理レプリケーションを構成できます。この場合のセカンダリ データベースは、サービス レベルが同じ別の Elastic Database Pool 内に置くことができます。通常のデータベースに対して、セカンダリを Elastic Database Pool 内のデータベースにすることもできます (この反対も可能です)。この場合も、サービス レベルは同じである必要があります。Elastic Database Pool での地理レプリケーション構成のわかりやすい例については、「Transact-SQL で Azure SQL Database の地理レプリケーションを構成する (英語)」と「PowerShell で Azure SQL Database の地理レプリケーションを構成する (英語)」を参照してください。

セカンダリ データベースのパフォーマンスの構成

セカンダリ データベースをプライマリよりも低いパフォーマンス レベルで作成できるようになりました。サービス レベルについては、プライマリ データベースとセカンダリ データベースで同じである必要があります。このオプションはデータベースへの書き込み処理が多いアプリケーションには推奨されません。このオプションを使用するとレプリケーションのタイムラグが増えることになるので、フェールオーバー後に喪失するデータが多くなるリスクが高まります。また、フェールオーバー後のアプリケーションのパフォーマンスは、新しいプライマリ データベースのパフォーマンスが高いレベルに更新されるまで影響を受けることになります。セカンダリのパフォーマンス レベルの構成の例については、「Transact-SQL で Azure SQL Database の地理レプリケーションを構成する (英語)」と「PowerShell で Azure SQL Database の地理レプリケーションを構成する (英語)」を参照してください。

Azure Resource Manager API とロールベース セキュリティ

地理レプリケーションでは、管理用に新しい Azure Resource Manager (ARM) API (機械翻訳) のセットと、新しい ARM ベースの PowerShell コマンドレット (英語) がサポートされるようになりました。この API には、リソース グループの使用とロールベース セキュリティ (RBAC) のサポートが必要です。アクセス ロールの実装方法については、こちらの RBAC の入門記事を参照してください。

以前から提供されている従来の Azure SQL Database Service Management REST API (機械翻訳)従来の Azure SQL Database コマンドレット (英語) は、下位互換性のためにサポートされています。しかし、新しい機能については、ARM ベースの Azure SQL Database REST API (機械翻訳) と ARM ベースの Azure SQL Database PowerShell コマンドレット (英語) でのみサポートされます。

同期的 PowerShell コマンドレット

既定で同期的実行をサポートする新しい ARM ベース PowerShell コマンドレット (英語) が導入されたことにより、スクリプト化が簡単になりました。地理レプリケーションとフェールオーバーのコマンドを同期的に使用する場合、これらの長時間に及ぶ処理の進行状況を監視する必要がなくなり、単純にコマンドが戻るのを待つようにスクリプトを作成できます。

Comments (0)

Skip to main content