>> はじめに |
今月は、SharePlexが誇るレプリケーションの高速化アーキテクチャについて第2弾です。
>> トランザクションが多い場合の対策 |
一日当たりどのくらいのオンラインREDOログが生成されている環境なら、SharePlexを使用することができるか?というご質問をいただくことがありますが、下記のような様々な要因によって状況が異なるため、一概に何とも言えません。
- システムの性能
- ストレージ構成
- トランザクションに占めるCaptureすべき内容の割合
- 対象テーブルの割合
- レプリケーションの用途
- その他
事前のアセスメントで、ある程度の検討をつけ、あとは本番環境に近い状態でのテスト等を通して、パフォーマンスについての見極めをしていきます。
論理レプリケーションのアーキテクチャーを考えると、ソース側のCapture処理の部分の負荷もありますが、この部分は基本的に運用環境のOracleへのアクセスはあまり行われず、ログファイルに対するI/Oに対する考慮が必要です。しかし、ターゲット側は、PostプロセスがPostキューの内容をSQL文に変換して、OracleインスタンスにOCI (Oracle Call Interface) を使用して反映を行います。そのため、このPostの部分がボトルネックになることもあります。
>> Postのマルチプロセス化 |
Post側のボトルネックを解消するには、Postのプロセスをマルチプロセス化することがとても有効です。この内容は、SharePlexの仕組みをご紹介する際に、こちらの講座で少しご説明させていただきました。
今回は、このマルチプロセス化について、設定方法を見ていきましょう。
>> named post queueとは? |
Postプロセスが特定のトランザクションを処理している際に、その処理に時間がかかってpost queueにある他のトランザクションに対して、パフォーマンス上の影響を与えてしまうことがあります。
- LOB列を持つ設定内のオブジェクト
- 大規模なトランザクションを行うオブジェクト
- 隔離する操作を含むオブジェクト
このような場合に、対象のオブジェクト毎にキューファイルの格納先を分けて、その各キューファイル毎に個別にPostプロセスを稼働させることが可能です。何も名前を設定しないデフォルトのpost queueに対して、個別に名前を付けて分けたものをnamed post queueと呼びます。今回は、標準で用意されているテーブルを使用して、以下のような組み合わせを考えてみました。
- 標準のpost queueを使用して複製する(既に過去の講座で設定済)
- 転送元: SYSTEM1上のsplex.demo_src
- 転送先: SYSTEM2上のsplex.demo_dest
- testという名前のpost queueを使用して複製する(新しい設定)
- 転送元: SYSTEM1上のsplex.demo_dest
- 転送先: SYSTEM2上のsplex.demo_src
一見難しいように思われるpostプロセスを分けるという設定も、SharePlexでは定義ファイル1つで行うことができます。
>> named post queueの設定をしよう |
まず、最初のシステム側で (つまりactivate configをしたsp_ctrlから)、現在の状態を確認しておきます。
statusコマンドを実行して現在起動しているプロセスがcopとcmd & Ctrlだけであることを確認しておきます (初期のインストール状態と一緒です)。
|
もし、設定ファイルがactivateされてソース側でプロセスが他にも起動している場合には、deactivate configを実行すると、上記の状態になります。
|
次に、デフォルトでテンプレートとして用意されているORA_configファイルを使用する場合には、それをeditします。
|
以前からの講座に従って進めている場合には、以下のような設定がなされているはずです (ホスト名やSID等は異なると思いますが)。
|
この状態で、既にデフォルトのpost queueを使用して、「SYSTEM1上のsplex.demo_srcをSYSTEM2上のsplex.demo_destへ標準のpost queueを使用して複製する。」という目的のための設定はなされています。そのため、2番目のnamed post queueのための設定だけ追記します。
この部分の書式は以下のようになっています。ターゲットのホスト名の後にコロンを付けてqueue名を記述するだけです。このqueue名を記述しない場合には、デフォルトのpost queueという形になるのです。
<ターゲットホスト名>:<queue名>@o.<ターゲットSID>
そこで、要件に従って設定すると、次のようになります。
|
この設定を実際にソース側でactivateをして、statusを確認してみても、状態に変化はありません。これは、ソース側には特に影響しないためです。
|
ターゲット側でstatusを確認してみると、post queueを分けたことで、postプロセスが2つ起動するため、その状態を確認することが可能です。
|
また、queueの状態を確認するqstatusコマンドを実行すると、通常は1つのqueueがName: testというように、名前を付けたqueue nameを確認することができました。
|
ためしに、それぞれのテーブルに対してトランザクションを発生させてみます。
|
すると、ターゲット側のqstatusが両方とも更新されていることがわかります。ちなみに、全部で3件だったのが、ターゲット側で合計4件になっているのはおかしいな?と思われた方もいるかもしれません。これは、postプロセスを分けることで、処理が分散されますので、commitも分散して実行する必要があるからです。このような内部の細かい処理はすべてSharePlexが管理しています。
|
>> まとめ |
Postの部分は比較的、ターゲット側のOracleの状態にもよりますが、遅延が起きやすい部分ですが、デフォルトの動作であるマルチスレッドと合わせて、このようなマルチPostの仕組みを使用すると、更なる高速化を行うことが可能です。
次回も高速化するアーキテクチャーの続編をご紹介します。