サイトのフェイルオーバーおよびリカバリ

インフラストラクチャで計画外のイベントが発生し、プライマリ・サイトが使用できなくなり、ビジネスに悪影響を及ぼす期間、完全にアクセスできなくなった場合は、サイトのフェイルオーバーが必要です。このシナリオでは、スタンバイがプライマリ・ロールを引き受けます。

プライマリ・サイトは、次のものを含め、様々な理由で利用できなくなる可能性があります。

障害が発生したメディアや広範囲に破損したメディア、OSまたはファームウェアのアップグレードなど、プライマリデータベースインスタンスが起動しない可能性のある問題
OCIリージョン・インフラストラクチャ内の全電力または冷却システムの停止などのインフラストラクチャ障害
完全なネットワーク障害
地震、火災、洪水などの自然災害

計画外のイベントはまれですが、発生する可能性があります。

サイトのフェイルオーバーの実行

真のフェイルオーバーは中断を伴い、データが少し失われる可能性があるため、TEST環境でサイトのフェイルオーバーをテストします。

次の例では、アッシュバーンのプライマリ・データベース(CDBHCM_iad1dx)およびフェニックスのスタンバイ・データベース(CDBHCM_phx5s)のテスト環境の名前を使用します。

プライマリ上のすべてのデータベースOracle Real Application Clusters (Oracle RAC)インスタンスを強制的に停止します。

ノート:
本番環境では、このテストを実行しないでください。
```
$ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
```
この時点から、プライマリは完全に使用できません(シミュレートされます)。セカンダリ・リージョンを新しいプライマリ・サイトにします。
次のステップではテスト実装を使用し、すべてのステップはセカンダリ・サイト(新しいプライマリ)で実行されます。

セカンダリ・サイトで、Oracle Exadata Database Service on Dedicated Infrastructure domUsのいずれかにログインし、oracle OSユーザーになり、Data Guard Brokerコマンドライン・インタフェースを起動します。

ノード: 1つのOracle Exadata Database Service on Dedicated Infrastructure domU
ユーザー: oracle

$ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

エラーに注意してください。

Oracle Data Guard Brokerコマンドライン・インタフェースを使用して、フェイルオーバーを実行します。
- ノード:セカンダリ・サイトにある1つのOracle Exadata Database Service on Dedicated Infrastructure domU
- ユーザー: oracle
```
DGMGRL> failover to CDBHCM_phx5s
```
プライマリ中間層(共有ファイル・システムを含む)がまだ変更されていない場合は、障害が発生したプライマリ・サイトからDRサイトに強制rsyncを手動で実行します。

アプリケーション層とWeb層はまだ機能している可能性がありますが、アプリケーションおよびプロセス・スケジューラ・プロセスは、障害が発生したデータベースへの接続の試行に失敗し始めます。これにより、rsyncスクリプトでrsyncの実行が停止します。
- ノード: 1つの中間層、障害が発生したプライマリ・サイト
- ユーザー: psadm2
1. 強制rsyncを実行します。サンプルのrsync_psft.shスクリプトは、scriptsディレクトリにあります。
  rsyncスクリプトが無効になっている場合、-fパラメータは強制rsyncの続行を要求します。強制rsyncは、データベースのロールを確認するためにデータベースを参照せず、リクエストされたrsyncを実行します。
  
  ノート:
  これは、サイト・フェイルオーバー中に最終リフレッシュを強制する場合にのみ実行する必要があります。FORCEオプションを使用すると、ログが記録されます。
```
$ rsync_psft.sh path to file system/parameter file -f
```
  例
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. rsyncプロセス・ログをモニターして、プロセスが正常に完了したことを確認します。
サイト障害が完了し、最終的なrsyncプロセスを実行できない場合は、disable_psft_rsync.shスクリプトを実行して、新しいプライマリでrsyncを無効にします。
- ノード: 1つの中間層、新しいプライマリ・サイト
- ユーザー: psadm2
```
disable_psft_rsync.sh
```
プライマリ・データベース・サーバーとスタンバイ・データベース・サーバーを構成するときにActive Data Guardサポートを構成した場合は、PeopleSoft (PSQUERY)のActive Data Guardサービスが新しいプライマリ・データベースで起動されていることを確認します。
- ノード:セカンダリ・サイトにある1つのOracle Exadata Database Service on Dedicated Infrastructure domU
- ユーザー: oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
このサービスは、すべてのOracle Real Application Clusters (Oracle RAC)インスタンスで実行されている必要があります。

