Articles

Always Onの可用性グループとは何ですか？

Posted on
  • 2020年04月29日
  • 所要時間14分
    • c
    • M
    • D
    • B
    • V
    • +13

該当するもの。 yesSQL Server (サポートされているすべてのバージョン)

このトピックでは、SQL Server で 1 つまたは複数の可用性グループを構成および管理する際の中心となる、常時稼働の可用性グループの概念を紹介します。 アベイラビリティ グループが提供するメリットの概要と、常時稼働型アベイラビリティ グループの用語の概要については、「常時稼働型アベイラビリティ グループ（SQL Server）」を参照してください。 アベイラビリティ グループは、高可用性（HA）またはリードスケールのために作成することができます。 HA アベイラビリティ グループは、一緒にフェイルオーバーするデータベースのグループです。 リード スケール アベイラビリティ グループは、読み取り専用の作業負荷のために SQL Server の他のインスタンスにコピーされるデータベースのグループです。 可用性の高いグループは、1つのプライマリデータベースと、それに対応する1～8つのセカンダリデータベースをサポートします。 セカンダリ データベースはバックアップではありません。

ヒント

プライマリ データベースのバックアップは、どのような種類のものでも作成できます。 また、セカンダリ データベースのログ バックアップやコピー専用のフル バックアップを作成することもできます。 詳細については、「アクティブなセカンダリ」を参照してください。

各セットのアベイラビリティ データベースは、アベイラビリティ レプリカによってホストされています。 アベイラビリティ レプリカには、プライマリ データベースをホストする1つのプライマリ レプリカと、セカンダリ データベースをホストし、アベイラビリティ グループのフェイルオーバー対象となる1つから8つのセカンダリ レプリカの2種類があります。 アベイラビリティグループのフェイルオーバーは、アベイラビリティレプリカのレベルで行われます。 アベイラビリティーレプリカは、1つのアベイラビリティーグループ内のデータベースのセットに対して、データベースレベルでのみ冗長性を提供します。

プライマリレプリカは、プライマリデータベースをクライアントからの読み書き可能な接続にします。 プライマリレプリカは、各プライマリデータベースのトランザクションログレコードをすべてのセカンダリデータベースに送信します。 このプロセスはデータ同期と呼ばれ、データベースレベルで行われます。 すべてのセカンダリレプリカは、トランザクションログレコードをキャッシュし（ログをハードニングし）、それを対応するセカンダリデータベースに適用します。 データ同期は、プライマリデータベースと、接続されている各セカンダリデータベースの間で、他のデータベースとは無関係に行われます。

オプションとして、1つまたは複数のセカンダリ レプリカを構成してセカンダリ データベースへの読み取り専用アクセスをサポートしたり、任意のセカンダリ レプリカを構成してセカンダリ データベースへのバックアップを許可することができます。

SQL Server 2017 では、可用性グループに2つの異なるアーキテクチャが導入されています。 Always On アベイラビリティ グループは、高可用性、ディザスタ リカバリ、およびリード スケール バランシングを提供します。 これらのアベイラビリティ グループには、クラスタ マネージャが必要です。 Windowsでは、フェイルオーバー クラスタリングがクラスタ マネージャを提供します。 Linuxでは、Pacemakerを使用することができます。 もう1つのアーキテクチャは、リードスケールアベイラビリティグループです。 リードスケールアベイラビリティグループは、読み取り専用のワークロードに対してレプリカを提供しますが、高可用性はありません。

Windows上でHAのためのAlways Onアベイラビリティグループを展開するには、Windows Server Failover Cluster(WSFC)が必要です。 あるアベイラビリティ グループの各アベイラビリティ レプリカは、同じ WSFC の異なるノードに存在する必要があります。

注

Linuxでのアベイラビリティーグループについては、LinuxでのSQL Serverの常時接続アベイラビリティーグループを参照してください。

HA構成では、作成したアベイラビリティーグループごとにクラスターロールが作成されます。 WSFCクラスターはこのロールを監視して、プライマリ・レプリカの健全性を評価します。 常時稼働グループのクォーラムは、あるクラスタ・ノードが可用性レプリカをホストしているかどうかにかかわらず、WSFCクラスタのすべてのノードに基づいています。

注意事項

SQL Server Always OnコンポーネントとWSFCクラスターの関係については、「Windows Server Failover Clustering (WSFC) with SQL Server」を参照してください。

5つのレプリカを持つアベイラビリティ グループ

アベイラビリティ データベース

