Azure SQL Database ハイパースケールに関する FAQ

Hyperscale データベースとは、Hyperscale スケールアウト ストレージ テクノロジによって支えられている SQL Database データベースです。 ハイパースケール データベースは最大 100 TB のデータをサポートし、高いスループットとパフォーマンスを実現すると同時に、ワークロード要件に適応するために迅速にスケーリングできます。 接続性、クエリ処理、データベース エンジン機能などは、Azure SQL Database 内の他のデータベースと同様に機能します。

ハイパースケール サービス レベルを利用できるのは、Azure SQL データベース において仮想コアベースの購入モデルを使用する単一のデータベースのみです。 DTU ベースの購入モデルでは利用できません。

リソース制限の比較で説明されているように、仮想コアベースのサービス レベルは、データベースの可用性とストレージの種類、パフォーマンス、最大ストレージ サイズに基づいて区別されます。

Hyperscale サービス レベルは、より高いパフォーマンスと可用性、高速のバックアップと復元、高速ストレージとコンピューティングのスケーラビリティを必要とするすべてのお客様を対象としています。 これには、アプリケーションを最新化するためにクラウドに移行中のお客様、および Azure SQL Database の他のサービス レベルを既に使用しているお客様が含まれます。 ハイパースケールで得られるのは次のとおりです。

• 最大 100 TB のデータベース サイズ
• データベース サイズにかかわらないデータベースの高速バックアップ (ストレージ スナップショットに基づいたバックアップ)
• データベース サイズにかかわらないデータベースの高速復元 (ストレージ スナップショットに基づいた復元)
• データベースのサイズと仮想コアの数にかかわらないログ スループットの向上
• 1 つ以上の読み取り専用レプリカを使用した読み取りスケールアウト (オフロード読み取り専用ワークロードまたはホット スタンバイデータベースに対応)。
• コンピューティングの一定時間での迅速なスケールアップ (重いワークロードに対応するために性能を向上) と、その後の一定時間でのスケールダウン。 スケーリング操作にかかる時間は、プロビジョニングされたコンピューティングでは 1 桁の分、サーバーレス コンピューティングではデータベース サイズに関係なく 1 秒未満です。

Hyperscale サービス レベルは、Azure SQL Database が利用可能なすべてのリージョンで利用できます。

はい。 サーバーあたりのデータベース数の詳細や制限については、サーバー上の単一データベースおよびプールされたデータベースの SQL Database リソース制限に関するページをご覧ください。

ハイパースケール アーキテクチャは、大きなデータベース サイズをサポートする一方でハイ パフォーマンスとスループットを提供します。

ハイパースケールでは、ワークロードの需要に基づいて迅速なスケーラビリティを提供します。

• スケールアップ/スケールダウン

  ハイパースケールでは、CPU やメモリなどのリソースの観点で主要なコンピューティング サイズをスケールアップしてから、一定時間でスケールダウンできます。 ストレージはリモートであるため、スケールアップとスケールダウンはデータ操作の規模ではありません。

  サーバーレス コンピューティングのサポートでは、自動スケールアップおよびスケールダウンが提供され、コンピューティングは使用量に基づいて課金されます。

• スケールイン/スケールアウト

  Hyperscale では、読み取りスケールアウト、高可用性、geo レプリケーションの各要件に対応するために 3 種類のセカンダリ レプリカを使用できます。 これには次のものが含まれます

  • プライマリと同じコンピューティング サイズを持つ最大 4 つの高可用性レプリカ。 これらは、プライマリからすばやくフェールオーバーするためのホット スタンバイ レプリカとして機能します。 また、これらは、プライマリから読み取りワークロードをオフロードするためにも使用できます。
  • プライマリと同じまたは異なるコンピューティング サイズを持つ最大 30 個の名前付きレプリカ (さまざまな読み取りスケールアウト シナリオに対応するため)。
  • 別の Azure リージョン内にある geo レプリカ (リージョンの停止から保護するため、および地理的な読み取りスケールアウトを可能にするため)。

