ライフサイクル

システム上でライフサイクル中に異なる操作が実行されます。最も関連性の高いものは、スイッチオーバーして、検証やパッチ適用などのためにセカンダリをテストまたはオープンすることです。

スイッチオーバーの実行

スイッチオーバーは、管理者が2つのサイトの役割を元に戻す計画された操作です。スイッチオーバー後は、プライマリシステムがセカンダリになり、セカンダリシステムがプライマリになります。スイッチオーバーを実行すると、プライマリ・サイトで停止時間が発生します。

スイッチオーバーは、標準の手順に従って実行されます(Oracle WebLogic Server for Oracle Cloud Infrastructureのディザスタ・リカバリおよびOracle Cloud Infrastructure MarketplaceのSOA Suiteのディザスタ・リカバリのスイッチオーバーを参照してください)。

  1. 「進行中の構成レプリケーションの設定」に記載されている手順に従って、保留中の構成変更を伝播します。
  2. プライマリ・サイトのサーバーを停止します。
  3. DNS名をスイッチオーバーします。
  4. データベースのスイッチオーバー。
  5. セカンダリサイトのサーバーを起動します。

主な違いは、Oracle Cloud Infrastructure (OCI)コンソールのみがOracle Autonomous Databaseインスタンスのスイッチオーバーに使用されることです。

ノート:

リモート・リフレッシュ可能クローンの場合、永続的なスイッチオーバーが実行された場合(セカンダリが永続的でないテストまたは検証を超えてプライマリになった場合)、元のプライマリ・リージョンにピア・リフレッシュ可能クローンを作成して、新しいスタンバイ(元のプライマリ)でテストおよび検証用のセカンダリ・システムを保持する必要があります。セカンダリ内のリフレッシュ可能クローンは、ソースがスタンバイになるため、再接続できなくなります(リフレッシュ可能クローンは、スタンバイOracle Autonomous Database Serverlessから作成、メンテナンスまたは接続できません)。再度リフレッシュすることはできません。また、必要に応じてデータベースを削除してコストを削減できます。元のプライマリ(現在のスタンバイ)に新しいリフレッシュ可能クローンを作成するには、最初のものと同じ手順に従います。

スイッチオーバー操作に対して次のステップを実行します。

  1. スイッチオーバーの実行中にスケジュールされたレプリケーションを無効にします。これは、障害が発生してスイッチオーバー操作自体に干渉する可能性があるためです。
  2. プライマリ・サイトのサーバーを停止します。
    Oracle WebLogic Administration Serverコンソールまたはスクリプトを使用して、プライマリ・サイトのOracle WebLogic Serverインスタンスを停止します。

    ノート:

    スイッチオーバー中、プライマリ・サイトの管理サーバーは稼働したままにできます。ただし、サイトがスタンバイ・ロールの場合は停止することをお薦めします。これは、スタンバイ・サイトのドメイン構成がライフサイクル中にプライマリ構成によってオーバーライドされることが想定されているためです。管理サーバーが稼働している場合、そのサーバーは失効した構成で実行されます。
  3. フロントエンドDNS名をスイッチオーバーします。

    システムで使用される名前をホストしているDNSサーバーで必要なDNSプッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロントエンド仮想名をセカンダリ・サイトのLoad Balancerで使用されるパブリックIPにポイントします。

    DNSが外部フロント・エンド解決(OCI DNSや商用DNSなど)に使用されるシナリオでは、APIを使用して変更をプッシュできます。OCI DNSでこの変更をプッシュする例を確認するには、GitHub (フロントエンドDNSを更新するスクリプトの例)に移動します。

    ノート:

    DNSエントリのTTL値がスイッチオーバーのRTOに影響します。TTLの値が大きい(20分など)と、DNSの変更がクライアントで有効になるのに、それと同じ時間がかかります。TTLの値を小さくすると、この処理は短時間で行われますが、キャッシュされた名前を使用するのではなく、クライアントがDNSにヒットする頻度が高くなるため、オーバーヘッドの原因になる可能性があります。DNSの変更前に、TTLを一時的に小さい値(1分など)に設定することをお薦めします。その後、変更を行い、スイッチオーバーの手順が完了したら、TTLを元の値に戻します。
  4. SECONDARY REGIONのOracle Cloud Infrastructure (OCI)コンソールにログインし、Autonomous Databaseに移動します。
  5. Oracle WebLogicデータベースをホストしているコンパートメントを選択し、データベース名をクリックします。
  6. 「他のアクション」ドロップダウン・メニューから「スイッチオーバー」を選択し、スタンバイ・データベース名の入力を確認します。
  7. 操作が完了するのを待ちます。

    ステータスは、左側の「リソース」の下の「作業リクエスト」メニューに表示されます。

  8. セカンダリ管理サーバーを起動します(または、すでに起動されている場合は再起動するため、スタンバイ中にレプリケートされた構成の変更が有効になります)。
  9. セカンダリ管理対象サーバーを起動します(Oracle WebLogic Serverコンソールまたはスクリプトを使用)。

フェイルオーバーの実行

フェイルオーバー操作は、プライマリ・サイトが使用可能になると実行され、通常は計画されていない操作です。元のプライマリ・データベースに障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、スタンバイ・データベースのプライマリ・データベースへのロール・トランジションを実行できます。

プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースに一貫性があったかどうかによって、データが損失する場合があります。フェイルオーバー手順はスイッチオーバー手順と似ていますが、かわりにデータベースでスイッチオーバー操作を実行します。

通常、フェイルオーバー操作は、停止がプライマリ・リージョンに影響したときに実行されます。したがって、プライマリで実行できないタスクがある場合があります。たとえば、ホストにアクセスできないため、プライマリでOracle WebLogic Serverプロセスを停止できない場合があります。

  1. 可能な場合は、プライマリ・サイトのWebLogicサーバーを停止します。
  2. DNS名をスイッチオーバーします。
  3. データベースをフェイルオーバーします。

    ノート:

    Oracle Autonomous Database Serverlessを使用する場合、フェイルオーバー・リンクは、プライマリ・データベースが使用できず、スタンバイ・データベースが使用可能な場合にのみ表示されます。APIを使用して、いつでも手動フェイルオーバーを開始できます
  4. セカンダリ・サイトのサーバーを起動します。
  5. フェイルオーバー操作が終了し、以前のプライマリサイトが再度アクセス可能になったら、次の手動タスクを実行して、システムを将来のスイッチバック用に準備する必要があります。
    1. 失敗したサイトでOracle WebLogic Serverプロセスを停止します。
      フェイルオーバー中にそれらを停止しなかった場合、プロセスがハングしている可能性があります。停止していることを確認します。
    2. Oracle Autonomous Database Serverlessの場合、障害が発生したプライマリを手動で回復する必要はありません。
      手動のOracle Autonomous Data Guardフェイルオーバー後、スタンバイ・データベースは自動的に再接続されるか、リージョンがオンラインに戻ったときに自動的に(透過的に)再プロビジョニングされます。
    3. Oracle Autonomous Database on Dedicated Exadata Infrastructureの場合、「詳細」ページから、失敗したコンテナ・データベースを有効なスタンバイ・ロールに回復します。
      フェイルオーバー後、スタンバイ・コンテナ・データベースのロールが「プライマリ」になり、プライマリ・コンテナ・データベースのロールが「使用不可」状態の「無効スタンバイ」になります。
    4. (新しいプライマリから新しいスタンバイへの)構成レプリカの正しい実行を確認します。