アベイラビリティ グループにデータベースを追加するには、プライマリ レプリカをホストしているサーバー インスタンス上に存在する、オンラインの読み書き可能なデータベースである必要があります。 データベースを追加すると、そのデータベースはプライマリ データベースとしてアベイラビリティ グループに参加し、クライアントが利用できる状態になります。 新しいプライマリ データベースのバックアップをセカンダリ レプリカをホストするサーバー インスタンスにリストアする（RESTORE WITH NORECOVERY を使用）までは、対応するセカンダリ データベースは存在しません。 新しいセカンダリデータベースは、アベイラビリティグループに参加するまでRESTORING状態になります。

参加すると、セカンダリ データベースはONLINE状態になり、対応するプライマリ データベースとのデータ同期が開始されます。 データ同期とは、プライマリ データベースへの変更がセカンダリ データベースに再現されるプロセスです。

重要

可用性のあるデータベースは、Transact-SQL、PowerShell、および SQL Server Management Objects (SMO) の名前でデータベース レプリカと呼ばれることがあります。 たとえば、アベイラビリティ データベースに関する情報を返す Always On ダイナミック管理ビューの名前である sys.dm_hadr_database_replica_states および sys.dm_hadr_database_replica_cluster_states では、「データベース レプリカ」という用語が使用されています。 しかし、SQL Server Books Onlineでは、「レプリカ」という言葉は、通常、アベイラビリティ レプリカを指します。

可用性レプリカ

各可用性グループは、可用性レプリカと呼ばれる2つ以上のフェイルオーバー パートナーのセットを定義します。 アベイラビリティ レプリカは、アベイラビリティ グループのコンポーネントです。 各アベイラビリティ レプリカは、アベイラビリティ グループ内のアベイラビリティ データベースのコピーをホストします。 特定のアベイラビリティ グループでは、アベイラビリティ レプリカは、WSFC クラスタの異なるノードに存在する SQL Server の個別のインスタンスによってホストされている必要があります。

1つのインスタンスがホストできるアベイラビリティ レプリカは、アベイラビリティ グループごとに1つだけです。

1つのインスタンスは、1つのアベイラビリティ グループに対して1つのアベイラビリティ レプリカしかホストできません。 インスタンスには、スタンドアロン インスタンスと、SQL Server フェイルオーバー クラスタ インスタンス (FCI) があります。

すべてのアベイラビリティ レプリカには、プライマリ ロールまたはセカンダリ ロールのいずれかの初期ロールが割り当てられ、そのレプリカのアベイラビリティ データベースに継承されます。 レプリカの役割は、そのレプリカが読み書き可能なデータベースをホストするか、読み取り専用のデータベースをホストするかを決定します。 プライマリレプリカと呼ばれる1つのレプリカには、プライマリロールが割り当てられ、読み書き可能なデータベース（プライマリデータベース）をホストします。 他の少なくとも1つのレプリカ（セカンダリレプリカ）には、セカンダリの役割が割り当てられています。

注意

フェイルオーバーなどでアベイラビリティ レプリカの役割が確定していない場合、そのデータベースは一時的に「NOT SYNCHRONIZING」の状態になります。 アベイラビリティー・レプリカの役割が解決するまで、そのデータベースの役割は「RESOLVING」に設定されます。 アベイラビリティー・レプリカがプライマリの役割に解決した場合、そのデータベースはプライマリ・データベースになります。

可用性モード

可用性モードは、各アベイラビリティ レプリカのプロパティです。 アベイラビリティー モードは、プライマリ レプリカがデータベース上のトランザクションのコミットを、特定のセカンダリ レプリカがトランザクション ログ レコードをディスクに書き込むまで (ログをハードニングするまで) 待つかどうかを決定します。

  • 非同期コミットモード

    このアベイラビリティモードを使用するアベイラビリティレプリカは、非同期コミットレプリカと呼ばれます。 非同期コミット・モードでは、プライマリ・レプリカは、非同期コミット・セカンダリ・レプリカがログをハードニングしたという確認を待たずにトランザクションをコミットします。

  • 同期コミットモード

    このアベイラビリティー・モードを使用しているアベイラビリティー・レプリカは、同期コミット・レプリカと呼ばれます。 同期コミットモードでは、トランザクションをコミットする前に、同期コミットのプライマリレプリカは、同期コミットのセカンダリレプリカがログのハードニングを完了したことを確認するのを待ちます。 同期コミットモードでは、あるセカンダリデータベースがプライマリデータベースと同期した時点で、コミットしたトランザクションが完全に保護されます。

詳細については、Availability Modes (Always On Availability Groups)を参照してください。

フェイルオーバーの種類

