アクティブなセカンダリ: 読み取り可能なセカンダリ レプリカ (AlwaysOn 可用性グループ)
AlwaysOn 可用性グループ のアクティブなセカンダリ機能では、1 つ以上のセカンダリ レプリカ (読み取り可能なセカンダリ レプリカ) への読み取り専用アクセスをサポートしています。 読み取り可能なセカンダリ レプリカは、すべてのセカンダリ データベースへの読み取り専用アクセスを許可します。 ただし、読み取り可能なセカンダリ データベースは読み取り専用に設定されません。 これらは動的です。 セカンダリ データベースは、対応するプライマリ データベースに対する変更がそのセカンダリ データベースに適用されると変更されます。 一般的なセカンダリ レプリカでは、セカンダリ データベースのデータはほぼリアルタイムです。 また、フルテキスト インデックスはセカンダリ データベースと同期されます。 多くの場合、プライマリ データベースと対応するセカンダリ データベース間のデータ待機時間は数秒です。
プライマリ データベースに適用されるセキュリティ設定は、セカンダリ データベースに保存されます。 これには、ユーザー、データベース ロール、およびアプリケーション ロールと、それぞれの権限が含まれます。また、透過的なデータ暗号化 (TDE) も含まれます (プライマリ データベースで有効な場合)。
.gif "注意") 注 |
|---|
セカンダリ データベースにはデータを書き込むことはできませんが、ユーザー データベースやシステム データベース (tempdb など) を含め、セカンダリ レプリカをホストするサーバー インスタンス上の読み書き可能なデータベースには書き込むことができます。 |
AlwaysOn 可用性グループ は、読み取り可能なセカンダリ レプリカへの読み取りを目的とした接続要求の再ルーティング (読み取り専用ルーティング) もサポートしています。 読み取り専用ルーティングについては、「リスナーを使用した読み取り専用セカンダリ レプリカ (読み取り専用ルーティング) への接続」を参照してください。
このトピックの内容
利点
可用性グループの前提条件
制限事項と制約事項
パフォーマンスに関する考慮事項
キャパシティ プランニングの注意点
関連タスク
関連コンテンツ
利点
読み取り可能なセカンダリ レプリカに読み取り専用接続を割り当てることには、次の利点があります。
プライマリ レプリカを読み取り専用ワークロードから解放することができ、リソースをミッション クリティカルなワークロード用に保護できます。 ミッション クリティカルな読み取りワークロードまたは待機時間が許容できないワークロードは、プライマリ上で実行する必要があります。
読み取り可能なセカンダリ レプリカをホストするシステムに対する投資収益率を向上させます。
また、読み取り可能なセカンダリは、次のように読み取り専用操作に対する堅牢なサポートを提供します。
セカンダリ データベースの一時的な統計により、読み取り専用クエリが最適化されます。 詳細については、このトピックの後の「読み取り専用アクセス データベースの統計」を参照してください。
読み取り専用ワークロードは、行のバージョン管理を使用してセカンダリ データベースでのブロック競合を除去します。 他のトランザクション分離レベルが明示的に設定されていても、セカンダリ データベースに対して実行されるすべてのクエリは、スナップショット分離トランザクション レベルに自動的にマップされます。 また、すべてのロック ヒントが無視されます。 これにより、リーダー/ライターの競合が解消されます。
![[トップに戻る] リンクで使用される矢印アイコン](images/ms175817.uparrow16x16(sql.110).gif "[トップに戻る] リンクで使用される矢印アイコン")
[先頭に戻る]
可用性グループの前提条件
読み取り可能なセカンダリ レプリカ (必須)
データベース管理者は、セカンダリ ロールで実行しているときに、すべての接続 (読み取り専用アクセスのみ) または読み取りを目的とした接続のみを許可するように 1 つ以上のレプリカを構成する必要があります。
注必要に応じて、プライマリ ロールで実行しているときに、読み取り専用接続を除外するように可用性レプリカを構成することもできます。
詳細については、「可用性レプリカに対するクライアント接続アクセスについて (SQL Server)」を参照してください。
可用性グループ リスナー
読み取り専用ルーティングをサポートするには、可用性グループに可用性グループ リスナーが存在する必要があります。 読み取り専用クライアントは、このリスナーに接続要求を送信する必要があります。クライアントの接続文字列では、アプリケーションの目的として "読み取り専用" を指定する必要があります。つまり、読み取りを目的とした接続要求であることが必要です。
読み取り専用ルーティング
読み取り専用ルーティングは、可用性グループ リスナーに送信される読み取りを目的とした受信接続要求を、使用できる読み取り可能なセカンダリ レプリカにルーティングする SQL Server の機能です。 読み取り専用ルーティングの前提条件は次のとおりです。
読み取り専用ルーティングをサポートするには、読み取り可能なセカンダリ レプリカに読み取り専用ルーティングの URL が必要です。 この URL は、ローカル レプリカがセカンダリ ロールで実行されている場合にのみ有効です。 読み取り専用ルーティングの URL は、必要に応じてレプリカごとに指定する必要があります。 各読み取り専用ルーティングの URL は、読み取りを目的とした接続要求を特定の読み取り可能なセカンダリ レプリカにルーティングする際に使用されます。 通常は、読み取り可能なすべてのセカンダリ レプリカに読み取り専用ルーティングの URL が割り当てられます。
可用性レプリカがプライマリ レプリカである場合に読み取り専用ルーティングをサポートするには、その可用性レプリカに読み取り専用ルーティング リストが必要です。 読み取り専用ルーティング リストは、ローカル レプリカがプライマリ ロールで実行されている場合にのみ有効です。 このリストは、必要に応じてレプリカごとに指定する必要があります。 通常、各読み取り専用ルーティング リストには、すべての読み取り専用ルーティングの URL が含まれており、リストの末尾にローカル レプリカの URL が示されています。
注読み取りを目的とした接続要求は、現在のプライマリ レプリカの読み取り専用ルーティング リスト内の最初に使用できる読み取り可能なセカンダリにルーティングされます。 負荷分散はありません。
詳細については、「可用性グループの読み取り専用ルーティングの構成 (SQL Server)」を参照してください。
| 注 |
|---|
可用性グループ リスナーと読み取り専用ルーティングの詳細については、「可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)」を参照してください。 |
[先頭に戻る]
制限事項と制約事項
次に示すように、一部の操作は完全にはサポートされていません。
可用性グループに参加した読み取り可能なセカンダリ レプリカは、即座にセカンダリ データベースへの接続を許可できます。 ただし、プライマリ データベースにアクティブなトランザクションが存在する場合、行のバージョンは、対応するセカンダリ データベースで即座に完全に使用可能にはなりません。 セカンダリ レプリカの構成時にプライマリ レプリカ上に存在していたアクティブなトランザクションは、コミットまたはロールバックする必要があります。 このプロセスが完了するまでは、セカンダリ データベースでのトランザクションの分離レベルのマッピングは完了せず、クエリは一時的にブロックされます。
注長いトランザクションを実行すると、保持されるバージョン管理される行の数に影響が及びます。
変更の追跡および変更データ キャプチャは、読み取り可能なセカンダリ レプリカに所属するセカンダリ データベースではサポートされません。
変更の追跡は、セカンダリ データベースでは明示的に無効になります。
変更データ キャプチャは、セカンダリ データベースで有効にすることができますが、これはサポートされていません。
読み取り操作はスナップショット分離トランザクション レベルにマップされるため、プライマリ レプリカでのゴースト レコードのクリーンアップが 1 つ以上のセカンダリ レプリカのトランザクションによってブロックされることがあります。 ゴースト レコードのクリーンアップ タスクでは、プライマリ レプリカのゴースト レコードはセカンダリ レプリカで不要になったときに自動的にクリーンアップされます。 これは、プライマリ レプリカでトランザクションを実行する場合の処理と似ています。 セカンダリ データベースでの極端なケースでは、ゴーストのクリーンアップをブロックしているセカンダリ上の実行時間の長い読み取りクエリを終了する必要があります。 セカンダリ レプリカの接続が切断された場合、またはセカンダリ データベースでデータの移動が中断された場合、ゴーストのクリーンアップがブロックされる可能性があります。 この状態ではログの切り捨ても実行できなくなるので、この状態が続く場合は、セカンダリ データベースを可用性グループから削除することをお勧めします。
セカンダリ レプリカで引き続き必要なゴースト レコードがファイルに含まれている場合、プライマリ レプリカでの DBCC SHRINKFILE 操作は失敗する可能性があります。
| 注 |
|---|
読み取り可能なセカンダリ レプリカをホストしているサーバー インスタンスで、sys.dm_db_index_physical_stats 動的管理ビューに対してクエリを実行すると、再実行のブロックの問題が発生する可能性があります。 これは、この動的管理ビューは指定されたユーザー テーブルまたはビューの IS ロックを取得し、このロックによって、再実行スレッドによるそのユーザー テーブルまたはビューの X ロック要求をブロックできるためです。 |
[先頭に戻る]
パフォーマンスに関する考慮事項
このセクションでは、読み取り可能なセカンダリ データベースのパフォーマンスに関するいくつかの考慮事項について説明します。
このセクションの内容
データ待機時間
読み取り専用ワークロードの影響
インデックス作成
読み取り専用アクセス データベースの統計
データ待機時間
セカンダリ レプリカへの読み取り専用アクセスの実装が役立つのは、読み取り専用ワークロードである程度のデータ待機時間を許容できる場合です。 データ待機時間が許容できない場合は、読み取り専用ワークロードをプライマリ レプリカに対して実行することを検討してください。
プライマリ レプリカは、プライマリ データベースでの変更のログ レコードをセカンダリ レプリカに送信します。 それぞれのセカンダリ データベースで、専用の再実行スレッドがログ レコードに適用されます。 読み取りアクセス セカンダリ データベースでは、その変更を含むログ レコードがセカンダリ データベースに適用され、トランザクションがプライマリ データベース上でコミットされない限り、特定のデータの変更はクエリ結果に反映されません。
つまり、プライマリ レプリカとセカンダリ レプリカの間には待機時間 (通常は数秒程度) が発生します。 ただし、ネットワークの問題のためにスループットが低下するなどの特殊なケースでは、待機時間が長くなることがあります。 I/O ボトルネックが生じた場合やデータの移動が中断された場合は、待機時間が増加します。 データ移動の中断を監視するには、AlwaysOn ダッシュボードまたは sys.dm_hadr_database_replica_states 動的管理ビューを使用できます。
読み取り専用ワークロードの影響
セカンダリ レプリカを読み取り専用アクセス用に構成した場合、セカンダリ データベースに対する読み取り専用ワークロードによって (大量の I/O が発生する場合には特に)、再実行スレッドの CPU や I/O などのシステム リソースが消費されます。
また、セカンダリ レプリカの読み取り専用ワークロードによって、ログ レコードを介して適用されるデータ定義言語 (DDL) による変更がブロックされることもあります。 行のバージョン管理のために、読み取り操作は共有ロックを保持しませんが、スキーマ安定度 (Sch-S) ロックを保持します。これにより、DDL の変更を適用する再実行操作がブロックされることがあります。
クエリの作成に関するベスト プラクティスを調べて、セカンダリ データベースでベスト プラクティスを実施してください。 たとえば、データ集計などの実行時間の長いクエリは使用率が低い時間帯にスケジュールするようにします。
| 注 |
|---|
セカンダリ レプリカに対するクエリによって再実行スレッドがブロックされた場合、sqlserver.lock_redo_blocked XEvent が発生します。 |
インデックス作成
読み取り可能なセカンダリ レプリカでの読み取り専用ワークロードを最適化するには、セカンダリ データベースのテーブルにインデックスを作成できます。 セカンダリ データベースではスキーマやデータの変更を行えないため、プライマリ データベースでインデックスを作成し、再実行プロセスによってセカンダリ データベースに変更を転送できるようにします。
セカンダリ レプリカでのインデックス使用状況を監視するには、sys.dm_db_index_usage_stats 動的管理ビューの user_seeks 列、user_scans 列、および user_lookups 列をクエリします。
読み取り専用アクセス データベースの統計
テーブルとインデックス付きビューの列の統計情報を使用して、クエリ プランを最適化します。 可用性グループの場合、プライマリ データベースで作成および管理される統計は、トランザクション ログ レコードの適用の一部としてセカンダリ データベースに自動的に保存されます。 ただし、セカンダリ データベースの読み取り専用ワークロードについて、プライマリ データベースで作成される統計とは別の統計が必要になることがあります。 ただし、セカンダリ データベースは読み取り専用アクセスに制限されているため、セカンダリ データベースで統計を作成することはできません。
この問題に対処するために、セカンダリ レプリカでは、セカンダリ データベースの一時的な統計を、tempdb に作成して管理します。 一時的な統計と、(プライマリ データベースで作成されてセカンダリ データベースに保存される) 永続的な統計とを区別するために、サフィックス _readonly_database_statistic が一時的な統計の名前に付加されます。
一時的な統計を作成して更新できるのは、SQL Server のみです。 ただし、永続的な統計の場合と同じツールを使用すると、一時的な統計を削除したり、そのプロパティを監視したりできます。
DROP STATISTICS Transact-SQL ステートメントを使用して一時的な統計を削除します。
sys.stats カタログ ビューと sys.stats_columns カタログ ビューを使用して統計を監視します。 sys_stats には、どの統計が一時的または永続的なものかを示すための is_temporary 列が含まれています。
SQL Server の統計の詳細については、「統計」を参照してください。
このセクションの内容
セカンダリ データベースの古い永続的な統計
制限事項と制約事項
セカンダリ データベースの古い永続的な統計
セカンダリ データベースの永続的な統計情報が古くなると、SQL Server によって検出されます。 しかし、プライマリ データベースで変更する以外は、永続的な統計に変更を加えることはできません。 クエリの最適化のために、SQL Server はセカンダリ データベースに一時的な統計を作成し、古い永続的な統計の代わりにこの統計を使用します。
永続的な統計がプライマリ データベースで更新されると、統計は自動的にセカンダリ データベースに永続化されます。 次に、SQL Server は、一時的な統計よりも新しい、更新された永続的な統計を使用します。
可用性グループのフェールオーバーが発生すると、すべてのセカンダリ レプリカで一時的な統計が削除されます。
制限事項と制約事項
一時的な統計は tempdb に格納されるので、SQL Server サービスを再起動すると、一時的な統計はすべてなくなります。
サフィックス _readonly_database_statistic は、SQL Server によって生成される統計用に予約されています。 このサフィックスは、プライマリ データベースで統計を作成するときに使用できません。 詳細については、「統計」を参照してください。
[先頭に戻る]
キャパシティ プランニングの注意点
読み取り可能なセカンダリ レプリカでは、2 つの理由から tempdb に領域が必要になることがあります。
スナップショット分離レベルは行バージョンを tempdb にコピーします。
セカンダリ データベースの一時的な統計が tempdb に作成されて管理されます。 一時的な統計により、tempdb のサイズが多少増加することがあります。 詳細については、このセクションの後の「読み取り専用アクセス データベースの統計」を参照してください。
1 つまたは複数のセカンダリ レプリカに対して読み取りアクセスを構成した場合、セカンダリ データベースに行バージョンのポインターを格納するために、プライマリ データベースでデータ行の削除、変更、または挿入ごとに 14 バイトのオーバーヘッドが生成されます。 この 14 バイトのオーバーヘッドはセカンダリ データベースに適用されます。 14 バイトのオーバーヘッドがデータ行に追加されるため、ページ分割が発生することがあります。
行バージョンのデータはプライマリ データベースでは生成されません。 代わりに、セカンダリ データベースで行バージョンが生成されます。 ただし、行のバージョン管理により、プライマリ データベースとセカンダリ データベースの両方でデータ ストレージが増加します。
行バージョン データの追加の有無は、プライマリ データベースのスナップショット分離または READ COMMITTED スナップショット分離 (RCSI) レベル設定によって決まります。 次の表に、さまざまな設定での読み取り可能なセカンダリ データベースのバージョン管理の動作について説明します。
読み取り可能なセカンダリ レプリカ?
スナップショット分離または RCSI レベルは有効?
プライマリ データベース
セカンダリ データベース
いいえ
いいえ
行のバージョンまたは 14 バイトのオーバーヘッドなし
行のバージョンまたは 14 バイトのオーバーヘッドなし
いいえ
はい
行のバージョンおよび 14 バイトのオーバーヘッド
行のバージョンはないが、14 バイトのオーバーヘッドあり
はい
いいえ
行のバージョンはないが、14 バイトのオーバーヘッドあり
行のバージョンおよび 14 バイトのオーバーヘッド
はい
はい
行のバージョンおよび 14 バイトのオーバーヘッド
行のバージョンおよび 14 バイトのオーバーヘッド
[先頭に戻る]
関連タスク
[先頭に戻る]
関連コンテンツ
[先頭に戻る]
関連項目
概念
AlwaysOn 可用性グループの概要 (SQL Server)
可用性レプリカに対するクライアント接続アクセスについて (SQL Server)