構成の確認

DR設定が完了したら、完全なスイッチオーバーを実行するか、またはセカンダリサイトを開いて検証を行うことによって、設定が正しいことをすぐに検証します。検証のためにセカンダリ・サイトをオープンしても、プライマリで実行されているシステムには影響しません。

セカンダリを検証用に開く

スタンバイ・データベースをスナップショット・スタンバイに変換することで、完全なスイッチオーバーを実行せずにスタンバイ・サイトを検証できます。これにより、セカンダリ WebLogic Serverサーバーをスタンバイサイトで起動し、セカンダリシステムを検証できます。スナップショット・スタンバイ・モード中にスタンバイ・サイト・データベースで実行された変更は、再度物理スタンバイに変換されると破棄されます。プライマリ・データはセカンダリ・サイト検証の影響を受けません。

ノート:

この操作は注意して実行する必要があります: スナップショットへの変換時にデータベースに保留中のJMSメッセージがある場合、スタンバイ・サイトのサーバーは起動時にそれらを処理します。スナップショット・スタンバイへの変換時に、プライマリ・データベースに保留中のアクションがないことを確認します。

oracleユーザーとして、プライマリdbホストでOracle Data Guardブローカを使用し、セカンダリをスナップショット・スタンバイに変換します。
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
コマンドshow configurationを使用して、変換が正しく実行されたことを確認します。
まだ起動していない場合は、セカンダリ・サイトでOracle HTTP Serverシステムを起動します。
セカンダリ・サイトで管理サーバーを起動します。
セカンダリ・サイトでセカンダリ管理対象サーバーを起動します。
WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。
セカンダリ・サイトを検証します。

これはスイッチオーバーではなく、プライマリ・サイトがまだアクティブであるため、仮想フロントエンド名はプライマリ・サイトのロード・バランサIPアドレスに解決されるため、ブラウザ・アクセスはデフォルトでアクティブなプライマリ・サイトにリダイレクトされます。

セカンダリ・サイトのWebLogicサーバー・アプリケーションに直接アクセスするには、制御されたクライアント(ラップトップなど)の/etc/hostsファイルを更新し、仮想フロントエンド名をセカンダリ・サイトのフロントエンド・ロード・バランサのIPアドレスに解決するように設定し、このクライアントから検証を実行する必要があります。

ノート:
検証に使用されるクライアントがHTTPプロキシを介してシステムにアクセスしないことを確認します。これは、HTTPプロキシがクライアントの/etc/hostsにある名前に関係なく、プライマリ・サイトのロード・バランサIPアドレスを使用して仮想フロントエンド名を解決し続ける可能性があるためです。

ブラウザがカスタマイズされたホストファイルエントリを使用してIPアドレスを解決する前に、Linux以外のクライアントでローカル DNSキャッシュのリセットが必要になることがあります。

セカンダリ・サイトが検証されたら、次のステップに進み、スタンバイ・ロールに戻します。

ノート:
セカンダリ・サイトの検証には時間がかかる場合があります。
セカンダリ・サイトの管理対象サーバーおよび管理サーバーを停止します。
セカンダリWebLogicコンソールを使用して、セカンダリ・サイトの管理対象サーバーおよび管理サーバーを停止します。
oracleユーザーとして、プライマリ・データベース・ホストでOracle Data Guard Brokerを使用し、セカンダリをフィジカル・スタンバイに再度変換します。
システム・パスワードとプライマリ・データベースの一意の名前が必要になります。
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
show configurationを使用して変換を確認します。
更新された/etc/hostsファイルを元に戻します。
検証のためにセカンダリ・サイトを指すようにクライアント内の/etc/hostsファイルを更新した場合、仮想フロントエンド名がプライマリ・フロントエンドIPアドレスを再度指すように元に戻します。

スイッチオーバーの実行

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

WebLogic ServerハイブリッドDR構成でスイッチオーバーを実行する前に、保留中の構成変更を伝播します。保留中のセカンダリ・サイトへのレプリケートされた変更がないことを確認します。

スイッチオーバーの実行中、スケジュールされたレプリケーションは失敗し、スイッチオーバー操作自体を妨げる可能性があるため、無効にします。
プライマリ・サイトでOracle HTTP Serverシステムを停止します。
プライマリ・サイトのサーバーを停止します。
WebLogic管理サーバー・コンソールまたはスクリプトを使用して、プライマリ・サイトのWebLogicサーバーを停止します。

ノート:
プライマリ・サイトの管理サーバーは、スイッチオーバー中に稼働状態を維持できます。ただし、ライフサイクル中にスタンバイ・サイトのドメイン構成がプライマリ構成によってオーバーライドされることが予想されるため、サイトがスタンバイ・ロールの場合に停止することをお薦めします。これが発生している間に管理サーバーが稼働している場合、古い構成で実行されます。
フロントエンドDNS名をスイッチオーバーします。

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

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

DNSエントリのTTL値はスイッチオーバーのRTOに影響することに注意してください。TTLが大きい(20分など)場合、DNS変更はクライアントで有効になるまでにその時間かかります。TTL値を小さくすると高速になりますが、キャッシュされた名前を使用するのではなく、クライアントがDNSにヒットする頻度が高くなるため、オーバーヘッドが発生する可能性があります。DNSを変更する前に、TTLを一時的に(1分など)低い値に設定することをお薦めします。次に、変更を実行し、スイッチオーバー・プロシージャが完了したら、TTLを元の値に戻します。
oracleユーザーとして、プライマリ・データベース・ホストのOracle Data Guardブローカを使用して、データベース・スイッチオーバーを実行します。
システム・パスワードとプライマリ・データベースの一意の名前が必要になります。
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
まだ起動していない場合は、セカンダリ・サイト(新しいプライマリ)でOracle HTTP Serverシステムを起動します。
セカンダリ・サイト(新しいプライマリ・サイト)で管理サーバーを起動するか、すでに起動している場合はサーバーを再起動します。
管理サーバーを起動すると、スタンバイ中にレプリケートされた構成変更が有効になります。
セカンダリ・サイトでセカンダリ管理対象サーバーを起動します(新しいプライマリ)。
WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。