第12回 SharePlexを高速化するアーキテクチャー詳細 (その2)

>> はじめに

今月は、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だけであることを確認しておきます (初期のインストール状態と一緒です)。


sp_ctrl (rhel5sposrc1:2100)> status

Brief Status for rhel5sposrc1
Process          State                             PID     Running   Since
---------------  ------------------------------  --------  --------------------
Cop              Running                             4482  27-Sep-12 13:10:22
Cmd & Ctrl       Running                             4545  27-Sep-12 13:11:11
There are no active configuration files

もし、設定ファイルがactivateされてソース側でプロセスが他にも起動している場合には、deactivate configを実行すると、上記の状態になります。


sp_ctrl (rhel5sposrc1:2100)> deactivate config ORA_config

次に、デフォルトでテンプレートとして用意されているORA_configファイルを使用する場合には、それをeditします。


sp_ctrl (rhel5sposrc1:2100)> edit config ORA_config

以前からの講座に従って進めている場合には、以下のような設定がなされているはずです (ホスト名やSID等は異なると思いますが)。


datasource:o.src1

#source tables      target tables           routing map

splex.demo_src      splex.demo_dest             rhel5spotrg1@o.trg1

この状態で、既にデフォルトのpost queueを使用して、「SYSTEM1上のsplex.demo_srcをSYSTEM2上のsplex.demo_destへ標準のpost queueを使用して複製する。」という目的のための設定はなされています。そのため、2番目のnamed post queueのための設定だけ追記します。

この部分の書式は以下のようになっています。ターゲットのホスト名の後にコロンを付けてqueue名を記述するだけです。このqueue名を記述しない場合には、デフォルトのpost queueという形になるのです。

<ターゲットホスト名>:<queue名>@o.<ターゲットSID>

そこで、要件に従って設定すると、次のようになります。


datasource:o.src1

#source tables      target tables           routing map

splex.demo_src      splex.demo_dest             rhel5spotrg1@o.trg1
splex.demo_dest      splex.demo_src             rhel5spotrg1:test@o.trg1

この設定を実際にソース側でactivateをして、statusを確認してみても、状態に変化はありません。これは、ソース側には特に影響しないためです。


sp_ctrl (rhel5sposrc1:2100)> activate config ORA_config
sp_ctrl (rhel5sposrc1:2100)> status

Brief Status for rhel5sposrc1
Process          State                             PID     Running   Since
---------------  ------------------------------  --------  --------------------
Cop              Running                             4482  27-Sep-12 13:10:22
Cmd & Ctrl       Running                             4545  27-Sep-12 13:11:11
Capture          Running                             5513  27-Sep-12 14:01:15
Read             Running                             5514  27-Sep-12 14:01:15
Export           Running                             5556  27-Sep-12 14:01:19

System is used as a source machine
There is 1 active configuration file

ターゲット側でstatusを確認してみると、post queueを分けたことで、postプロセスが2つ起動するため、その状態を確認することが可能です。


sp_ctrl (rhel5spotrg1:2100)> status

Brief Status for rhel5spotrg1
Process          State                             PID     Running   Since
---------------  ------------------------------  --------  --------------------
Cop              Running                             4550  27-Sep-12 13:11:04
Cmd & Ctrl       Running                            20714  27-Sep-12 14:10:33
Import           Running                            14397  27-Sep-12 14:11:56
MTPost           Running                            14398  27-Sep-12 14:11:56
MTPost           Running                            14399  27-Sep-12 14:11:56
There are no active configuration files

また、queueの状態を確認するqstatusコマンドを実行すると、通常は1つのqueueがName: testというように、名前を付けたqueue nameを確認することができました。


sp_ctrl (rhel5spotrg1:2100)> qstatus

Queues Statistics for rhel5spotrg1
  Name:  rhel5sposrc1 (o.src1-o.trg1) (MTPost queue)
    Number of messages:          0 (Age         0 min; Size          1 mb)
    Backlog (messages):          0 (Age         0 min)

  Name:  test (o.src1-o.trg1) (MTPost queue)
    Number of messages:          0 (Age         0 min; Size          1 mb)
    Backlog (messages):          0 (Age         0 min)

ためしに、それぞれのテーブルに対してトランザクションを発生させてみます。


SQL> insert into demo_src values ('Default','Queue','12345');

1行が作成されました。

SQL> insert into demo_dest values ('Named','test','67890');

1行が作成されました。

SQL> commit;

コミットが完了しました。

すると、ターゲット側のqstatusが両方とも更新されていることがわかります。ちなみに、全部で3件だったのが、ターゲット側で合計4件になっているのはおかしいな？と思われた方もいるかもしれません。これは、postプロセスを分けることで、処理が分散されますので、commitも分散して実行する必要があるからです。このような内部の細かい処理はすべてSharePlexが管理しています。


sp_ctrl (rhel5spotrg1:2100)> qstatus

Queues Statistics for rhel5spotrg1
  Name:  rhel5sposrc1 (o.src1-o.trg1) (MTPost queue)
    Number of messages:          2 (Age         0 min; Size          1 mb)
    Backlog (messages):          0 (Age         0 min)

  Name:  test (o.src1-o.trg1) (MTPost queue)
    Number of messages:          2 (Age         0 min; Size          1 mb)
    Backlog (messages):          0 (Age         0 min)

>> まとめ

Postの部分は比較的、ターゲット側のOracleの状態にもよりますが、遅延が起きやすい部分ですが、デフォルトの動作であるマルチスレッドと合わせて、このようなマルチPostの仕組みを使用すると、更なる高速化を行うことが可能です。

次回も高速化するアーキテクチャーの続編をご紹介します。

Recommended