ノート:
このサービスは、プロセススケジューラを起動する前に起動する必要があります。そうしないと、プロセススケジューラは起動時に失敗します。
ロールベースのデータベース・サービスが新しいプライマリで稼働していることを確認します。
- サイト:サイト2
- ノード:すべてのOracle Exadata Database Service on Dedicated Infrastructure domUs
- ユーザー: oracle
たとえば、PeopleSoft Oracle RACデータベース・インスタンスをホストする各domUで次のコマンドを発行します。
```
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
```
このサービスは、すべてのOracle RACインスタンスで実行されている必要があります。

アプリケーション・サーバーを起動し、スケジューラ・ドメインを処理します。

サイト:サイト2
ノード:アプリケーションおよびプロセス・スケジューラ・サーバーのコンピュート・インスタンス
ユーザー: psadm2

PeopleSoftアプリケーション・サーバーおよびプロセス・スケジューラをホストするコンピュート・インスタンスにログインし、psadm2になります。
GitHubのWrapperディレクトリからstartPSFTAPP.shスクリプトを使用します。
```
$ startPSFTAPP.sh
```

起動を監視します。

この問合せは、PeopleSoftアプリケーションおよびProcess Schedulerドメインから使用できます。

col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50

ステップ5の説明に従って完全なサイト障害がなかった場合は、次のステップに進みます。完全なサイト障害が発生した場合は、startPSTAPP.shスクリプトによってrsyncが有効になるため、disable_psft_rsync.shスクリプトを再度実行する必要があります。
ノート:

プライマリ・サイトが失われたり、アクセスできなくなった実際の障害イベントでは、スコープと影響を評価する必要があります。考慮する必要がある項目をいくつか次に示します。
- データベース・データ損失の可能性があります
- ファイル・システム・アーティファクト(レポート、ログ、インバウンド・ファイルおよびアウトバウンド・ファイルなど)がありません
停止によっては、元のプライマリでコミットされたすべてのトランザクションをリカバリできる場合とできない場合があります。可能な場合は、最後に作業していたトランザクションを確認するようユーザーに依頼します。

元のプライマリへのアクセスが停止すると、出力の書込みまたは転送から、ファイル・システム・アーティファクトが欠落している可能性があります。データベース内のレポート・ロギングを使用して、停止時間の近くに作成されたファイル・システム・アーティファクトを特定し、ファイルの欠落または不完全について、必要な処理をケースごとに判断します。
Webサービスを開始します。
- サイト:サイト2
- ノード:すべてのPeopleSoft Internet Architecture (PIA) Webサーバー・コンピュート・インスタンス
- ユーザー: psadm2
Coherence*Webが構成されている場合は、最初にPIA Webサーバーをホストするすべてのコンピュート・インスタンスでキャッシュ・クラスタを起動してから、PIA Webサーバーを起動します。この例では、1つのスクリプトを使用して、両方を適切な順序で開始します。
1. PIA Webサーバーにログインし、psadm2になります。
2. startPSFTAPP.shのスクリプトを使用して、Webサーバーを起動します。
```
$ startPSFTWEB.sh
```
ロード・バランサを確認します。
- サイト:サイト2リージョン
- ノード: OCIコンソール
- ユーザー: テナンシ管理者
1. OCIコンソールにログインし、リージョンを新しいプライマリに変更します。
2. メイン・メニューから「ネットワーキング」、「Load Balancer」の順に選択します。
3. 適切なコンパートメントを選択します。
4. 「バックエンド・セット」をクリックし、「バックエンド」をクリックします。
  各バックエンドに「OK」が表示されます。各PIA Webサーバーが起動されてから数分かかる場合があります。

