>> はじめに |
本連載をご覧いただいている皆さんであれば、SharePlexが何のソフトかどうかは、既にお分かりかと思います。それは、もちろんOracleのデータをリアルタイムにレプリケーションするソフトです。
では、レプリケーションというデータの複製にとって、一番大切なことはなんでしょうか?
SharePlexの特徴で考えると、様々なOSへの対応や、Oracleのバージョン、そしてエディションへの対応面、前回まで少し特集した高速性、オペレーションに関連する操作性などいろいろと考えられます。
しかし、もっとも重要なことはソース側のデータをターゲット側へと、まったく同じように複製することを保障することが、レプリケーションソフトの使命ではないでしょうか?
今回からは少し、SharePlexがいかにデータの整合性を重要視しているかをご紹介していきます。
>> データが非同期状態になるということ |
ソース側とターゲット側で、データが異なる状態、つまり非同期の状態になることが考えれます。その原因には、いくつかのパターンがあります。
- レプリケーション ソフトウェアの問題
- ターゲット側でデータを更新
- ストレージ障害
- その他
要因はいくつも考えられますが、その中でもターゲット側で間違ってデータを更新してしまった、というようなケースは比較的発生しやすい事象になります。
>> ターゲット側で間違って更新したらどうなるか? |
SharePlexをはじめとする論理レプリケーションソフトでは、主にOracleのログを元に、ソースからターゲットへ独立したプロセスで複製を行います。
INSERT、UPDATE、DELETEのDMLのトランザクションを処理していく訳ですが、INSERTは新規でレコードを追加するので、確認は難しいのですが、UPDATEの場合には、元々異なる値があって、それを新規の値に変更するという処理を行います。
その際に、行特定をして、特定の列を単純に変更するという処理も可能ですが、SharePlexの場合には、ソース側のREDOログに記録されたBefore Imageを使用して、元々の値のチェックをして、ターゲット側で値を変更するという動作を行っています。
以下の図を例にしてご説明すると、時間軸を上から下にしてみると、T1からT3までのトランザクションがソース側であり、Balance列だけが変化していきます。その際に、T2からT3の間にターゲット側でBalanceを1500に間違って更新してしまった場合には、エラーが検出されます。これは、ターゲット側のUPDATEをWHERE句を使用して、Balanceが800であったこと確認するためです。
>> 実際に確認してみましょう |
では、実際に上図の内容で動作を確認してみます。
■テスト用のテーブルの準備
最初にソース側でconfigファイルがdeactivateされた状態を確認しておきます。
|
configファイルを編集して、定義を追加します。
|
expandによって、testユーザスキーマ以下をすべてターゲットへ同名で複製するワイルドカードの設定を追加します。
|
追加した定義内容に基づいてレプリケーションが行われるよう、activateを実行します。
|
expandというワイルドカードの指定がある定義をactivateしたことによって、DDLの伝播も行われるようになったため、testユーザによって、ソース側でテーブルを作成してみます。
|
そうするとターゲット側にテーブルが作成されたことが、確認できます。
|
以上で、確認するための準備が整いました。
■テスト用のトランザクションを発生させてみる
まずは、ソース側で最初のINSERTを実行します。
|
ターゲット側で確認すると、きちんと反映できていることが確認できます。
|
次は、例にあったT2のトランザクションです。
|
再度ターゲットで確認すると、正常に反映されています。
|
■ターゲット側で間違って値を変更するとどうなるか?
では、例にあったようにターゲット側でbalanceを1500に設定してみます。
ターゲット側もデータベースがオープンな状態で自由に更新が可能ですので、変更ができてしまいます。
|
その状態で、ソース側を更新してみます。ソース側は当然のことながら、値の更新が可能です。
|
ターゲットを確認してみると、値が1200にはなっておらず、間違って更新された1500の状態になっています。
|
ターゲット側には、sp_ctrlにアクセスしてSharePlexの状態を確認するshow statusdbコマンドで確認するとErrorが発生しています。
|
Errorが発生してもソース側のDBの更新は止まりませんので、ここで更にbalanceを1200から2000に変更してみましょう。
|
デフォルトでは、SharePlexは動作を停止させずに、他のレプリケーションを継続します。sp_ctrlからstatusを確認してみても、そのことが確認できます。
|
では、非同期状態の内容はどこにあるのでしょうか? 答えは、logディレクトリにあるSID名_errlog.sqlというファイルにあります。
|
中を確認すると、詳細な非同期状態の情報を確認することが可能です。
|
※BALANCE列の表記はe表記 (指数表記) になっています。
>> まとめ |
今回は、errorの確認までを行いましたが、次回は実際に発生した非同期状態を解消していく方法等についてご説明していく予定です。