はい、できます。

いいえ。アプリケーションのプログラミング モデルは、他の MSSQL データベースと同じままです。 いつもの接続文字列とその他の通常の方法を使用して、ハイパースケール データベースを操作します。 アプリケーションが Hyperscale データベースを使用すると、セカンダリ レプリカなどの機能を利用できます。

プライマリ レプリカでは、既定のトランザクション分離レベルは RCSI (Read Committed スナップショット分離) です。 読み取りスケールアウトのセカンダリ レプリカでは、既定の分離レベルはスナップショットです。 これは、他の Azure SQL データベースと同じです。

2023 年 12 月 15 日以降、新しい簡素化された価格が有効になったことで、新しく作成された Hyperscale データベース、すべてのサーバーレス Hyperscale データベース、およびすべての Hyperscale エラスティック プールに対するコンピューティングの価格が引き下げられました。 新しい簡素化された価格では、同等の節約を得るために Azure ハイブリッド特典 (AHB) を適用する必要はありません。 Azure ハイブリッド特典 (AHB) は、プロビジョニングされたコンピューティングを使用する古い (2023 年 12 月 15 日より前に作成された) Hyperscale 単一データベースにのみ適用できます。 これらの古いデータベースの場合、AHB は 2026 年 12 月までしか適用されません。その後、これらのデータベースも新しい簡略化された価格に従って課金されます。 詳細については、「Hyperscale の価格に関するブログ」と「Azure SQL Database Hyperscale – より安くシンプルな価格！」を参照してください。

Hyperscale は、OLTP、ハイブリッド (HTAP)、分析 (データ マート) ワークロードなど、すべてのワークロードの種類に適しています。

現在、SQL Server をデータ ウェアハウスとして使用して対話型分析クエリを実行している場合、Hyperscale がオプションとして優れています。小規模および中規模データ ウェアハウス (数 TB から最大 100 TB) をホスティングするコストを抑えることができ、最小限の T-SQL コードの変更で SQL Server データ ウェアハウス ワークロードを Hyperscale に移行できます。

複雑なクエリで大規模な Data Analytics を実行し、100 MB/s を超えるインジェスト速度を維持しているか、Parallel Data Warehouse (PDW)、Teradata、その他の大規模並列処理 (MPP) データウェアハウスを使用している場合、Azure Synapse Analytics または Microsoft Fabric が最適な選択肢として使用できます。

現時点ではありません。 ただし、コンピューティングとレプリカの数をスケールダウンしてピーク時以外のコストを削減したり、サーバーレスを使って使用量に基づいてコンピューティングを自動的にスケーリングしたりできます。

読み取りワークロードの場合、プライマリよりも高いコンピューティング サイズ (より多くのコアおよびメモリ) を持つ名前付きレプリカを作成できます。 使用可能なコンピューティング サイズの詳細については、Hyperscale のストレージおよびコンピューティング サイズに関するページをご覧ください。

読み取りワークロードの場合、これは名前付きレプリカを使用して実現できます。

Azure portal または REST API を使用して、HA セカンダリ レプリカの数を 0 から 4 の間でスケーリングすることができます。 さらに、さまざまな読み取りスケールアウト シナリオに対応するために、最大 30 個の名前付きレプリカを作成できます。

ハイパースケール データベースでは、データ回復性はストレージ レベルで提供されます。 回復性を実現するために必要なのレプリカは 1 つだけです。 コンピューティング レプリカが停止すると、新しいレプリカが自動的に作成されるためデータは失われません。

ただし、プライマリ レプリカが 1 つしかない場合、フェールオーバー後に新しいレプリカを作成するために 1 から 2 分かかる場合があります。これに対して、HA セカンダリ レプリカを使用できる場合は数秒です。 新しいレプリカには、最初はコールド キャッシュがあるため、ストレージの待機時間が長くなり、フェールオーバー直後のクエリ パフォーマンスが低下する可能性があります。