失敗したプライマリを新しいスタンバイとして回復します

新しい本番環境はスタンバイで保護する必要があります。理想的には、データベースとファイル・システムの両方を回復することで、障害が発生したプライマリを新しいスタンバイとして回復できます。

スタンバイとしての古いプライマリ・データベースの回復

Oracle Data Guardは、プライマリ・サイトの障害後に再び使用可能になったときに、古いプライマリ・データベースを開かないようにします。通常、データベースを起動しようとすると失敗し、回復が必要であることを示すメッセージがアラート・ログに書き込まれます。障害発生前にこのデータベースでフラッシュバック・データベースが有効になっている場合は、古いプライマリを新しいスタンバイとして回復できます。

次の手順を実行して、古いプライマリを現在の本番のスタンバイとして回復します。

古いプライマリ・データベースをホストしているdomUsのいずれかにログインし、データベースを起動します。
```
$ srvctl start database -db CDBHCM_phx5s
```

新しいプライマリ・リージョンでData Guard Brokerコマンドライン・インタフェースにログインし、構成を表示します。

次の太字でORA-16661エラーに注意してください。

$ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)

スタンバイを回復します。
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
ノート:
障害が発生したデータベースをリカバリし、有効なスタンバイを作成するプロセスは起動し、完了までに時間がかかる場合があります。
Data Guard Brokerコマンドライン・インタフェースを使用して、環境のステータスを確認します。
例
```
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)
```
修復されたデータベースはスタンバイとして機能し、プライマリを保護し、スイッチオーバーおよびフェイルオーバーに使用できます。

プライマリ・データベース・サーバーとスタンバイ・データベース・サーバーを構成するときにActive Data Guardサポートを構成した場合は、PeopleSoft (PSQUERY)のActive Data Guardサービスをプライマリからスタンバイ・データベースに再配置できます。

スタンバイとしての古いプライマリ中間層の回復

フェイルオーバー・イベントに基づいて、古いプライマリ中間層を回復します。

データベース・フェイルオーバー・イベントが発生した間、古いプライマリ中間層サーバーが使用可能なままだった場合は、障害発生時に障害の発生したプライマリ・サイトからスタンバイへの最終強制rsyncを実行してから、スイッチオーバーの実行時と同じ方法でrsyncプロセスの方向を逆にします。

アプリケーション層とWeb層はまだ機能している可能性がありますが、アプリケーションおよびプロセス・スケジューラ・プロセスは、障害が発生したデータベースへの接続の試行に失敗し始めます。これにより、rsyncスクリプトがrsyncの実行を停止します。
1. 共有ファイルシステムを含むプライマリ中間層がまだ変更されていない場合は、障害が発生したプライマリサイトからDRサイトに対して強制的なrsyncを手動で実行します。
  rsyncスクリプトが無効になっている場合、-fパラメータは強制rsyncの続行を要求します。強制的なrsyncでは、データベースを参照してサイトのロールを特定せず、要求されたrsyncを実行します。
  
  ノート:
  これは、サイト・フェイルオーバー中に最終リフレッシュを強制する場合にのみ実行する必要があります。FORCEオプションを使用すると、ログに記録されます。
  
  スクリプト・ディレクトリrsync_psft.shのサンプル・スクリプトをユーザーpsadm2として使用できます。
```
$ rsync_psft.sh path to file system/parameter file -f
```
  例
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. rsyncプロセス・ログをモニターして、プロセスが正常に完了したことを確認します。
rsyncでも古いプライマリ・サイトにアクセスできない場合は、次を実行します。
1. レプリケートされるすべてのファイル・システムのdisable_psft_rsync.shを使用して、新しいプライマリ・サイトでrsyncスクリプトを無効にします。
2. 後で元の中間層でアクティビティを再開できる場合は、rsyncスクリプトを再度有効にしてキャッチアップさせます。
中間層を再構築する必要がある場合は、前述のプロセスに従います。