Always On 可用性グループの前提条件、制限事項、推奨事項
適用対象:
SQL Server
この記事では、Always On 可用性グループ の展開に関して、各種コンポーネント (ホスト コンピューター、Windows Server フェールオーバー クラスタリング (WSFC)、サーバー インスタンス、可用性グループ) の前提条件、制限、推奨事項などの考慮事項について説明します。 各コンポーネントのセキュリティに関する考慮事項のほか、要求される権限 (該当する場合) にも触れています。
重要
Always On 可用性グループを配置する前に、このトピックのすべてのセクションを読むことを強くお勧めします。
可用性グループをサポートする .NET 修正プログラム
SQL Server で使用する Always On 可用性グループコンポーネントと機能によっては、次の表で指定されている追加の .NET 修正プログラムのインストールが必要になる可能性があります。 これらの修正プログラムは任意の順序でインストールできます。
| 依存機能 | 修正プログラム | Link |
|---|---|---|
| Reporting Services | .NET 3.5 SP1 の修正プログラムでは、SQL クライアントに読み取り目的、読み取り専用、multisubnetfailover の Always On 機能のサポートが追加されます。 修正プログラムは、各 Reporting Services レポート サーバーにインストールする必要があります。 | KB 2654347:Always On 機能のサポートが追加される .NET 3.5 SP1 の修正プログラム |
チェック リスト: 要件 (Windows システム)
Always On 可用性グループ の機能を利用するには、1 つまたは複数の可用性グループに参加するすべてのコンピューターが、次の基本要件を満たしている必要があります。
| 要件 | リンク |
|---|---|
| システムがドメイン コントローラーではないことを確認します。 | 可用性グループは、ドメイン コントローラーではサポートされていません。 |
| すべてのコンピューターで Windows Server 2019 以降のバージョンが実行されていることを確認します。 | SQL Server 2022: ハードウェアとソフトウェアの要件 |
| 各コンピューターが WSFC のノードであることを確認します。 | Windows Server フェールオーバー クラスタリングと SQL Server |
| 必要な可用性グループの構成に耐える十分なノードが WSFC に存在することを確認します。 | クラスター ノードでは、可用性グループのレプリカを 1 つホストできます。 同じノードで、同じ可用性グループのレプリカを 2 つホストすることはできません。 クラスター ノードは複数の可用性グループに参加できます。その際、各グループからのレプリカは 1 つです。 予定している可用性グループの可用性レプリカをサポートするために必要なクラスター ノードの数については、データベース管理者にお問い合わせください。 Always On 可用性グループとは。 |
重要
可用性グループへの接続に必要な構成が環境に対して正しく実施されていることも確認します。 詳細については、「可用性グループのドライバーとクライアント接続のサポート」を参照してください。
可用性レプリカをホストするコンピューターに関する推奨事項 (Windows システム)
同程度のシステム: 可用性グループ内の可用性レプリカはすべて、ワークロードの処理能力が同程度であるシステム上で運用する必要があります。
専用のネットワーク アダプター: 最良のパフォーマンスを得るには、Always On 可用性グループに専用のネットワーク アダプター (ネットワーク インターフェイス カード) を使用します。
十分なディスク領域: 可用性レプリカをホストするサーバー インスタンスのあるすべてのコンピューターには、可用性グループ内のすべてのデータベースを格納できるだけのディスク領域が存在する必要があります。 プライマリ データベースが大きくなるにつれて、対応するセカンダリ データベースも同じだけ大きくなる点に注意してください。
アクセス許可 (Windows システム)
WSFC を管理するユーザーは、すべてのクラスター ノードのシステム管理者であることが必要です。
クラスターを管理するためのアカウントの詳細については、「付録 A: フェールオーバー クラスターの要件」を参照してください。
関連タスク (Windows システム)
| タスク | Link |
|---|---|
| HostRecordTTL の値を設定します。 | HostRecordTTL の変更 (Windows PowerShell を使用) |
HostRecordTTL の変更 (PowerShell を使用)
[管理者として実行] を選択して PowerShell ウィンドウを開きます。
FailoverClusters モジュールをインポートします。
Get-ClusterResource コマンドレットを使用してネットワーク名リソースを検索し、次に Set-ClusterParameter コマンドレットを使用して HostRecordTTL 値を設定します。次に例を示します。
Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>
次に示す PowerShell の例では、
SQL Network Name (SQL35)というネットワーク名リソースの HostRecordTTL を 300 秒に設定します。Import-Module FailoverClusters $nameResource = "SQL Network Name (SQL35)" Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300ヒント
新しい PowerShell ウィンドウを開くたびに、 FailoverClusters モジュールをインポートする必要があります。
関連コンテンツ (PowerShell)
クラスターと高可用性 (フェールオーバー クラスタリングとネットワーク負荷分散のチームのブログ)
関連コンテンツ (Windows システム)
SQL Server インスタンスの前提条件と制限
可用性グループにはそれぞれ、 のインスタンスによってホストされる一連のフェールオーバー パートナー ( 可用性レプリカ SQL Server) が必要です。 サーバー インスタンスには、 スタンドアロン インスタンス または SQL Serverフェールオーバー クラスター インスタンス (FCI) を使用できます。
このセクションの内容:
チェック リスト: 前提条件 (サーバー インスタンス)
| 前提条件 | リンク |
|---|---|
| このホスト コンピューターは WSFC ノードである必要があります。 可用性グループの可用性レプリカをホストする SQL Server のインスタンスは、クラスターの別のノードに存在します。 別のクラスターに移行するときに、可用性グループは一時的に 2 つのクラスターにまたがることができます。 SQL Server 2016 (13.x) には分散型可用性グループが導入されています。 分散型可用性グループでは、2 つの可用性グループが別々のクラスターに存在します。 | Windows Server フェールオーバー クラスタリングと SQL Server フェールオーバー クラスタリングと Always On 可用性グループ (SQL Server) 分散型可用性グループ |
| 可用性グループで Kerberos を操作するには: 可用性グループの可用性レプリカをホストするすべてのサーバー インスタンスで、同じ SQL Server サービス アカウントを使用する必要があります。 ドメイン管理者は、可用性グループ リスナーの仮想ネットワーク名 (VNN) の SQL Server サービス アカウントに、Active Directory でサーバー プリンシパル名 (SPN) を手動で登録する必要があります。 SQL Server サービス アカウント以外のアカウントに SPN が登録されている場合は、認証が失敗します。 可用性グループ (AG) エンドポイント間の通信に Kerberos 認証を使うには、AG によって使用されるデータベース ミラーリング エンドポイントの SPN を手動で登録します。 重要: SQL Server サービス アカウントを変更した場合は、ドメイン管理者が SPN を手動で再登録する必要があります。 |
Kerberos 接続用にサービス プリンシパル名を登録する 注: Kerberos と SPN は相互認証を行います。 SPN は、SQL Server サービスを起動する Windows アカウントにマップされます。 SPN が正常に登録されていないか登録に失敗した場合、Windows セキュリティ レイヤーは、SPN に関連するアカウントを決定することができず、Kerberos 認証は使用できません。 注: NTLM には、この要件はありません。 |
| SQL Server フェールオーバー クラスター インスタンス (FCI) を使用して可用性レプリカをホストする予定がある場合は、FCI の制限を確実に理解し、FCI の要件が満たされていることを確認してください。 | SQL Server のフェールオーバー クラスター インスタンス (FCI) を使用して可用性レプリカをホストするための前提条件と要件 (この記事の後半) |
| 可用性グループに参加するために、各サーバー インスタンスで同じバージョンの SQL Server が実行されている必要がある。 | 詳細については、このセクションの最後にあるエディションとサポートされている機能のリストをご覧ください。 |
| 特定の可用性グループの可用性レプリカをホストするすべてのサーバー インスタンス間で SQL Server の照合順序を統一する必要があります。 | サーバーの照合順序の設定または変更 |
| 可用性グループの可用性レプリカをホストするすべてのサーバー インスタンスで Always On 可用性グループ 機能を有効にします。 Always On 可用性グループ のサーバー インスタンスは、 SQL Server 環境がサポートする範囲内であれば、1 台のコンピューターでいくつでも有効にすることができます。 | Always On 可用性グループ機能を有効または無効にする 重要: WSFC を破棄してから再作成した場合は、Always On 可用性グループを有効にしていた、元のクラスター上の各サーバー インスタンスについて、Always On 可用性グループ 機能を無効にしてからもう一度有効にする必要があります。 |
| すべてのサーバー インスタンスには、データベース ミラーリング エンドポイントが必要です。 このエンドポイントは、サーバー インスタンス上のミラーリング監視サーバーとデータベース ミラーリング パートナー、および可用性レプリカすべてによって共有されます。 可用性レプリカのホストとして選んだサーバー インスタンスがドメイン ユーザー アカウントで実行されていて、まだデータベース ミラーリング エンドポイントが存在しない場合、可用性グループ ウィザードの使用 (SQL Server Management Studio) (または SQL Server Management で可用性グループ ウィザードを使用した Always On 可用性グループへのレプリカの追加) でエンドポイントを作成し、サーバー インスタンス サービス アカウントに CONNECT アクセス許可を許可することができます。 ただし、 SQL Server サービスがビルトイン アカウント (Local System、Local Service、Network Service など) で実行されている場合または非ドメイン アカウントで実行されている場合は、エンドポイント認証に証明書を使用する必要があります。ウィザードは、サーバー インスタンス上でデータベース ミラーリング エンドポイントを作成できなくなります。 この場合は、データベース ミラーリング エンドポイントを手動で作成してからウィザードを起動することをお勧めします。 セキュリティに関する注意: Always On 可用性グループのトランスポート セキュリティは、データベース ミラーリングと同じです。 |
データベース ミラーリング エンドポイント (SQL Server) トランスポート セキュリティ - データベース ミラーリング - Always On 可用性 |
| FILESTREAM を使用するデータベースを可用性グループに追加する場合は、その可用性グループの可用性レプリカをホストするすべてのサーバー インスタンスで FILESTREAM が有効になっていることを確認してください。 | FILESTREAM の有効化と構成 |
包含データベースを可用性グループに追加する場合は、その可用性グループの可用性レプリカをホストするすべてのサーバー インスタンスで contained database authentication (サーバー構成オプション) が 1 に設定されていることを確認してください。 |
contained database authentication サーバー構成オプション サーバー構成オプション (SQL Server) |
Windows の SQL Server の各エディションでサポートされる機能のリストについては、以下を参照してください。
- SQL Server 2022 の各エディションとサポートされている機能
- SQL Server 2019 の各エディションとサポートされている機能
- エディションと SQL Server 2017 のサポートされる機能
- エディションと SQL Server 2016 のサポートされる機能
可用性グループによるスレッドの使用
Always On 可用性グループ には、ワーカー スレッドに関する次の要件があります。
SQL Serverのアイドル状態のインスタンスでは、 Always On 可用性グループ はスレッドを使用しません。
可用性グループが使用するスレッドの最大数は、サーバー スレッドの最大数 ('max worker threads') から 40 を引いた数にあらかじめ設定されています。
特定のサーバー インスタンスでホストされている可用性レプリカは、SQL Server 2019 (15.x) 以前のバージョンの単一スレッド プールを共有します。
スレッドは、次のように要求に基づいて共有されます。
通常は 3 個から 10 個の共有スレッドがありますが、プライマリ レプリカのワークロードに応じてこの数が増える場合があります。
特定のスレッドが一定期間アイドル状態になると、そのスレッドは解放され、 SQL Server の汎用スレッド プールに戻されます。 通常、非アクティブ スレッドは、非アクティブな状態のまま最大 15 秒経過すると解放されます。 ただし、最後の利用状況によっては、アイドル状態のスレッドが保持される時間が延長される場合があります。
SQL Server インスタンスは、セカンダリ レプリカの並列再実行に最大で 100 個のスレッドを使用します。 各データベースは、最大で、CPU コアの合計数の半分を使用しますが、データベースあたりのスレッド数は 16 個以下となります。 単一のインスタンスで必要なスレッド数の合計が 100 を超えている場合、SQL Server は、残りの各データベースには単一の再実行スレッドを使用します。 シリアル再実行スレッドは、非アクティブな状態のまま約 15 秒経過すると解放されます。
さらに、可用性グループでは非共有スレッドを次のように使用します。
各プライマリ レプリカでは、プライマリ データベースごとにログ キャプチャ スレッドを 1 つ使用します。 また、セカンダリ データベースごとにログ送信スレッドを 1 つ使用します。 ログ送信スレッドは、非アクティブな状態のまま最大 15 秒経過すると解放されます。
セカンダリ レプリカでのバックアップでは、バックアップ操作の間、プライマリ レプリカにスレッドが保持されます。
SQL Server 2022 (16.x) では、並列再実行スレッド プールが導入されました。これは、再実行作業を行うすべてのデータベースと共有されるインスタンス レベルのスレッド プールです。 このプールを使用すると、同じスレッドのセットで、異なるデータベースのログ レコードを同時に (並列で) 処理できます。 SQL Server 2019 (15.x) 以前のバージョンでは、再実行に使用できるスレッドの数は 100 に制限されています。
SQL Server 2019 (15.x) では、メモリ最適化可用性グループ データベースに対する並列再実行が導入されました。 SQL Server 2016 (13.x) と SQL Server 2017 (14.x) では、可用性グループ内のデータベースがメモリ最適化もされている場合、ディスク ベースのテーブルで並列再実行は使用されません。
詳細については、「Always On - HADRON 学習シリーズ: HADRON 対応データベースでのワーカー プールの使用」 (CSS SQL Server エンジニア ブログ) を参照してください。
アクセス許可 (サーバー インスタンス)
| タスク | 必要なアクセス許可 |
|---|---|
| データベース ミラーリング エンドポイントを作成する | CREATE ENDPOINT 権限、または sysadmin 固定サーバー ロールのメンバーシップが必要です。 また、CONTROL ON ENDPOINT 権限も必要です。 詳細については、「GRANT (エンドポイントの権限の許可) (Transact-SQL)」を参照してください。 |
| 有効にする Always On 可用性グループ | ローカル コンピューターの Administrator グループのメンバーシップおよび WSFC に対するフル コントロール権限が必要です。 |
関連タスク (サーバー インスタンス)
| タスク | [アーティクル] |
|---|---|
| データベース ミラーリング エンドポイントが存在するかどうかを確認する | sys.database_mirroring_endpoints (Transact-SQL) |
| データベース ミラーリング エンドポイントを作成する (まだ存在しない場合) | Windows 認証でのデータベース ミラーリング エンドポイントの作成 (Transact-SQL) データベース ミラーリング エンドポイントでの証明書の使用 (Transact-SQL) PowerShell を利用し、可用性グループのデータベース ミラーリング エンドポイントを作成する |
| 可用性グループを有効にする | Always On 可用性グループ機能を有効または無効にする |
関連コンテンツ (サーバー インスタンス)
ネットワーク接続の推奨事項
WSFC ノード間の通信と、可用性レプリカ間の通信には、同じネットワーク リンクを使用することを強くお勧めします。 別々のネットワーク リンクを使用すると、一部のリンクにエラーが発生した場合に (断続的なエラーであっても)、予期しない動作が発生する可能性があります。
たとえば、自動フェールオーバーをサポートする可用性グループでは、自動フェールオーバー パートナーであるセカンダリ レプリカの状態が SYNCHRONIZED である必要があります。 このセカンダリ レプリカへのネットワーク リンクにエラーが発生した場合 (断続的なエラーであっても)、レプリカが UNSYNCHRONIZED 状態になり、リンクが復元されるまで再同期を開始できません。 セカンダリ レプリカが非同期状態にある間に WSFC が自動フェールオーバーを要求しても、自動フェールオーバーは行われません。
クライアント接続のサポート
クライアント接続に対する Always On 可用性グループのサポートについては、「可用性グループのドライバーとクライアント接続のサポート」を参照してください。
SQL Server のフェールオーバー クラスター インスタンス (FCI) を使用して可用性レプリカをホストするための前提条件と制限
このセクションの内容:
制限 (FCI)
Note
フェールオーバー クラスター インスタンスは、クラスター化共有ボリューム (CSV) もサポートしています。 CSV の詳細については、「 フェールオーバー クラスターのクラスターの共有ボリュームについて」を参照してください。
FCI のクラスター ノードでホストできるレプリカは、特定の可用性グループに対して 1 つだけである: FCI に可用性レプリカを追加する場合、FCI の有効な所有者である WSFC ノードで、同じ可用性グループに対して別のレプリカをホストすることはできません。 競合を避けるために、フェールオーバー クラスター インスタンスの所有者を構成することをお勧めします。 これにより、1 つの WSFC によって同じ可用性グループの 2 つの可用性レプリカがホストされる可能性がなくなります。
さらに、その他の各レプリカは、同じ Windows Server フェールオーバー クラスター内の別のクラスター ノードに存在する SQL Server のインスタンスによってホストされている必要があります。 唯一の例外は、別のクラスターに移行するときに、可用性グループは一時的に 2 つのクラスターにまたがることができるという点です。
警告
フェールオーバー クラスター マネージャーを使用して、可用性グループをホストしている FCI を、同じ可用性グループのレプリカをすでにホストしているノードに移動すると、可用性グループのレプリカが失われ、それによってターゲット ノード上でオンラインにできなくなる可能性があります。 フェールオーバー クラスターの 1 つのノードでは、同じ可用性グループの複数のレプリカをホストすることはできません。 これがどのように発生し、どのように回復するかの詳細については、ブログ記事の「Replica unexpectedly dropped in availability group」(可用性グループでレプリカが予想外に削除される) を参照してください。
可用性グループによる自動フェールオーバーは FCI ではサポートされない: FCI では可用性グループによる自動フェールオーバーがサポートされないため、FCI によってホストされる可用性レプリカは手動フェールオーバー用にのみ構成できます。
FCI ネットワーク名の変更: 可用性レプリカがホストされている FCI のネットワーク名を変更する必要がある場合は、レプリカをその可用性グループから削除してから再度、可用性グループに追加する必要があります。 プライマリ レプリカを削除することはできません。そのため、プライマリ レプリカがホストされている FCI の名前を変更するには、セカンダリ レプリカにフェールオーバーしてから、以前のプライマリ レプリカを削除し、再度追加する必要があります。 FCI の名前を変更すると、そのデータベース ミラーリング エンドポイントの URL が変わる可能性があります。 レプリカを追加する際は、必ず最新のエンドポイントの URL を指定してください。
チェック リスト: 前提条件 (FCI)
| 前提条件 | Link |
|---|---|
| 標準の SQL Server フェールオーバー クラスター インスタンスのインストールと同様、各 SQL Server フェールオーバー クラスター インスタンス (FCI) が必要な共有ストレージを所有していることを確認してください。 |
関連タスク (FCI)
| タスク | 記事 |
|---|---|
| SQL Server FCI のインストール | 新しい Always On フェールオーバー クラスター インスタンスを作成する (セットアップ) |
| 既存の SQL Server FCI のインプレース アップグレード | フェールオーバー クラスター インスタンスのアップグレード |
| 既存の SQL Server FCI の維持 | フェールオーバー クラスター インスタンスでのノードの追加または削除 (セットアップ) |
関連コンテンツ (FCI)
可用性グループの前提条件と制限
このセクションの内容:
制限 (可用性グループ)
可用性レプリカは、1 つの WSFC の別々のノードによってホストされている必要がある: 各可用性グループで、個々の可用性レプリカは、同じ WSFC の別々のノード上で動作するサーバー インスタンスによってホストされる必要があります。 唯一の例外は、別のクラスターに移行するときに、可用性グループは一時的に 2 つのクラスターにまたがることができるという点です。
注意
同じ物理コンピューター上の各仮想マシンは独立したコンピューターとして動作するため、同じ可用性グループの可用性レプリカをそれぞれの仮想マシンがホストできます。
一意の可用性グループ名: 各可用性グループの名前は、WSFC 上で一意である必要があります。 可用性グループ名の最大文字数は 128 文字です。
可用性レプリカ: 各可用性グループでは、1 つのプライマリ レプリカと最大 8 つのセカンダリ レプリカがサポートされます。 すべてのレプリカを非同期コミット モードで実行することも、最大 5 つのレプリカを同期コミット モードで実行することもできます (1 つのプライマリ レプリカと 2 つの同期セカンダリ レプリカ)。 各レプリカには、Windows と SQL Server の両方で一意のサーバー名が必要です。 サーバー名は Windows と SQL Server の間で一致する必要があります。
コンピューターあたりの可用性グループおよび可用性データベースの最大数: コンピューター (仮想マシンまたは物理コンピューター) に実際に配置できるデータベースおよび可用性グループの数はハードウェアとワークロードによって異なりますが、強制的な制限はありません。 Microsoft では物理マシンあたり最大 10 AG および 100 DB までをテストしていますが、これはバインドの上限ではありません。 サーバー上のハードウェア仕様とワークロードに応じて、SQL Server のインスタンス上により多くのデータベースと可用性グループを配置できます。 過剰な負荷がかかっているシステムには、ワーカー スレッドの枯渇、可用性グループ システム ビューおよび DMV の応答の遅延、ディスパッチャー システム ダンプの一時停止などの症状があります (ただし、これだけではありません)。 アプリケーション SLA 内でピーク ワークロード容量を処理できることを確認するために、実稼働環境と同様のワークロードを使用して環境を十分にテストしてください。 SLA を検討する際は、障害条件下の負荷や期待される応答時間を考慮してください。
可用性グループの操作のために、フェールオーバー クラスター マネージャーを使用してしないでください。 SQL Server FCI の状態は SQL Server と Windows Failover Cluster (WSFC) の間で共有されます。SQL Server には、インスタンスに関する情報が、クラスターよりも詳細にわたって保存されます。 管理モデルは、SQL Server によるトランザクションの促進を必要とするものであり、クラスターの状態の表示を SQL Server の状態の表示に同期させたまま保持する役目を持っています。 クラスターの状態が SQL Server の外部で変更された場合、WSFC と SQL Server の間で状態が同期していないことがあり、予想外の動作が引き起こされる可能性があります。
次に例を示します。
可用性グループのプロパティ (たとえば、有効な所有者) を変更しないでください。
フェールオーバー クラスター マネージャーを使用して可用性グループをフェールオーバーしないでください。 Transact-SQL または SQL Server Management Studio を使用する必要があります。
可用性グループ ロールに関連付けられているリソースを追加したり、依存関係を変更したりしないでください。 フェールオーバーのパフォーマンスに悪影響を及ぼす可能性があるため、追加のリソース (ユーザーまたはサード パーティを含む) を可用性グループ ロールに配置したり、ロールの依存関係を変更したりすることは推奨していません。
前提条件 (可用性グループ)
可用性グループの構成を作成したり再構成したりする場合は、次の要件を満たす必要があります。
| 前提条件 | 説明 |
|---|---|
| SQL Server フェールオーバー クラスター インスタンス (FCI) を使用して可用性レプリカをホストする予定がある場合は、FCI の制限を確実に理解し、FCI の要件が満たされていることを確認してください。 | SQL Server のフェールオーバー クラスター インスタンス (FCI) を使用して可用性レプリカをホストするための前提条件と制限 (このトピックの前半) |
セキュリティ (可用性グループ)
セキュリティは WSFC から継承されます。 Windows Server フェールオーバー クラスタリングには、クラスター全体の粒度で 2 レベルのユーザー セキュリティがあります。
読み取り専用アクセス
フル コントロール
Always On 可用性グループ はフル コントロールを必要とします。また、Always On 可用性グループ を有効にした SQL Server のインスタンスには、クラスターのフル コントロール権限が (サービス SID を介して) 与えられます。
サーバー インスタンスのセキュリティをクラスター マネージャーで直接追加したり削除したりすることはできません。 クラスター セキュリティ セッションを管理するには、SQL Server 構成マネージャーまたはそれに相当する SQL Server の WMI を使用します。
SQL Server の各インスタンスには、レジストリやクラスターにアクセスするための権限が必要です。
Always On 可用性グループ 可用性レプリカをホストするサーバー インスタンス間の接続は暗号化するようにお勧めします。
アクセス許可 (可用性グループ)
| タスク | 必要なアクセス許可 |
|---|---|
| 可用性グループの作成 | sysadmin 固定サーバー ロールのメンバーシップと、CREATE AVAILABILITY GROUP サーバー権限、ALTER ANY AVAILABILITY GROUP 権限、CONTROL SERVER 権限のいずれかが必要です。 |
| 可用性グループの変更 | 可用性グループの ALTER AVAILABILITY GROUP 権限、CONTROL AVAILABILITY GROUP 権限、ALTER ANY AVAILABILITY GROUP 権限、または CONTROL SERVER 権限が必要です。 さらに、データベースを可用性グループに参加させるには、 db_owner 固定データベース ロールのメンバーシップが必要です。 |
| 可用性グループの削除 | 可用性グループの ALTER AVAILABILITY GROUP アクセス許可、CONTROL AVAILABILITY GROUP アクセス許可、ALTER ANY AVAILABILITY GROUP アクセス許可、または CONTROL SERVER アクセス許可が必要です。 ローカル レプリカの場所でホストされていない可用性グループを削除するには、その可用性グループ上の CONTROL SERVER アクセス許可または CONTROL アクセス許可が必要です。 |
関連タスク (可用性グループ)
可用性データベースの前提条件と制限
可用性グループに追加するデータベースは、次の前提条件と制限を満たしている必要があります。
このセクションの内容:
チェック リスト: 要件 (可用性データベース)
可用性グループに追加するデータベースは、次の条件を満たしている必要があります。
| 必要条件 | Link |
|---|---|
| ユーザー データベースであること。 システム データベースを可用性グループに追加することはできません。 | |
| 可用性グループの作成先となる SQL Server のインスタンス上に存在し、そのサーバー インスタンスからアクセスできること。 | |
| 読み取り/書き込み可能なデータベースであること。 読み取り専用データベースを可用性グループに追加することはできません。 | sys.databases (is_read_only = 0) |
| マルチユーザー データベースであること。 | sys.databases (user_access = 0) |
| AUTO_CLOSE が使用されていないこと。 | sys.databases (is_auto_close_on = 0) |
| 完全復旧モデルを使用します。 | sys.databases (recovery_model = 1) |
| データベースの完全バックアップが少なくとも 1 つ存在すること。 注: データベースを完全復旧モデルに設定した後、完全復旧ログ チェーンを開始するには完全バックアップが必要です。 |
データベースの完全バックアップの作成 |
| 既存の可用性グループに属していないこと。 | sys.databases (group_database_id = NULL) |
| データベース ミラーリング用に構成されていないこと。 | sys.database_mirroring (データベースがミラー化の対象となっていない場合、"mirroring_" で始まるすべての列は NULL) |
| FILESTREAM を使用するデータベースを可用性グループに追加する前に、その可用性グループの可用性レプリカをホストしている (またはこれからホストする) すべてのサーバー インスタンスで FILESTREAM が有効になっていることを確認してください。 | FILESTREAM の有効化と構成 |
| 包含データベースを可用性グループに追加する前に、その可用性グループの可用性レプリカをホストしている (またはこれからホストする) 各サーバー インスタンスで、 contained database authentication サーバー オプションが 1 に設定されていることを確認してください。 | contained database authentication サーバー構成オプション サーバー構成オプション (SQL Server) |
注意
Always On 可用性グループ は、サポートされているすべてのデータベース互換性レベルで動作します。
制限事項 (可用性データベース)
セカンダリ データベースのファイル パス (ドライブ文字を含む) が、対応するプライマリ データベースのパスと異なる場合、次の制限が適用されます。
新しい可用性グループ ウィザード/可用性グループへのデータベース追加ウィザード:[完全] オプションはサポートされていません ([最初のデータの同期を選択] (Always On 可用性グループ ウィザード) ページ)。
RESTORE WITH MOVE: セカンダリ データベースを作成するには、セカンダリ レプリカをホストする SQL Server の各インスタンス上で、WITH MOVE を使用してデータベース ファイルを復元する必要があります。
ファイルの追加操作への影響: 後でファイルの追加操作をプライマリ レプリカで実行した場合、セカンダリ データベースでエラーが発生する可能性があります。 この操作の失敗によってセカンダリ データベースが中断する可能性があります。 セカンダリ データベースが中断すると、セカンダリ レプリカが "NOT SYNCHRONIZING" 状態になります。
注意
ファイルの追加操作が失敗した場合の対処については、「失敗したファイルの追加操作のトラブルシューティング (Always On 可用性グループ)」を参照してください。
可用性グループに現在属しているデータベースを削除することはできません。
TDE で保護されたデータベースの補足情報
透過的なデータ暗号化 (TDE) を使用する場合、他のキーの作成および暗号化解除を行うための証明書または非対称キーは、可用性グループの可用性レプリカをホストするすべてのサーバー インスタンスで同じである必要があります。 詳細については、「 別の SQL Server への TDE で保護されたデータベースの移動」を参照してください。
アクセス許可 (可用性データベース)
データベースに対する ALTER 権限が必要です。
関連タスク (可用性データベース)
| タスク | [アーティクル] |
|---|---|
| セカンダリ データベースの準備 (手動) | Always On 可用性グループに対するセカンダリ データベースの準備 |
| 可用性グループへのセカンダリ データベースの参加 (手動) | セカンダリ データベースの Always On 可用性グループへの参加 |
| 可用性データベースの数の変更 | Always On 可用性グループへのデータベースの追加 可用性グループからのセカンダリ データベースの削除 (SQL Server) Always On 可用性グループからのプライマリ データベースの削除 |
関連するコンテンツ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示