| >> はじめに |
前回は大量のトランザクション発生時の動作を確認しましたが、今回は、同じくガイドに従った続きとして、「ターゲットが利用できない時の動作」について確認していきましょう。
| >> 現在の状況を確認して、ターゲットをシャットダウンしてみるとどうなるか？ |
最初に、sp_ctrlコマンドのコンソールから、ソースとターゲットのそれぞれのマシン上でstatusを確認しておきます。
ソース側では、capture, read, export等のプロセスが上がっているのが確認できます。
|
ターゲット側では、それをimportしてpostにより処理するプロセスが確認できます。
|
この状態で、ターゲットをshutdownコマンドによりシャットダウンします。
シャットダウンすると、sp_copの親プロセス自体が起動していない状態になりますので、SharePlexのstatus等による確認もできない状態になります。
|
ターゲット側がシャットダウンしている状態で、ソース側から前回作成したdemo.sqlのスクリプトを実行します。スクリプトの詳細については、前回の講座を参考にするようにしてください。
|
この状態で、ソース側のstatusを確認すると、captureやreadといった、変更内容をキューに格納するプロセスは動作していますが、ターゲット側にキューを転送する役割を持つexportがidleとなって停止していることが確認できます。
|
sp_ctrlのコンソールから、キューの状態を確認するqstatusコマンドを実行すると、demo.sqlによって生成されたトランザクションがキューとなって格納されている状態が確認できます。
messagesという数が実際のトランザクションの数よりも大幅に少ないのは、SharePlexは同じようなトランザクションが連続した場合に、それを1件づつmessagesとして処理するのではなく、効率よく処理ができるようにまとめる機能があるためです。
|
ソース側のdemo_srcのテーブルの件数を確認すると、前回の講座で100001になった件数がさらに10万件増えていることが確認できます。
|
しかし、SharePlexがシャットダウンされているターゲット側の件数を確認すると、未だに10万件程度なことがわかります。
|
| >> ターゲットでsp_copを起動して、処理を再開させてみよう |
差分の更新内容は、ターゲット側のsp_copが起動していない状態では、ソース側のキュー用ディスクに格納されています。そこで、ターゲット側でsp_copを再起動して、動作の継続を確認してみましょう。
sp_copの起動方法は、インストール後にSharePlexを起動した際とまったく同じになります。
|
再度、statusを確認すると、キューを受け取るべきimportがソース側のexportと通信をして、受け取れる状態になるまで、少し時間がかかることもあります。そのような状態ではimportだけidleになっていますが少し待ってみてください。
|
ソース側とターゲット側が正しく通信ができる準備が整ったら、すべてstateがrunningの状態になります。以下はターゲット側の状態ですが、ソース側も準備が整っていますので確認してみてください。
|
再度qstatusで状況を確認するとNumber of messagesの件数が減っていることが確認できます (もしくは、状況によっては減っている最中かもしれません)。
|
最終的にターゲット側のdemo_destテーブルには、ソース側で発生したトランザクションの内容がすべて反映されていることが確認できるはずです。
|
| >> まとめ |
これで、sp_copのプロセス自体がシャットダウンされても、再起動ができればキューの処理が正しく継続されることが確認できました。
次回も更にテストを継続し、SharePlexの動作を確認していきます。