高可用性を必要とするミッション クリティカル アプリに対するフェールオーバーの影響を最小限に抑えるため、少なくとも 1 つのHAセカンダリ レプリカをプロビジョニングし、ホット スタンバイレプリカでフェールオーバーターゲットとして機能できるようにする必要があります。

100 TB。

Hyperscale において、トランザクション ログは、1 つのトランザクションで 1 TB を超えるログを生成できないという制限はありますが、実質的には無限です。 ログのアクティブな部分は、実行時間の長いトランザクションや、変更データ キャプチャ処理がデータ変更速度に追いつかないことが理由で増加する可能性があります。 この制限を超えないよう、不必要に長くて大きなトランザクションが作成されないようにしてください。 この制限以外、ログ処理能力が高いシステム上では、ログ領域の不足を心配する必要はありません。 ただし、高い書き込みワークロードが継続する場合にはログ生成速度が調整される可能性があります。 ピークが持続するログ生成速度は、100 MB/秒です。

tempdb データベースはローカル SSD ストレージに配置され、プロビジョニングするコンピューティング サイズ (コア数) に比例してサイズが調整されます。 tempdb のサイズを構成することはできません。これは自動的に管理されます。 データベースの最大 tempdb サイズを決定するには、tempdbに関するセクションを参照してください。

データベースのサイズは、データの挿入/取り込みに応じて自動的に拡大します。

10 GB。 ハイパースケール データベースは、まず 10GB で作成され、必要に応じて 10GB まとめて拡張されます。

各データ ファイルは 10 GB ずつ拡張されます。 複数のデータ ファイルが同時に拡張される可能性があります。

ハイパースケールでは、データ ファイルは Azure Standard ストレージに格納されます。 計算レプリカに対してリモートのページ サーバーでは、データは完全にローカル SSD ストレージにキャッシュされます。 さらに、計算レプリカは、ローカル SSD とメモリ内にデータ キャッシュを持ち、リモート ページ サーバーからデータをフェッチする回数を減らします。

いいえ。 データ ファイルは、PRIMARY ファイル グループに自動的に追加されます。 追加のファイル グループを作成する一般的な理由は、Hyperscale ストレージ アーキテクチャやより広範な Azure SQL Database には当てはまりません。

いいえ。

現時点ではありません。

はい。他の Azure SQL DB データベースと同様です。 これには、行、ページ、列ストア圧縮が含まれます。

はい。 特定のテーブルに関連付けられたデータ ページを、同じファイルグループに含まれる複数のデータ ファイルに分散することができます。 MSSQL データベース エンジンでは、比例したデータ格納方法を使用してデータをデータ ファイルに均等配置します。

はい。 ハイパースケールには既存の Azure SQL Database データベースを移行できます。 概念実証 (POC) のために、データベースのコピーを作成して、そのコピーをハイパースケールに移行することをお勧めします。

既存のデータベースを Hyperscale に移動するのに必要な時間は、データのコピーにかかる時間と、データのコピー中にソース データベースに加えられた変更を再生する時間で構成されます。 データのコピー時間は、データのサイズに比例します。 書き込み操作が少ない期間に移動が行われた場合、変更の再生にかかる時間は短くなります。

「既存のデータベースを Hyperscale に移行する」で、Azure portal、Azure CLI、PowerShell、Transact-SQL を使用して既存の Azure SQL データベースを Hyperscale に移行するサンプル コードを取得します。

Azure SQL Database 内の既存のデータベースを Hyperscale サービス レベルに最近移行したお客様は、Hyperscale でニーズを満たせなかった場合、General Purpose サービス レベルへの逆移行により元に戻すことができます。 逆移行はサービス レベルの変更によって開始されますが、基本的には異なるアーキテクチャ間のデータのサイズ操作です。 Hyperscale への移行と同様に、書き込みアクティビティが少ない期間中に行うと、逆移行が速くなります。 逆移行の制限事項について学習します。

