コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Microsoft SQL Server の Always On 可用性グループ(AG)を使用すると、複数の SQL Server Enterprise インスタンス間でデータベースを複製できます。
SQL Server フェイルオーバー クラスタ インスタンスと同様に、Always On 可用性グループは Windows Server フェイルオーバー クラスタリング(WSFC)を使用して高可用性を実装します。ただし、この 2 つの機能には次のような違いがあります。
|
Always On 可用性グループ |
フェイルオーバー クラスタ インスタンス |
フェイルオーバーのスコープ |
データベースのグループ |
インスタンス |
ストレージ |
共有なし |
共有 |
詳細な比較については、フェイルオーバー クラスタ インスタンスと可用性グループの比較をご覧ください。
Always On 可用性グループは、複数の可用性モードをサポートしています。このチュートリアルでは、Always On 可用性グループを同期 commit モードでデプロイして、1 つ以上のデータベースの高可用性を実装する方法について説明します。
この設定では、3 つの VM インスタンスを作成します。2 つの VM インスタンス(node-1
と node-2
)がクラスタノードとして機能し、SQL Server を実行します。3 番目の VM インスタンス witness
は、フェイルオーバー シナリオでクォーラムを達成するために使用されます。3 つの VM インスタンスは 3 つのゾーンに分散され、共通のサブネットを共有します。
SQL Server Always On 可用性グループを使用して、サンプル データベース bookshelf
が、2 つの SQL Server インスタンス間で同期的に複製されます。
オンプレミスの Windows Server フェイルオーバー クラスタリング環境では、ARP 通知によって IP アドレスのフェイルオーバーがトリガーされます。ただし、Google Cloudは ARP のアナウンスメントを無視します。そのため、2 つのオプション、内部ロードバランサの使用、または分散ネットワーク名(DNN)の使用のいずれかを実装する必要があります。この記事は、 Google Cloud に Active Directory がデプロイされており、SQL Server、Active Directory、Compute Engine の基本的な知識があることを前提としています。 Google Cloudの Active Directory の詳細については、始める前にセクションをご覧ください。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-21 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-21 UTC。"],[[["Microsoft SQL Server Always On availability groups (AG) replicate databases across multiple SQL Server instances using Windows Server Failover Clustering (WSFC) for high availability."],["AGs differ from Failover Cluster Instances in that they handle failover at the database group level and use non-shared storage, while Failover Cluster Instances fail over the entire instance and rely on shared storage."],["This tutorial demonstrates deploying Always On availability groups in synchronous commit mode, involving three VM instances across three zones: two SQL Server nodes (`node-1`, `node-2`) and one witness node (`witness`) for quorum."],["The example setup replicates a database (`bookshelf`) synchronously across the two SQL Server instances using an Always On availability group."],["Due to Google Cloud's handling of ARP announcements, implementing AGs requires the use of either an internal load balancer or a distributed network name (DNN) for IP address failover, differing from on-premises environments."]]],[]]