プライマリ レプリカとセカンダリ レプリカの間のセッションでは、フェイルオーバーと呼ばれるプロセスで、プライマリとセカンダリの役割が入れ替わる可能性があります。 フェイルオーバーでは、対象のセカンダリレプリカがプライマリの役割に移行し、新しいプライマリレプリカになります。 新しいプライマリレプリカは、そのデータベースをプライマリデータベースとしてオンラインにし、クライアントアプリケーションがそれらに接続できるようになります。 旧プライマリレプリカが利用可能になると、セカンダリロールに移行してセカンダリレプリカになります。

フェイルオーバーには、自動、手動、強制（データ損失の可能性あり）の3つの形式があります。

  • 同期コミットモードでは、計画的な手動フェイルオーバーと、対象となるセカンダリレプリカがプライマリレプリカと同期している場合の自動フェイルオーバーの2種類のフェイルオーバーをサポートしています。 これらの形式のフェイルオーバーをサポートするかどうかは、フェイルオーバー・パートナーのフェイルオーバー・モード・プロパティの設定によります。 プライマリレプリカまたはセカンダリレプリカのいずれかでフェイルオーバーモードが「手動」に設定されている場合、そのセカンダリレプリカでは手動によるフェイルオーバーのみがサポートされます。

    • 計画的な手動フェイルオーバー（データ損失なし）

      手動フェイルオーバーは、データベース管理者がフェイルオーバー コマンドを発行し、同期されたセカンダリ レプリカがプライマリ ロールに移行し（データ保護が保証されている）、プライマリ レプリカがセカンダリ ロールに移行した後に発生します。

    • 自動フェイルオーバー (データ損失なし)

      自動フェイルオーバーは、同期しているセカンダリレプリカがプライマリの役割に移行する障害に対応して発生します (データ保護は保証されています)。 元のプライマリレプリカが利用可能になると、セカンダリの役割に移行します。 自動フェイルオーバーは、プライマリレプリカと対象となるセカンダリレプリカの両方が同期コミットモードで動作しており、フェイルオーバーモードが「自動」に設定されている必要があります。

      重要なこと

      SQL Server Failover Cluster Instances (FCI) は、可用性グループによる自動フェイルオーバーをサポートしていません。

    注意

    同期しているセカンダリレプリカに強制フェイルオーバーコマンドを発行した場合、セカンダリレプリカは計画された手動フェイルオーバーと同じように動作することに注意してください。

  • 非同期コミット モードでは、フェイルオーバーの唯一の形態は、一般的に強制フェイルオーバーと呼ばれる強制的な手動フェイルオーバー (データ損失の可能性あり) です。 強制的なフェイルオーバーは、手動でしか開始できないため、手動フェイルオーバーの一形態と考えられます。 強制フェイルオーバーは、ディザスターリカバリーのオプションです。

詳細については、「フェイルオーバーとフェイルオーバーのモード（常時稼働の可用性グループ）」を参照してください。

可用性グループ リスナーは、クライアントの接続を適切な可用性レプリカに向けるために、特定の可用性グループに関連付けられたリソースのセットを提供します。

可用性グループ リスナーは、仮想ネットワーク名（VNN）として機能する固有のDNS名、1つまたは複数の仮想IPアドレス（VIP）、およびTCPポート番号に関連付けられます。

ヒント

可用性グループが2つの可用性レプリカしか所有しておらず、セカンダリ レプリカへの読み取りアクセスを許可するように構成されていない場合、クライアントはデータベース ミラーリング接続文字列を使用してプライマリ レプリカに接続することができます。 この方法は、データベースをデータベースミラーリングから常時稼働グループに移行した後、一時的に役立つことがあります。

アクティブ セカンダリ レプリカ

Always Onのアベイラビリティ グループは、アクティブ セカンダリ レプリカをサポートしています。 アクティブ・セカンダリの機能には次のようなサポートがあります：

  • セカンダリ・レプリカでのバックアップ操作の実行

    セカンダリ・レプリカは、データベース全体、ファイル、またはファイルグループのログ・バックアップとコピーのみのバックアップの実行をサポートしています。 可用性グループを構成して、バックアップを実行する場所の優先順位を指定することができます。 この環境設定は、SQL Server によって強制されるものではないため、アドホック バックアップには影響しないことを理解しておく必要があります。 この環境設定の解釈は、特定の可用性グループ内の各データベースのバックジョブにスクリプトを組む場合は、そのロジックに依存します。 個々のアベイラビリティー・レプリカについて、同じアベイラビリティー・グループ内の他のレプリカと比較して、このレプリカでバックアップを実行する際の優先順位を指定することができます。 詳細については、「アクティブなセカンダリ」を参照してください。

  • 1つまたは複数のセカンダリ レプリカへの読み取り専用アクセス（読み取り可能なセカンダリ レプリカ）

    すべてのセカンダリ アベイラビリティ レプリカは、そのローカル データベースへの読み取り専用アクセスのみを許可するように設定できますが、一部の操作は完全にはサポートされていません。 これにより、セカンダリレプリカへの読み書き可能な接続の試みができなくなります。 また、プライマリレプリカでは、読み取り/書き込みのアクセスのみを許可することで、読み取り専用のワークロードを防ぐことができます。 これにより、プライマリレプリカへの読み取り専用の接続が行われなくなります。 詳細については、「アクティブなセカンダリ」を参照してください。 Readable Secondary Replicas (Always On Availability Groups).

    可用性グループが現在、可用性グループ リスナーと 1 つ以上の読み取り可能なセカンダリ レプリカを所有している場合、SQL Server は読み取り目的の接続要求をそのうちの 1 つにルーティングすることができます (読み取り専用のルーティング)。 詳細については、「可用性グループ リスナー、クライアント接続、およびアプリケーションのフェイルオーバー (SQL Server)」を参照してください。

セッション タイムアウト期間

セッション タイムアウト期間は、可用性レプリカのプロパティであり、別の可用性レプリカとの接続が閉じられるまでの非アクティブ状態の期間を決定します。 プライマリ・レプリカとセカンダリ・レプリカは、アクティブであることを示すために互いにpingを打ちます。 タイムアウト期間中に他のレプリカからpingを受信すると、接続がまだ開いていて、サーバー・インスタンスが通信していることを示します。

セッション・タイムアウト期間は、どちらかのレプリカがもう一方のレプリカからのpingの受信を無期限に待つことを防ぎます。 セッション・タイムアウト期間内に相手のレプリカから ping を受信しなかった場合、そのレプリカはタイムアウトします。 接続が終了し、タイムアウトしたレプリカは「DISCONNECTED」状態になります。 切断されたレプリカが同期コミットモードに設定されていたとしても、トランザクションはそのレプリカの再接続と再同期を待ちません。 この値はユーザーが設定可能で、最低でも5秒となっています。 一般的には、タイムアウト期間を10秒以上に設定することをお勧めします。

注意

解決役ではpingが発生しないため、セッションタイムアウト期間は適用されません。

自動ページ修復

各アベイラビリティレプリカは、データページの読み取りを妨げる特定の種類のエラーを解決することで、ローカルデータベースの破損したページからの自動回復を試みます。 セカンダリのレプリカがページを読み取れない場合、そのレプリカはプライマリのレプリカにページの新しいコピーを要求します。 プライマリ・レプリカがページを読み取れない場合、レプリカはすべてのセカンダリ・レプリカに新鮮なコピーの要求をブロードキャストし、最初に応答したものからページを取得します。

詳細については、「ページの自動修復（可用性グループ：データベースミラーリング）」を参照してください。

関連タスク

  • Getting Started with Always On Availability Groups (SQL Server)

関連コンテンツ

  • Blogs:

    Always On – HADRON Learning Series: HADRON Enabled Databasesのワーカープール使用法

    SQL Server Always On Team Blogs:

    CSS SQL Server Engineers Blogs

  • Videos:

    Microsoft SQL Server Code-Named “Denali” Always On Series,Part 1:

    Microsoft SQL Server Code-Named “Denali” Always On Series,Part 2: Building a Mission-Critical High Availability Solution Using Always On

  • Whitepaper:

    Microsoft SQL Server Always On Solutions Guide for High Availability and Disaster Recovery

    Microsoft White Papers for SQL Server 2012

    SQL Server Customer Advisory Team Whitepapers

See Also

Availability Modes (Always On Availability Groups)
Failover and Failover Modes (Always On Availability Groups)
Overview of Transact-?SQL Statement for Always On Availability Groups (SQL Server)
Overview of Transact-SQL Statements for Always On Availability Groups (SQL Server)
Overview of PowerShell Cmdlets for Always On Availability Groups (SQL Server)
High Availability Support for In-Memory OLTP databases
Prerequisites, 常時稼働グループの前提条件、制限、および推奨事項（SQL Server）
可用性グループの作成と構成（SQL Server）
アクティブなセカンダリ。 読み込み可能なセカンダリ レプリカ (Always On Availability Groups)
Active Secondaries: 利用可能グループのリスナー、クライアントの接続性、およびアプリケーションのフェイルオーバー (SQL Server)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です