以前に既存の Azure SQL Database を Hyperscale サービス レベルに移行している場合、元の Hyperscale への移行から 45 日以内であれば、General Purpose サービス レベルに逆移行できます。 データベースを別のサービス レベル (Business Critical など) に移行する場合は、まず General Purpose サービス レベルに逆移行してから、サービス レベルを変更します。 逆移行は、データのサイズの操作です。

Hyperscale サービス レベルで作成されたデータベースは、他のサービス レベルに移動できません。

逆移行に関する制限事項やバックアップ ポリシーなど、Hyperscale から逆移行する方法を確認してください。

はい。 一部の Azure SQL Database 機能は Hyperscale でまだサポートされていません。 これらの機能の一部がデータベースに対して有効になっている場合、ハイパースケールへの移行がブロックされるか、それらの機能が移行後に動作しなくなる可能性があります。 これらの制限は一時的なものであると想定しています。 詳細については、「既知の制限事項」を参照してください。

はい。 既存の多くの移行テクノロジ (トランザクション レプリケーションやその他のデータ移動テクノロジ (一括コピー、Azure Data Factory、Azure Databricks、SSIS) など) を使用して、Hyperscale に移行することができます。 Azure Database Migration Service に関するページもご覧ください。このサービスでは、多くの移行シナリオがサポートされています。

ハイパースケールへの移行のダウンタイムは、ご自身のデータベースを他の Azure SQL Database サービス レベルに移行する際のダウンタイムと同じです。 トランザクション レプリケーションを使用すると、ダウンタイムを最小限に抑えて、サイズが数 TB までのデータベースを移行できます。 特に大規模なデータベース (10 TB 以上) の場合は、ADF、Spark、またはその他の一括データ移動テクノロジを使用した移行プロセスを実装することを検討してください。

ハイパースケールは、新規または変更されたデータを 100 MB/秒で利用できますが、Azure SQL Database のデータベースにデータを移動するために必要な時間は、使用可能なネットワーク スループット、ソースの読み取り速度、ターゲット データベースのサービス レベル目標の影響も受けます。

クライアント アプリケーションで Azure Storage からデータを読み取り、ハイパースケール データベースに読み込むことができます (他の Azure SQL Database データベースの場合と同様です)。 Polybase は現在 Azure SQL Database でサポートされていません。 高速読み込みを提供する代替手段として、Azure Data Factory を使用するか、SQL 用 Spark コネクタで Spark ジョブを Azure Databricks で使用できます。 SQL 用の Spark コネクタでは一括挿入がサポートされます。

BULK INSERT または OPENROWSET を使用して、Azure BLOB ストアからデータを一括で読み取ることもできます。Azure Blob Storage のデータに一括アクセスする例。

単純復旧モデルまたは一括ログ記録モデルはハイパースケールではサポートされていません。 高可用性を実現して特定の時点に復旧するには、完全復旧モデルが必要です。 ただし、ハイパースケール ログ アーキテクチャでは、他の Azure SQL Database サービス レベルと比較してデータ取り込み率が向上しています。

いいえ。 ハイパースケールは対称型マルチプロセッシング (SMP) アーキテクチャです。超並列処理アーキテクチャ (MPP) またはマルチマスター アーキテクチャではありません。 読み取り専用ワークロードをスケールアウトするためには複数のレプリカを作成するしかありません。

はい。 Azure Database Migration Service では多くの移行シナリオがサポートされています。

「Azure SQL Database の SLA」を参照してください。 クリティカル ワークロード用に HA セカンダリ レプリカを追加することをお勧めします。 これにより、フェールオーバーが高速化され、フェールオーバー直後のパフォーマンスに対する潜在的な影響が軽減されます。

はい。

