Hyperscale セカンダリ レプリカ

  • [アーティクル]

適用対象:Azure SQL Database

分散機能アーキテクチャに関するページで説明したように、Azure SQL Database Hyperscale には、2 種類のコンピューティング ノード (レプリカとも呼ばれます) があります。

セカンダリ レプリカは常に読み取り専用で、次の 3 種類があります。

  • 高可用性レプリカ
  • geo レプリカ
  • 名前付きレプリカ

アーキテクチャ、機能セット、目的、コストは種類ごとに異なります。 必要な機能に応じて、1 つだけ使用することも、3 つすべてを組み合わせて使用することもできます。 セカンダリ レプリカは、サーバーレス コンピューティング レベルとプロビジョニング済みコンピューティング レベルの両方でサポートされています。

Hyperscale の名前付きレプリカの構成と管理に関するチュートリアルについては、以下を参照してください。

高可用性レプリカ

高可用性 (HA) レプリカでは、プライマリ レプリカと同じページ サーバーが使用されるため、HA レプリカを追加するためにデータのコピーは必要ありません。 HA レプリカは主にデータベースの可用性を高めるために使用され、フェールオーバー用のホット スタンバイのレプリカとして機能します。 プライマリ レプリカが利用不可の状態に陥った場合、既存の HA レプリカへのフェールオーバーが自動的にすばやく実行されます。 接続文字列が変化するとは限りません。フェールオーバー中、アクティブな接続が切断されることで、アプリケーションに最小限のダウンタイムが生じることがあります。 そのような場合は通常と同様、適切な再試行ロジックが推奨されます。 いくつかのドライバーには、ある程度の自動再試行ロジックが最初から用意されています。 .NET を使用している場合、構成可能な自動再試行ロジックが、最新の Microsoft.Data.SqlClient ライブラリでネイティブにフル サポートされています。

HA レプリカには、プライマリ レプリカと同じサーバー名とデータベース名が使用されます。 また、そのサービス レベル目標も常にプライマリ レプリカと同じです。 HA レプリカは、ポータルまたは任意の API からスタンドアロン リソースとして表示または管理することはできません。

使用できる HA レプリカの数は 0 個から 4 個です。 この数は、データベースの作成中や作成後に、一般的な管理エンドポイントとツール (例: PowerShell、AZ CLI、Portal、REST API) を使用して変更できます。 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 (AZ CLI、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 の名前付きレプリカのゾーン冗長性

Note

Azure SQL データベースの Hyperscale の名前付きレプリカに対するゾーン冗長のサポートはプレビュー段階です。

Azure SQL データベースの Hyperscale の名前付きレプリカのゾーン冗長性では、Azure Availability Zones を使用して、Azure リージョン内の異なる物理場所に名前付きレプリカ計算ノードを分散します。 名前付きレプリカのゾーン冗長性を選択することで、アプリケーション ロジックを変更することなく、広範な障害に対して、データセンターの停止を含め Hyperscale データベースのすべてのレイヤの回復性を強化できます。 詳細については、「Hyperscale ゾーン冗長の可用性」を参照してください。

ゾーン冗長 Hyperscale の名前付きレプリカを作成するチュートリアルについては、「Hyperscale の名前付きレプリカを作成する」を参照してください。

アプリケーションの障害回復性のトラブルシューティングとテストについては、「アプリケーションの障害回復性をテストする」を参照してください。

geo レプリカ

アクティブ geo レプリケーションを使用すると、プライマリ Hyperscale データベースの読み取り可能なセカンダリ レプリカを同じまたは異なる Azure リージョンに作成できます。 geo レプリカは、異なる論理サーバー上に作成する必要があります。 geo レプリカのデータベース名は常にプライマリのデータベース名と一致します。

geo レプリカを作成すると、プライマリのすべてのデータが、別の一連のページ サーバーにコピーされます。 geo レプリカとプライマリはページ サーバーを共有しません。これは両者が同じリージョンに存在していても同様です。 このアーキテクチャによって、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. を受け取ることがあります。

  • 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 の名前付きレプリカの構成と管理に関するチュートリアルについては、以下を参照してください。

詳細については、以下を参照してください: