>> はじめに |
先月の手順で、ソース側のSharePlexインスタンスの二重化が完了ました。今月はターゲット側の二重化後に、実際に2つのインスタンスに対してレプリケーションの設定を行い、動作の確認を行ってみます。
>> ターゲット側の二重化 |
基本的には、ソース側と同じ作業を行います。そのため、以前のソース側の構築方法を参考に作業を進めてください。
■ソースとターゲットで違う事
ソース側では、現在すでにactivateした設定ファイルがあった場合は、一旦設定を解除していましたが、ターゲット側では作成していませんので、解除の必要もありません。以前の作業でターゲット側もシャットダウンされているため、ポート番号やディレクトリ名等を確認したあとで、変数データディレクトリの作成以降の作業をソース側と同じように行っていきます。以下にて、詳細を割愛した状態で、実際の手順だけをご紹介します。
■変数データ ディレクトリの作成
最初に既にインストールされたインスタンスの必要ファイルを、tarコマンドで退避しておきます。
|
次に、2つ目のインスタンス用に作成したディレクトリで、退避されたデータを展開します。
|
■paramdbの変更
paramdbファイルの編集により、port番号を2200に変更します。
|
■古いキュー ファイル等の削除
スクリプト対応により、古いキュー等を削除します。
|
手動で削除が必要なファイルもあります。
|
■ora_setupの実行
複製したインスタンスで使用するSharePlex用Oracleユーザを作成します。
|
paramdbで、それぞれのインスタンス毎で使用するOracleアカウントが違うことを念のため確認しておきます。
|
■環境変数の編集
ポートや変数データ ディレクトリの特定を環境変数で行わないよう設定を変更します。
|
>> 設定後のsp_copの起動確認 |
事前の設定がすべて完了したら、実際に2つのsp_copを起動してみます。
■ポート番号2100のsp_copの起動
|
■ポート番号2200のsp_copの起動
|
■sp_cop起動状態の確認
|
>> 2つのSharePlexインスタンスが準備完了後にテスト |
今までのすべての作業で、ソースとターゲットの双方で、2つのSharePlexインスタンスが動作できる状態になりました。ここからは、実際の動作の確認を行っていきます。
テスト方法は、named post queueのテストを行った時のルールで実行してみたいと思います。
- port 2100のSharePlexインスタンスを使用
転送元: SYSTEM1上のsplex.demo_src
転送先: SYSTEM2上のsplex.demo_dest - port 2200のSharePlexインスタンスを使用
転送元: SYSTEM1上のsplex2200.demo_dest
転送先: SYSTEM2上のsplex2200.demo_src
■port2100のSharePlexインスタンスで設定ファイルを編集してactivate
2つ分のSharePlexインスタンスの設定ファイルの作成は、すべてソース側で行います。
|
なお、接続先が2200の場合にはportコマンドで切り替えておきます。
|
編集によって設定ファイルを確認してみます。
|
そうすると、以前の定義の編集により希望通りになっているので、そのままにして、activateしてみます。
|
|
■port2200のSharePlexインスタンスで設定ファイルを編集してactivate
portコマンドで切り替えて、今度は設定ファイルのテーブルの定義を逆にします。
|
|
|
以上の設定で、2つのSharePlexインスタンスが完全に稼働した状態になります。
細かいテストについては、割愛させていただきますので、みなさん各自ソース側のテーブルを更新して、それが正しくターゲット側にレプリケーションされるか確認してみてください。
>> まとめ |
5回に渡って、SharePlexが持つ高速化のソリューションを、ほんの一部にはなりますが、ご紹介してきました。豊富なパラメータによって、速度的な向上を行うことも可能ですが、大規模な環境でパフォーマンスを重視する場合には、アーキテクチャ的な変更の方が即効性があり、期待した効果が得られることが多いようです。
次回からは、データベースにとっても重要なトピックである、整合性についてをテーマにさせていただく予定です。