はい、Hyperscale では、ゾーン冗長構成がサポートされています。 Hyperscale のゾーン冗長構成を有効にするには、少なくとも一つの HA セカンダリ レプリカと、ゾーン冗長または geo ゾーン冗長ストレージの使用が必要です。 Hyperscale の名前付きレプリカに対するゾーン冗長のサポートはプレビュー段階です。

はい。 Hyperscale エラスティック プールは現在プレビュー段階です。 ゾーン冗長 Hyperscale のエラスティック プールは現在プレビュー段階です。

Hyperscale データベースでは、従来の完全バックアップ、差分バックアップ、トランザクション ログ バックアップは存在しません。 代わりに、データ ファイルの定期的なストレージ スナップショットがあります (スナップショット頻度はファイルごとに固有です)。 生成されたトランザクション ログは、構成された保有期間だけそのまま保持されます。 復元時、関連するトランザクション ログ レコードが、復元されたストレージ スナップショットに適用されます。 これにより、スナップショット頻度に関係なく、保持期間内の指定された時点で、データが失われることなく、トランザクション上一貫性のあるデータベースが復元されます。 実際、Hyperscale でのデータベース バックアップは継続的です。

はい。

ポイントインタイム リストアの RPO は 0 分です。 ほとんどのポイントインタイム リストア操作は、データベース サイズにかかわらず、60 分以内に完了します。 大規模なデータベースの場合、および復元ポイントの前とそこに至るまでの時間に大量の書き込みアクティビティが発生した場合は、復元時間が長くなる可能性があります。 復元の発行時に ストレージの冗長性 を変更すると、復元がデータのサイズであるため、復元時間がデータベース サイズに比例することから、復元時間が長くなる可能性があります。

いいえ。 バックアップはストレージ サブシステムによって管理され、ストレージ スナップショットを使用します。 ユーザー ワークロードには影響しません。

はい。 geo 冗長ストレージを使用する場合、geo リストアは完全にサポートされます。 新しいデータベースの場合、これは既定値です。 ポイントインタイム リストアとは異なり、geo リストアでは、データ サイズに応じた操作が必要です。 データ ファイルは並行してコピーされるため、この操作の実行時間は、データベースの合計サイズではなく、データベース内の最大ファイルのサイズによって主に決まります。 ソース データベースのリージョンとペアリングされた Azure リージョンでデータベースを復元した場合、Geo リストアの時間は大幅に短くなります。

はい。 Hyperscale データベースに Geo レプリケーションを設定できます。

いいえ。 Hyperscale データベースのストレージ形式は、リリース バージョンの SQL Server とは異なります。バックアップの管理またはバックアップへのアクセスはできません。 ハイパースケール データベースからデータを取り出すには、データ移動テクノロジ、すなわち、Azure Data Factory、Azure Databricks、SSIS などを使用して、データを抽出できます。

はい。 2022 年 5 月 4 日より、すべての新しいデータベースは、消費されたバックアップ ストレージと、「Azure SQL Database の価格」ページに示されているレートの選択されたストレージ冗長に基づいて課金されます。 2022 年 5 月 4 日より前に作成されたハイパースケール データベースの場合、設定されたバックアップ保持期間が 7 日間を超える場合にのみ、バックアップに対して課金されます。 詳細については、「Hyperscale のバックアップとストレージの冗長性」を参照してください。

バックアップ ストレージ サイズを測定する方法の詳細については、「自動バックアップ」を参照してください。

バックアップ ストレージの請求額を決定するために、バックアップ ストレージ サイズが定期的に計算され、バックアップ ストレージ レートと最後の計算からの時間数が乗算されれます。 ある期間のバックアップ請求額を見積もるには、その期間の 1 時間ごとの請求対象バックアップ ストレージ サイズにバックアップ ストレージ レートを掛け、1 時間あたりの金額をすべて合計します。 プログラムで複数の時間単位の間隔で関連する Azure Monitor メトリックのクエリを実行するには、Azure Monitor REST API を使用します。 サーバーレス コンピューティング レベルでのバックアップ課金は、プロビジョニング済みコンピューティング レベルの場合と同じです。

データベース内の大量のデータを追加、変更、または削除するワークロードの場合、バックアップ コストは高くなります。 逆に、ほとんどが読み取り専用のワークロードでは、バックアップ コストが低くなる可能性があります。

バックアップ ストレージのコストを最小限に抑える方法の詳細については、「バックアップの自動化」を参照してください。

すべてのハイパースケール コンピューティング サイズについて、トランザクション ログ スループットの制限は 100 MB/秒に設定されています。 この速度を達成する能力は、ワークロードの種類やクライアントの構成、パフォーマンスなど、さまざまな要因によって異なります。また、プライマリ計算レプリカ上に、この速度でログ記録を生成するための十分なコンピューティング容量があるかどうかによっても影響されます。

IOPS と IO 待ち時間は、ワークロードのパターンによって異なります。 アクセスされているデータが、コンピューティング レプリカの RBPEX にキャッシュされている場合、Business Critical または Premium サービス レベルの場合と同様の IO パフォーマンスになります。

いいえ。 コンピューティングはストレージ レイヤーから切り離されます。 これによりパフォーマンスへのバックアップの影響がなくなります。

ストレージが共有されており、プライマリ計算レプリカとセカンダリ計算レプリカの間では物理的なレプリケーションが直接発生しないため、セカンダリ レプリカを追加しても、プライマリ レプリカ上のスループットが直接影響を受けることはありません。 ただし、セカンダリ レプリカおよびページ サーバー上のログを適用し、遅れを取り戻すことができるように、プライマリ上の継続的で積極的な書き込みワークロードが調整される場合があります。 これにより、セカンダリ レプリカでの読み取りパフォーマンスの低下と、HA セカンダリ レプリカへのフェイルオーバー後の長時間の復旧が回避されます。

はい。 ただし、他の Azure SQL DB データベースと同様に、発生頻度が非常に低い一時的なエラーによって接続が終了する場合があります。これにより、長時間実行されるクエリが中止され、トランザクションがロールバックされる可能性があります。 一時的なエラーの原因の 1 つとして、コンピューティングやストレージ リソースの継続的可用性を確保したり、計画メンテナンスを実行したりするために、システムによってデータベースが別のコンピューティング ノードにすばやくシフトされる場合があります。 これらの再構成イベントの多くは、10 秒未満で終了します。 データベースに接続するアプリケーションは、再試行ロジックを実装することによって、これらの発生頻度の低い一時的なエラーを想定して許容するように構築する必要があります。 また、計画メンテナンスのために一時的なエラーが発生しないように、ワークロードのスケジュールに一致するメンテナンス期間を構成することを検討してください。

パフォーマンスに関する問題のほとんど、特に根本原因がストレージ パフォーマンスではない問題については、一般的な SQL の診断とトラブルシューティングの手順が適用されます。 ハイパースケール固有のストレージ診断については、「SQL Hyperscale のパフォーマンスのトラブルシューティング診断」を参照してください。

サーバーレス データベースでスケールアップできるメモリの最大量は、構成された仮想コアの最大数に 3 GB/仮想コアを掛けたものです。これに対して、プロビジョニング済みコンピューティングでは、5 GB/仮想コアに同じ数の仮想コアを掛けたものよりも大きくなります。 詳細については、サーバーレス Hyperscale リソースの制限に関するセクションをご確認ください。

プロビジョニング済みコンピューティング レベルでのスケールアップ、またはダウンは、データサイズに関わらず最大 2 分かかります。 サーバーレス コンピューティング レベルでは、ワークロードの需要に基づいてコンピューティングが自動的にスケーリングされ、スケーリング時間は、通常、1 秒未満ですが、プロビジョニング済みコンピューティングをスケーリングする場合と同じくらい時間がかかることもあります。

いいえ。 スケールアップまたはスケールダウンの操作中、データベースはオンラインのままです。

プロビジョニング済みコンピューティングをスケールアップまたはダウンすることで接続が切断されるのは、スケーリング操作の終了時にフェールオーバーが発生したときです。 サーバーレス コンピューティングでは、通常、自動スケーリングで接続が切断されることはありませんが、場合によっては接続が切断されることがあります。 セカンダリ レプリカを追加または削除しても、プライマリの接続は切断されません。

プロビジョニング済みコンピューティングのスケーリングは、エンド ユーザーによって行われます。 サーバーレス コンピューティングの自動スケーリングは、サービスによって行われます。

はい。 コンピューティング ノードの tempdb データベースと RBPEX cache のサイズは、コア数の増加に応じて自動的にスケールアップされます。 詳細については、Hyperscale のストレージとコンピューティング サイズに関するセクションを参照してください。

いいえ。 読み取り/書き込み要求を受け入れるのはプライマリ計算レプリカのみです。 セカンダリ計算レプリカは、読み取り専用要求のみを受け入れます。

Hyperscale では、高可用性 (HA) レプリカ、名前付きレプリカ、および geo レプリカがサポートされます。 詳細については、「Hyperscale セカンダリ レプリカ」を参照してください。

1 から 4 の間。 レプリカの数を調整する場合は、Azure portal または REST API を使用します。

これらの追加読み取り専用計算レプリカに接続するには、接続文字列の ApplicationIntent プロパティを ReadOnly に設定します。 ReadOnly でマークされたすべての接続は、HA セカンダリ レプリカのいずれかに自動的にルーティングされます (あれば)。 詳細については、「読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードする」を参照してください。

T-SQL クエリ SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability') を実行できます。 結果は、読み取り専用セカンダリ レプリカに接続されている場合は READ_ONLY、プライマリ レプリカに接続されている場合は READ_WRITE になります。 データベース コンテキストは、master データベースではなく、お使いのデータベースの名前に設定する必要があります。

いいえ。 ApplicationIntent=ReadOnly を指定することによって、HA セカンダリ レプリカだけに接続できます。 ただし、名前付きレプリカには専用エンドポイントを使用できます。

いいえ。 読み取り専用の意図との新しい接続は、任意の HA セカンダリ レプリカにリダイレクトされます。

プロビジョニング済みコンピューティング レベルではできません。 HA セカンダリ レプリカは高可用性フェールオーバー ターゲットとして使用されるため、フェールオーバー後、期待されるパフォーマンスを提供できるように、プライマリと同じ構成にする必要があります。 サーバーレスでは、コンピューティングは個々のワークロードの需要に基づいて HA レプリカごとに自動的にスケーリングされます。 各 HA セカンダリは、フェールオーバー後のロールに対応するために、構成された最大コアに自動スケーリングできます。 名前付きレプリカには、各レプリカを個別にスケーリングする機能があります。

いいえ。 tempdb データベースはプロビジョニングされたコンピューティング サイズに基づいて構成され、HA セカンダリ レプリカは、tempdb も含めて、プライマリ計算と同じサイズになります。 名前付きレプリカでは、tempdb のサイズはレプリカのコンピューティング サイズに応じて設定されるため、プライマリの tempdb より小さくなったり大きくなったりすることがあります。

