Hyperscale セカンダリ レプリカ
適用対象: 
Azure SQL データベース
分散機能アーキテクチャに関するページで説明したように、Azure SQL Database Hyperscale には、2 種類のコンピューティング ノード (レプリカとも呼ばれます) があります。
- プライマリ: 読み取り操作と書き込み操作を処理
- セカンダリ: 読み取りスケールアウト、高可用性、geo レプリケーションを提供
セカンダリ レプリカは常に読み取り専用で、次の 3 種類があります。
- 高可用性レプリカ
- geo レプリカ
- 名前付きレプリカ
アーキテクチャ、機能セット、目的、コストは種類ごとに異なります。 必要な機能に応じて、1 つだけ使用することも、3 つすべてを組み合わせて使用することもできます。 セカンダリ レプリカは、サーバーレスとプロビジョニング済みのいずれかのコンピューティング レベルで使用できます。
Hyperscale の名前付きレプリカの構成と管理に関するチュートリアルについては、以下を参照してください。
高可用性レプリカ
高可用性 (HA) レプリカでは、プライマリ レプリカと同じページ サーバーが使用されるため、HA レプリカを追加するためにデータのコピーは必要ありません。 HA レプリカはデータベースの可用性を高めるために使用され、フェールオーバー用のホット スタンバイ レプリカとして機能します。 プライマリ レプリカが利用不可の状態に陥った場合、既存の HA レプリカへのフェールオーバーが自動的にすばやく実行されます。 接続文字列が変化するとは限りません。フェールオーバー中、アクティブな接続が切断されることで、アプリケーションに最小限のダウンタイムが生じることがあります。 そのような場合は通常と同様、適切な再試行ロジックが推奨されます。 いくつかのドライバーには、ある程度の自動再試行ロジックが最初から用意されています。 .NET を使用する場合、最新の Microsoft.Data.SqlClient ライブラリが、構成可能な自動再試行ロジックに対するネイティブな全面サポートを提供しています。
HA レプリカには、プライマリ レプリカと同じサーバー名とデータベース名が使用されます。 そのサービス レベル目標 (SLO) も常にプライマリ レプリカと同じです。 HA レプリカは、ポータルまたは任意の API からスタンドアロン リソースとして表示や管理ができません。 プライマリ レプリカと同じコンピューティング料金で課金されますが、ストレージ コストはセカンダリ レプリカには適用されません。
使用できる HA レプリカの数は 0 個から 4 個です。 新しいデータベースの作成時にレプリカの数を指定したり、既存のデータベースのレプリカの数を更新したりできます。 一般的な管理エンドポイントとツール (Azure PowerShell、Azure CLI、Azure portal、REST API など) を使用して、HA レプリカの数を指定できます。 HA レプリカを作成したり削除したりしても、プライマリ レプリカのアクティブな接続には影響しません。
HA レプリカへの接続
Hyperscale データベースでは、読み取り/書き込みプライマリ レプリカと読み取り専用の HA レプリカのどちらに接続がルーティングされるかが、クライアントで使用される接続文字列の ApplicationIntent 引数によって決まります。 ApplicationIntent が ReadOnly に設定され、データベースにセカンダリ レプリカがない場合、接続はプライマリ レプリカにルーティングされ、既定で ReadWrite の動作になります。
-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
すべての HA レプリカのリソース容量は同じです。 複数の HA レプリカが存在する場合、読み取りを目的としたワークロードは、使用可能なすべての HA レプリカに任意に分散されます。 HA レプリカが複数存在するとき、プライマリでのデータ変更に関する待ち時間はレプリカごとに異なる場合があることに注意してください。 各 HA レプリカでは、プライマリと同じ一連のページ サーバー上の同じデータが使用されます。 ただし、各 HA レプリカのローカル データ キャッシュには、トランザクション ログ サービスを介してプライマリで行われた変更が反映されます。トランザクション ログ サービスによって、ログ レコードがプライマリ レプリカから HA レプリカに転送されます。 結果として、HA レプリカで実行されているワークロードに応じて、ログ レコードが適用される速度が異なる可能性があるため、プライマリ レプリカと比較したデータの待ち時間がレプリカごとに異なる可能性があります。
名前付きレプリカ
HA レプリカと同様、名前付きレプリカでも、プライマリ レプリカと同じページ サーバーが使用されます。 HA レプリカと同様、名前付きレプリカを追加するためにデータのコピーは必要ありません。
HA レプリカと名前付きレプリカには違いがあります。
- 名前付きレプリカは、ポータルおよび API (Azure CLI、Azure PowerShell、T-SQL) 呼び出しには、通常の (読み取り専用) Azure SQL データベースとして表示されます。
- 名前付きレプリカのデータベース名は、プライマリ レプリカとは異なる場合があります。また、(プライマリ レプリカと同じリージョン内であれば) 必要に応じて異なる論理サーバーに置くこともできます。
- 名前付きレプリカには、独自のサービス レベル目標があり、プライマリ レプリカとは無関係に設定および変更できます。
- 名前付きレプリカでは (プライマリ レプリカ 1 つにつき) 最大 30 個の名前付きレプリカがサポートされます。
- 名前付きレプリカで、名前付きレプリカをホストしている論理サーバーに複数の異なるログインを作成すると、名前付きレプリカごとに異なる認証をサポートできます。
そのため、名前付きレプリカには、HA レプリカと比較して、読み取り専用ワークロードに関するいくつかの利点があります。
- プライマリ レプリカがスケールアップまたはスケールダウンされていても、名前付きレプリカに接続されているユーザーは切断されません。
- 名前付きレプリカがスケールアップまたはスケールダウンされているときにも、プライマリ レプリカに接続されているユーザーには影響がありません。
- プライマリまたは名前付きのレプリカで実行されているワークロードは、他のレプリカで実行されている実行時間の長いクエリによる影響を受けません。
名前付きレプリカの主な目標は、幅広い 読み取りスケールアウト シナリオへの対応と、ハイブリッド トランザクションおよび分析処理 (HTAP) ワークロードの向上です。 こうしたソリューションを作成する方法の例を次に示します。
さらに、名前付きレプリカは柔軟性と弾力性を提供するため、次のような他の多くのユース ケースにも対応します。
- アクセスの分離: 特定の名前付きレプリカへのアクセスは許可できますが、プライマリ レプリカやその他の名前付きレプリカへのアクセスは許可できません。
- ワークロードに依存するサービス レベル目標: 名前付きレプリカには独自のサービス レベル目標を設定できるため、ワークロードやユース ケースごとに異なる名前付きレプリカを使用できます。 たとえば、一方の名前付きレプリカは Power BI 要求の処理に使用し、もう一方の名前付きレプリカは、Apache Spark for Data Science タスクにデータを提供する目的に使用することができます。 それぞれに独立したサービス レベル目標を設定し、個別にスケーリングできます。
- ワークロードに依存するルーティング: 最大 30 個の名前付きレプリカにより、名前付きレプリカをグループで使用し、アプリケーションをそれぞれに分離できます。 たとえば、モバイル アプリケーションから送信される要求の処理には、4 つの名前付きレプリカから成るグループを使用し、Web アプリケーションから送信される要求の処理には、2 つの名前付きレプリカから成るもう 1 つのグループを使用できます。 このアプローチにより、各グループのパフォーマンスとコストを細かな粒度でチューニングすることができます。
Note
Hyperscale の名前付きレプリカについてよく寄せられる質問については、「Azure SQL Database Hyperscale 名前付きレプリカに関する FAQ」を参照してください。
Hyperscale の名前付きレプリカのゾーン冗長性
ゾーン冗長用に構成されたハイパースケールの名前付きレプリカは、Azure Availability Zones を使用して、Azure リージョン内のさまざまな物理的な場所にまたがって名前付きレプリカのコンピューティング ノードを分散します。 名前付きレプリカのゾーン冗長性を選択することで、アプリケーション ロジックを変更することなく、広範な障害に対して、データセンターの停止を含め Hyperscale データベースのすべてのレイヤの回復性を強化できます。 詳細については、「Hyperscale ゾーン冗長の可用性」を参照してください。
ゾーン冗長 Hyperscale の名前付きレプリカを作成するチュートリアルについては、「Hyperscale の名前付きレプリカを作成する」を参照してください。
アプリケーションの障害回復性のトラブルシューティングとテストについては、「アプリケーションの障害回復性をテストする」を参照してください。
geo レプリカ
アクティブ geo レプリケーションを使用すると、プライマリ Hyperscale データベースの読み取り可能なセカンダリ レプリカを同じまたは異なる Azure リージョンに作成できます。 geo レプリカは、異なる論理サーバー上に作成する必要があります。 geo レプリカのデータベース名は常にプライマリのデータベース名と一致します。
geo レプリカを作成すると、プライマリのすべてのデータが、別の一連のページ サーバーにコピーされます。 geo レプリカはプライマリとページ サーバーを共有しません。これは両者が同じ Azure リージョンに存在していても同様です。 このアーキテクチャによって、geo フェールオーバーに必要な冗長性が確保されます。
geo レプリカは、非同期レプリケーションを介してデータベースのトランザクション上一貫性のあるコピーを維持するために使用されます。 geo レプリカが別の Azure リージョンにある場合は、プライマリ リージョンで災害や障害が発生した場合、ディザスター リカバリーに使用できます。 geo レプリカは、地理的な読み取りスケールアウトのシナリオにも使用できます。 2022 年 10 月の時点では、Hyperscale geo セカンダリ レプリカからのデータベース コピーがサポートされています。
Hyperscale データベースの geo レプリケーションには、現在、次の制限があります。
- 作成できる geo レプリカは 1 つだけです (リージョンは同じでも、異なっていてもかまいません)。
- geo レプリカのポイントインタイム リストアはサポートされていません。
- geo レプリカの geo レプリカ (別称 "geo レプリカのチェーン") の作成はサポートされていません。
トラブルシューティング
ゾーン冗長 Hyperscale の名前付きレプリカのトラブルシューティング
アプリケーションの障害回復性のトラブルシューティングとテストについては、「アプリケーションの障害回復性をテストする」を参照してください。
PowerShell と CLI でゾーン冗長の名前付きレプリカを作成するときに、少なくとも 1 つの高可用性レプリカが指定されていることを確認します。 例については、「Hyperscale の名前付きレプリカを作成する」を参照してください。
- Azure CLI では、パラメーター
ha-replicasとredundantの両方を指定する必要があります。 - PowerShell では、パラメーター
HighAvailabilityReplicaCountとZoneRedundantを指定する必要があります。 - 省略した場合、エラー メッセージ
(ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.を受け取ることがあります。
- Azure CLI では、パラメーター
Hyperscale データベースでは、名前付きレプリカに対してこの機能を有効にする前提条件として、ゾーン冗長が既に有効になっている必要があります。
- プライマリ データベースでゾーン冗長が有効になっている場合でも、名前付きレプリカのゾーン冗長を有効にするかどうかはオプションです。
- 有効になっていない場合、エラー メッセージ
(DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.を受け取ることがあります。
既知の問題
sys.databases から一部間違ったデータが返される
名前付きレプリカの sys.databases から返される行の、name 列と database_id 列以外の値が矛盾していたり間違っていたりする場合があります。 たとえば、名前付きレプリカに対応するプライマリ データベースが互換性レベル 150 に設定されている場合でも、その名前付きレプリカの compatibility_level 列が 140 と報告される可能性があります。 回避策は、可能なときには DATABASEPROPERTYEX() 関数を使用してこのデータを取得することです。これにより正しいデータが返されます。
関連するコンテンツ
Hyperscale の名前付きレプリカの構成と管理に関するチュートリアルについては、以下を参照してください。
詳細については、以下を参照してください: