ノート:

OCIへのDR用のMicrosoft SQL Server分散Always On可用性グループのデプロイ

イントロダクション

Distributed Always On可用性グループ(分散可用性グループ)は、SQL Serverの従来の可用性グループの機能を拡張するMicrosoft SQL Serverの強力な機能です。

分散可用性グループを使用すると、異なるOracle Cloud Infrastructure (OCI)リージョンで実行されている複数のWindows Serverフェイルオーバー・クラスタ(WSFC)にまたがるディザスタ・リカバリ(DR)ソリューションを作成できます。

これにより、OCIで実行されているクリティカルなSQL Serverデータベースの可用性、ディザスタ・リカバリ機能および地理的分散を高レベルで実現できます。

このチュートリアルの除外

このチュートリアルでは、単一の Microsoft SQL Server Always On可用性グループの段階的な作成については説明しません。詳細は、OCIでのHAおよびDR用のMicrosoft SQL Server Always On可用性グループのデプロイを参照してください。

次の公式の Microsoftドキュメントを参照してください。

目的

前提条件

タスク1: 分散可用性グループの作成

すでに実行されている2つの基礎となるAlways On可用性グループで構成される分散可用性グループ(distributed-aoag)を作成します。

すでに説明したように、2つの独立したAlways On可用性グループが、すでに2つの異なるOCIリージョンで稼働していると想定しています。

2番目のAlways On可用性グループ(marseille-aoag)は、スタンバイ・グループにはデータベースが関連付けられていないため、実際には、2番目のAlways On可用性グループは、分散可用性グループの作成前に空である必要があるため、可用性データベースが関連付けられていません。2つ目のAlways On可用性グループは、初期データベースを関連付けて通常どおり作成でき、その後、2つ目のAlways On可用性グループの作成にのみ使用されたこのデータベースを削除できます。これは、グラフィカル・インタフェースでは、データベースに関連付けられたAlways On可用性グループを作成できないためです。

  1. 最初のAlways On可用性グループで分散可用性グループを作成します。

    最初のサーバー(この例ではParisサイトのsql-srv1ノード)でSQL Serverに接続し、次のSQLコマンドを実行します。

    ノート:

    • リスナー名は、paris-sql-listおよびmars-sql-listです。

    • 使用するTCPポート、5022はエンドポイントのポートであり、使用する必要があります。これは通常、リスナー・ポート(1433)とは異なります。

    • 可用性グループ名は、すでに実行されているAlways On可用性グループで使用される名前にしてください。

    USE MASTER;
    CREATE AVAILABILITY GROUP [distributed-aoag]  
       WITH (DISTRIBUTED)   
       AVAILABILITY GROUP ON  
          'paris-aoag' WITH    
          (   
             LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022',    
             AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
             FAILOVER_MODE = MANUAL,   
             SEEDING_MODE = AUTOMATIC   
          ),   
          'marseille-aoag' WITH    
          (   
             LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022',   
             AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
             FAILOVER_MODE = MANUAL,   
             SEEDING_MODE = AUTOMATIC   
          );    
    GO
    
  2. 2番目のAlways On可用性グループで分散可用性グループに参加します。

    2番目のAlways On可用性グループ(Marseilleサイトsql-srv3サーバー)の最初のサーバーでSQL Serverに接続し、次のSQLコマンドを実行します。

    USE MASTER;
    ALTER AVAILABILITY GROUP [distributed-aoag]   
       JOIN   
       AVAILABILITY GROUP ON  
          'paris-aoag' WITH    
          (   
             LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022',    
             AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
             FAILOVER_MODE = MANUAL,   
             SEEDING_MODE = AUTOMATIC   
          ),   
          'marseille-aoag' WITH    
          (   
             LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022',   
             AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
             FAILOVER_MODE = MANUAL,   
             SEEDING_MODE = AUTOMATIC   
          );    
    GO 
    
  3. 従来の可用性グループとは異なり、分散可用性グループはWSFCのリソース・グループやロールを必要としないことを理解することが重要です。すべてのメタデータはSQL Server内で管理されます。つまり、SQL Server Management Studioでも、分散可用性グループ内のデータベースの名前は直接表示されません。

    この情報を表示するには、次のTransact-SQLスクリプトを実行します。

    --View metadata and status of the Distributed Availability Group
    SELECT r.replica_server_name, r.endpoint_url,
    rs.connected_state_desc, rs.role_desc, rs.operational_state_desc,
    rs.recovery_health_desc,rs.synchronization_health_desc,
    r.availability_mode_desc, r.failover_mode_desc
    FROM sys.dm_hadr_availability_replica_states rs 
    INNER JOIN sys.availability_replicas r
    ON rs.replica_id=r.replica_id
    ORDER BY r.replica_server_name   
    

    イメージ

ノート:リージョン間の潜在的なネットワーク・レイテンシに対応するために、プライマリおよびセカンダリAlways On可用性グループを非同期コミット・レプリケーションで構成しました。これにより、プライマリ・データベースのパフォーマンス・オーバーヘッドが最小限に抑えられます。各Always On可用性グループ内で、高可用性を確保するために、レプリカ間の同期コミット・レプリケーションを選択しました。ただし、非同期コミット・レプリカ間のフェイルオーバー(分散可用性グループの場合)では、データ損失を減らすには、フェイルオーバーを開始する前に同期コミット・モードへの一時的な切替えが必要です。failover_modeの場合、分散可用性グループに使用可能なモードは手動のみです。

タスク2: 分散可用性グループのフェイルオーバー手順

このタスクでは、2つのAlways On可用性グループ間のフェイルオーバーについて説明します。データベースのフェイルオーバー手順は、次の簡単な手順とチェックによって構成されます。

ステップに従います。

  1. 次のスクリプトを実行して、同期が正常かどうかを確認します。まず、現在のプライマリ・サイトの現在のプライマリSQLで、次にセカンダリ・サイトのプライマリSQLで確認します。

    実行結果は、CONNECTED_STATE = CONNECTEDおよびSYNCHRONIZATION_HEALTH = HEALTHYである必要があります。

    select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
       ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
       join sys.availability_replicas ar on ag.group_id=ar.group_id
       left join sys.dm_hadr_availability_replica_states ars
       on ars.replica_id=ar.replica_id
       where ag.is_distributed=1
    GO
    

    イメージ

    イメージ

  2. 可用性モードを変更します。次のスクリプトを、まず現在のプライマリ・サイトの現在のプライマリSQL Serverで実行し、次にセカンダリ・サイトのプライマリSQL Serverで実行します。

    --Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG
    USE MASTER;     
    ALTER AVAILABILITY GROUP [distributed-aoag]     
    MODIFY 
    AVAILABILITY GROUP ON
    'paris-aoag' WITH 
    ( 
       AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
    ), 
    'marseille-aoag' WITH     
    ( 
       AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
    );
    
  3. データ損失がないことを確認するには、このステップの結果を確認します。ステータスはSYNCHRONIZEDで、last_hardened_lsnはグローバル・プライマリとフォワーダの両方のデータベースごとに一致する必要があります。

    -- Run this query on the Global Primary and the forwarder
    -- Check the results to see if synchronization_state_desc is SYNCHRONIZED, and the last_hardened_lsn is the same per database on both the global primary and forwarder 
    -- If not rerun the query on both side every 5 seconds until it is the case
    --
    SELECT ag.name
             , drs.database_id
             , db_name(drs.database_id) as database_name
             , drs.group_id
             , drs.replica_id
             , drs.synchronization_state_desc
             , drs.last_hardened_lsn  
    FROM sys.dm_hadr_database_replica_states drs 
    INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;
    

    イメージ

    イメージ

  4. 現在のプライマリ・サイトの現在のプライマリSQL ServerでREQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITを設定する準備ができました。

    --Run this script into Primary AOAG
    USE MASTER;
    ALTER AVAILABILITY GROUP [distributed-aoag]
    SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
    

    これで、プライマリAlways On可用性グループのロールをプライマリからセカンダリに変更する準備ができました。

    --Run this script into Primary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG
    USE MASTER;
    ALTER AVAILABILITY GROUP [distributed-aoag] SET (ROLE = SECONDARY);
    

    イメージ

  5. セカンダリAlways On可用性グループのロールをセカンダリからプライマリに変更します。次のスクリプトは、このロール変更を実行し、データベースの読取りまたは書込み操作を有効にします。また、分散可用性グループ内のAlways On可用性グループのロールもそれに応じて更新されます。

    --Run this script into Secondary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG
    ALTER AVAILABILITY GROUP [distributed-aoag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
    

    ステータスを確認するには、次のスクリプトを実行します。

    --check the status on the new primary (formerly standby site)
    select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
       ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
       join sys.availability_replicas ar on ag.group_id=ar.group_id
       left join sys.dm_hadr_availability_replica_states ars
       on ars.replica_id=ar.replica_id
       where ag.is_distributed=1
    GO
    

    イメージ

    イメージ

  6. 新しいプライマリSQL Serverで、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITの設定を解除します。

    --Run this script into Primary AOAG
    ALTER AVAILABILITY GROUP [distributed-aoag] 
    SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
    

    プライマリ・サイトとセカンダリ・サイトの両方で次のスクリプトを実行して、可用性モードを標準モードに戻します。

    --Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG
    ALTER AVAILABILITY GROUP [distributed-aoag]     
    MODIFY 
    AVAILABILITY GROUP ON
    'paris-aoag' WITH 
    ( 
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT 
    ), 
    'marseille-aoag' WITH     
    ( 
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT 
    );
    

タスク3: 分散Always On可用性グループのフェイルバック手順

プライマリ・サイトとしてParisを復元し、セカンダリ・サイトとしてMarseilleを復元するには、タスク2で概説されているように、新しいスイッチオーバーを実行して同期を元に戻します。

承認

その他の学習リソース

docs.oracle.com/learnの他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。

製品ドキュメントは、Oracle Help Centerを参照してください。