いいえ。 Hyperscale データベースではストレージが共有されます。つまり、すべての計算レプリカは同じテーブル、インデックス、その他のデータベース オブジェクトを見ることになります。 読み取りに対して最適化したインデックスをセカンダリに追加したい場合は、プライマリに追加する必要があります。 各セカンダリ レプリカに一時テーブルを作成して (テーブル名の先頭に # または ## を付ける)、一時データを格納することもできます。 一時テーブルは読み取り/書き込みです。

トランザクションがプライマリ上でコミットされてからセカンダリで読み取り可能になるまでのデータ待機時間は、現在のログ生成速度、トランザクション サイズ、レプリカへの負荷、およびその他の要因によって異なります。 小規模なトランザクションの一般的なデータ待機時間は数十ミリ秒ですが、データ待機時間に上限はありません。 特定のセカンダリ レプリカ上のデータは、トランザクション上一貫性があるため、トランザクションが大きいほど伝達に時間がかかります。 ただし、特定の時点でのデータの待機時間とデータベースの状態は、セカンダリ レプリカによって異なる場合があります。 コミットされたデータの読み取りが直ちに必要なワークロードは、プライマリ レプリカで実行される必要があります。

いいえ。名前付きレプリカをプライマリ レプリカのフェールオーバー ターゲットとして使用することはできません。 その目的のために HA レプリカを追加します。

すべての名前付きレプリカは、異なるサービス レベル目標を持つ場合があり、したがって異なるユース ケースに使用される可能性があるため、プライマリに直接送信された読み取り専用トラフィックを一連の名前付きレプリカに転送する組み込みの方法はありません。 たとえば、8 個の名前付きレプリカがある場合、OLTP ワークロードは名前付きレプリカ 1 から 4 にのみ転送し、Power BI 分析ワークロードでは名前付きレプリカ 5 と 6 を使用し、データ サイエンス ワークロードにはレプリカ 7 と 8 を使用することができます。 そのようなワークロードを分散する戦略は、使用するツールまたはプログラミング言語によって異なる場合があります。 REST バックエンドをスケールアウトできるようにするワークロード ルーティング ソリューションを作成する例については、OLTP スケールアウト サンプルを確認してください。

いいえ。名前付きレプリカではプライマリ レプリカと同じページ サーバーが使用されるため、それらは同じリージョンに存在する必要があります。

名前付きレプリカによってプライマリ レプリカの可用性が影響を受けることはありません。 通常の状況では、名前付きレプリカがプライマリのパフォーマンスに影響を与える可能性はほとんどありませんが、負荷の高いワークロードが実行されている場合は発生する可能性があります。 HA レプリカと同様に、名前付きレプリカはトランザクション ログ サービスを介してプライマリと同期されます。 何らかの理由で名前付きレプリカがトランザクション ログを十分高速に使用できない場合、追い付くことができるよう、ログの生成を遅くする (スロットル) ようプライマリ レプリカに要求し始めます。 この動作はプライマリの可用性には影響しませんが、プライマリでの書き込みワークロードのパフォーマンスに影響を与える可能性があります。 この状況を回避するには、名前付きレプリカに、トランザクションログを遅延なしで処理するのに十分なリソース ヘッドルーム (主に CPU) があることを確認します。 たとえば、プライマリで多数のデータ変更が処理されている場合は、レプリカの CPU が飽和状態になり、プライマリの速度が低下しないように、少なくともプライマリと同じサービス レベル目標を持つ名前付きレプリカを用意することをお勧めします。

名前付きレプリカは、通常どおり、読み取り専用アクセスに引き続き使用できます。

既定では、名前付きレプリカには独自の HA レプリカはありません。 名前付きレプリカのフェールオーバーでは、最初に新しいレプリカを作成する必要があります。これには通常、約1 - 2分かかります。 ただし、名前付きレプリカは、HA レプリカによって提供される可用性の向上とフェールオーバーの短縮の恩恵を受けることもできます。 名前付きレプリカの HA レプリカを追加するには、AZ CLI でパラメーター ha-replicas、PowerShell でパラメーター HighAvailabilityReplicaCount、REST API で highAvailabilityReplicaCount プロパティのいずれかを使用できます。 HA レプリカの数は、名前付きレプリカの作成時に設定でき、名前付きレプリカの作成後にいつでも変更できます (AZ CLI、PowerShell、または REST API のみを使用)。 名前付きレプリカの HA レプリカの価格は、通常の Hyperscale データベースの HA レプリカと同じです。

関連するコンテンツ

ハイパースケール サービス レベルについて詳しくは、ハイパースケール サービス レベルに関するページをご覧ください。