この章では、高可用性環境でのフェイルオーバーの際に、Oracleレプリケーションをデータベースおよびアプリケーションと共にリカバリする方法を説明します。これらの手順をサポートするには、高可用性をサポートするようにSharePlexを適切に設定する必要があります。「高可用性を維持するためのレプリケーションの設定」を参照してください。
プライマリシステムに障害が発生した場合のレプリケーションのリカバリ
セカンダリOracleインスタンスに障害が発生した場合のレプリケーションのリカバリ
プライマリ(ソース)マシンに計画外の障害が発生した場合、そのシステム上のSharePlexキューに残っている複製データは、バッファリングの結果として、またキューが破損している可能性があるためリカバリ不可能となります。高可用性環境では、データの可用性を維持するために、データベースユーザと共にセカンダリ(ターゲット)マシンにレプリケーションを移動させることができます。プライマリシステムがリストアされると、セカンダリインスタンスのホットバックアップを使用して、最小限のダウンタイムでユーザとレプリケーションをそのシステムに戻すことができます。
この手順では、設定ファイルをアクティベーションし、reconcileコマンドを使用してコピーされたインスタンスをリカバリした後に、バックアップの結果と進行中の複製されたユーザの変更を同期させます。
UnixまたはLinux上のOracleデータベース
プライマリシステムに予期せぬ障害が発生した場合に、レプリケーションをセカンダリシステムに移行するには:
セカンダリシステムで、Exportが停止していることを確認します。
sp_ctrl> stop export
postキューを表示するには、qstatusコマンドを使用し、バックログされたメッセージの数が0になるまで、このコマンドを発行し続けます。注意: 実際のメッセージの数が0になるまで待たないでください。一部のトランザクションのコミットを受信する前にプライマリシステムに障害が発生した場合、これらの部分的なトランザクションのメッセージは、この手順の後半でクリアされるまでキューに残ります。
sp_ctrl> qstatus
注意: Exportを開始すると、プライマリシステムへの接続が繰り返し試行され、システムリソースを浪費します。
この手順では、プライマリマシンが計画外の障害からリカバリした後、ユーザをプライマリマシンに戻します。提示された順序で各セグメントに従います。
プライマリシステムのレプリケーション環境をリストアするには:
プライマリシステムで、-sオプションを使用してsp_copを起動し、SharePlexのプロセス(Capture、Read、Export、Import、Post)が起動しないようにします。
$ /productdir/bin/sp_cop -s &
プライマリシステムで設定ファイルを非アクティベーションします。アーカイブされたSharePlex変数データディレクトリをプライマリシステムにコピーしたときに、システムの障害発生前にアクティブだった設定をコピーしました。これにより、Captureプロセスは、プライマリシステムからのレプリケーション再開時にトランザクション番号を「1」に設定します。
sp_ctrl> deactivate config filename
キューをパージするには:
プライマリシステムでcaptureキューを削除します。
sp_ctrl> delete capture queue for datasrc [on host]
例: sp_ctrl> delete capture queue for o.oraA
プライマリシステムでexportキューを削除します。
sp_ctrl> delete export queue quename [on host]
例: sp_ctrl> delete export queue sysA
セカンダリシステムでpostキューを削除します。
sp_ctrl> delete post queue quename for datasrc-datadst [cleartrans] [on host]
例: sp_ctrl> delete post queue sysA for o.oraA-o.oraB
メモ:
|
セカンダリシステムからプライマリシステムへのレプリケーションを開始するには:
プライマリシステムで、SharePlexのすべてのプロセスがすべて停止していることを確認します。
sp_ctrl> status
プライマリシステムでPostを停止します。
sp_ctrl> stop post
セカンダリシステムでExportを開始します。これにより、プライマリシステムとセカンダリシステム間の通信が確立されます。
sp_ctrl> start export
ソースデータとターゲットデータを同期させるには:
ホットバックアップが終了したら、セカンダリシステムでログファイルを切り替え、アーカイブログの最大のシーケンス番号を書き留めておきます。
RESETLOGSオプションを使用してデータベースを開きます。
注意: この結果、起動時にプライマリシステムのシーケンスがキャッシュの先頭にリセットされます。
プライマリシステムで、前に書き留めたログのシーケンス番号を使用してreconcileコマンドを実行します。名前付きpostキューを使用している場合は、それぞれについてコマンドを実行します。キュー名がわからない場合は、最初にqstatusコマンドを実行します。
sp_ctrl> qstatus
sp_ctrl> reconcile queue queuename for datasource-datadest seq sequence_number
例: reconcile queue SysB for o.oraA-o.oraA seq 1234
プライマリシステムでレプリケーションをアクティベーションするには:
プライマリシステムで設定ファイルをアクティベーションします。
sp_ctrl> activate config filename
プライマリシステムでPostを開始します。
sp_ctrl> start post
オブジェクトキャッシュを復元するには:
プライマリシステムでSharePlexのプロセスのステータスを表示します。
sp_ctrl> status
注意: このコマンドは、オブジェクトキャッシュがないために発生したエラーによりPostが停止したことを示します。
プライマリシステムで、filterオプションを使用してshow logコマンドを発行し、キーワード「objcache」でフィルタリングします。
sp_ctrl> show log filter=objcache
以下の例に類似した名前を持つファイルを参照するPostエラーメッセージを探します。
0x0a0100c5+PP+sys4+sp_opst_mt+o.quest-o.ov-objcache_sp_opst_mt.18
「objcache_sp_opst_mt」という文字列の後に数字が続く文字列を探しています。これは、Postプロセスが必要とするオブジェクトキャッシュファイルです。名前付きpostキューを使用している場合、それぞれが異なるオブジェクトキャッシュファイルを参照しているが同じ番号で終わる(例では「.18」)複数のエラーメッセージが表示されます。
エラーメッセージに記載されているPostオブジェクトキャッシュファイルのフルパス名を書き留めます。パスは、以下のようにSharePlexの変数データディレクトリ内のstateディレクトリになります。
splex_vardir/state/0x0a0100c5+PP+sys4+sp_opst_mt+o.quest-o.ov-objcache_sp_opst_mt.18
セカンダリシステムでSharePlexをシャットダウンします。
sp_ctrl> shutdown
セカンダリシステムで、SharePlexの変数データディレクトリのstateサブディレクトリにディレクトリを変更し、Captureオブジェクトキャッシュファイルを探します。このファイルは以下の例のような名前になります。
o.quest-objcache_sp_ocap.18
重要!: これらのファイルが複数ある場合は、その末尾に最新の番号が付いたものを使用してください。この番号は、例の.18のように、Postオブジェクトキャッシュファイルの末尾の番号と一致している必要があります。
プライマリシステムでPostを開始します。
sp_ctrl> start post
ユーザをプライマリシステムに戻すには:
プライマリシステムで、postキューを表示し、メッセージ数が0になるまでコマンドを発行し続けます。
sp_ctrl> qstatus
セカンダリシステムでOracleインスタンスをシャットダウンします。
svrmgr1> shutdown
セカンダリシステムでOracleインスタンスを起動します。
svrmgr1> startup
注意: この結果、セカンダリシステムのシーケンスがキャッシュの先頭にリセットされ、プライマリシステムと同期されます。
セカンダリシステムでPostを停止します。
sp_ctrl> stop post
セカンダリシステムでPostを開始します。
sp_ctrl> start post
プライマリシステムで、postキューのメッセージ数を表示し、メッセージ数が0になるまでチェックし続けます。
sp_ctrl> qstatus
セカンダリシステムで行われた偶発的な変更がプライマリシステムに複製されるのを防ぐため、セカンダリシステムでExportを停止します。
sp_ctrl> stop export
注意: セカンダリシステムは、以下のようなフェイルオーバー可能な状態に戻りました。
|
セカンダリ(ターゲット)Oracleインスタンスで予期しない障害が発生した場合、そのシステムからプライマリシステムへのレプリケーション環境が破損します。この手順により、プライマリシステムのデータベースユーザに影響を与えることなく、またプライマリシステムの設定ファイルを再度アクティベーションすることなく、レプリケーション設定を復元することができます。影響を受けるのはセカンダリ設定のみです。
この手順では、SharePlexのキューを一掃し、ソースシステムからのホットバックアップによってターゲットインスタンスを復元します。reconcileコマンドを使用して、コピーされたインスタンスをリカバリした後に、バックアップの結果と進行中の複製されたユーザの変更を同期します。
UnixまたはLinux上のOracleデータベース
この手順は論理的なセグメントに分かれています。提示された順番に従ってください。
キューをパージするには:
セカンダリシステムでPostを停止します。
sp_ctrl> stop post
セカンダリシステムで設定ファイルを非アクティベーションします。
sp_ctrl> deactivate config filename
注意: 非アクティベーションにより、イベントログにエラー「Error in sp_cnc.(sp_cncのエラー)」が表示されます。無視して手続きを続けることもできます。
プライマリシステムでpostキューを削除します。
sp_ctrl> delete post queue quename for datasrc-datadst [cleartrans] [on host]
例: sp_ctrl> delete queue sysB:P for o.oraA-o.oraB
注意: プライマリシステムのキューを削除しているのは、セカンダリインスタンスで障害が発生する前にセカンダリインスタンスから送信されたコミットされていないトランザクションのメッセージが残っている可能性があるためです。
セカンダリシステムでcaptureキューを削除します。
sp_ctrl> delete capture queue for datasrc [on host]
例: sp_ctrl> delete queue o.oraB:C
セカンダリシステムでexportキューを削除します。
sp_ctrl> delete export queue quename [on host]
例: sp_ctrl> delete queue sysB:X
注意: セカンダリシステム上のキューを削除するのは、そのシステム上のcaptureキューとexportキューが、既に処理されたトランザクションの記録をまだ保持しているためです。
データを同期させるには:
プライマリシステムでログファイルを切り替えます。
オンプレミスのデータベース:
svrmgr1> alter system switch logfile;
Amazon RDSデータベース:
Amazon RDSプロシージャrdsadmin.rdsadmin_util.switch_logfileを使用します。
SQL*Plusで、SharePlexの製品ディレクトリのbinサブディレクトリからcleanup.sqlスクリプトを実行します。
セカンダリシステムで、前に書き留めたログのシーケンス番号を使用してreconcileコマンドを実行します。名前付きpostキューを使用している場合は、それぞれについてコマンドを実行します。キュー名がわからない場合は、最初にqstatusコマンドを実行します。
sp_ctrl> qstatus
sp_ctrl> reconcile queue queuename for datasource-datadest seq sequence_number
例: reconcile queue SysA for o.oraA-o.oraA seq 1234
セカンダリシステムで、sp_ctrlプロンプトが戻った後にExport を停止します。これにより、セカンダリシステムで設定をアクティベーションする際に、誤ってプライマリシステムに複製されなくなります。
sp_ctrl> stop export
セカンダリシステムでレプリケーションを開始するには:
セカンダリシステムで設定ファイルをアクティベーションします。
sp_ctrl> activate config filename
セカンダリシステムでPostを開始します。
sp_ctrl> start post
statusコマンドを使用して、SharePlexの他のプロセスのステータスがStopped due to Error(エラーにより停止)であるかどうかを確認し、これらを開始します。
sp_ctrl> status
sp_ctrl> start process
注意: これで、セカンダリシステムは将来のフェイルオーバーに備えることができます。
セカンダリOracleインスタンスへのデータベースアクティビティの計画的なフェイルオーバーでは、SharePlexをセカンダリシステムに迅速に移動できます。ユーザがそのシステムでトランザクションを続けている間、プライマリシステムがオンラインに戻り、アクティビティがそのシステムに戻されるまで、SharePlexはユーザの変更をキャプチャして保存します。
UnixまたはLinux上のOracleデータベース
この手順は論理的なセグメントに分かれています。提示された順番に従ってください。手順でプロンプトが表示されるまで、プライマリインスタンスをシャットダウンしないでください。
セカンダリシステムにユーザを切り替えるには:
プライマリシステムで、キュー内のデータをセカンダリシステムにフラッシュします。このコマンドは、セカンダリシステムのPostを停止し、プライマリデータとセカンダリデータの同期ポイントを確立するためにデータストリームにマーカーを置きます。
sp_ctrl> flush datasource
ここで、datasourceは、プライマリOracleインスタンスのデータソースの指定です(o.OraAなど)。
セカンダリシステムで、Postが停止したことを確認します(Postが停止したと表示されるまで、このコマンドを発行し続ける)。
sp_ctrl> status
プライマリシステムで、captureキューとexportキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。
sp_ctrl> qstatus
セカンダリシステムで、postキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。
sp_ctrl> qstatus
プライマリシステムで、abortオプションを使用してOracleインスタンスをシャットダウンします。immediateオプションは使用しないでください。
svrmgr1> shutdown abort
注意: これにより、データベース起動時にプライマリシステムのシーケンスがキャッシュの先頭にリセットされます。
セカンダリシステムで、Exportが停止していることを確認します。これにより、プライマリシステムがオンラインに復帰し、SharePlexで変更を受け取る準備が整うまで、ユーザの変更がプライマリシステムに複製されなくなります。必要に応じてExportを停止します。
sp_ctrl> status
sp_ctrl> stop export
ユーザをプライマリシステムに戻すには:
セカンダリシステムでExportを開始し、蓄積された複製済みのデータをSharePlexがプライマリシステムに送信するようにします。
sp_ctrl> start export
注意: Exportの開始時に、SharePlexはセカンダリシステムからプライマリシステムにすべてのシーケンスの更新を戻します。
プライマリシステムでExportを停止します。
sp_ctrl> stop export
プライマリシステムで、プライマリシステムから送信されたメッセージのバックログをPostで処理できるようにします。
セカンダリシステムで、キューのデータをプライマリシステムにフラッシュします。
sp_ctrl> flush datasource
ここで、datasourceは、セカンダリOracleインスタンスのデータソース指定です(o.OraBなど)。
プライマリシステムで、Postが停止したことを確認します(Postが停止したと表示されるまで、このコマンドを発行し続ける)。
sp_ctrl> status
セカンダリシステムで、captureキューとexportキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。
sp_ctrl> qstatus
プライマリシステムで、postキューにメッセージがないことを確認します。Number of MessagesフィールドとBacklog (messages)フィールドは0でなければなりません。
sp_ctrl> qstatus
セカンダリシステムでSharePlexをシャットダウンします。
sp_ctrl> shutdown
セカンダリシステムで、abortオプションを使用してOracleインスタンスをシャットダウンします。immediateオプションは使用しないでください。
svrmgr1> shutdown abort
注意: これにより、データベース起動時にセカンダリシステムのシーケンスがキャッシュの先頭にリセットされます。
セカンダリシステムでOracleインスタンスを起動します。
svrmgr1> startup
注意: これで、セカンダリシステムのシーケンスがキャッシュの先頭になりました。プライマリシステムで次の値が選択されると、新しいキャッシュが取得され、セカンダリシステムに複製されます。これで、プライマリシステムがキャッシュの先頭に、セカンダリシステムがキャッシュの最上部になりました。
セカンダリインスタンスを維持するためにレプリケーションを再開するには:
セカンダリシステムでExportを停止します。これにより、そのシステムで誤ってDMLを実行した場合、プライマリシステムに複製されるのを防ぐことができます。
sp_ctrl> stop export
プライマリシステムでExportを開始します。
sp_ctrl> start export
セカンダリシステムでPostを開始します。
sp_ctrl> start post
プライマリインスタンスからセカンダリインスタンスへのレプリケーションがアクティブになり、2つのデータベースの同期が維持されて、必要に応じた将来のフェイルオーバーに対応できるようになりました。
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center