ジャーナリングとデータベースのレプリケーションのトリガ

GT.Mは、「トリガ定義」と「トリガ更新」を別々に処理します。

  1. トリガ定義の変更は、ジャーナル・ファイルとレプリケーション・ストリームの両方に表示され、定義はリカバリされたデータベースとレプリケートされたデータベースに伝播されます。

  2. MUPIP JOURNAL RECOVER/ROLLBACK は、トリガ起動しないため、トリガされた更新はジャーナル・ファイルに出現します。ただし、レプリケーション・インスタンス上の更新プロセスでトリガが適用され、そのロジックが処理されるため、レプリケーション・ストリームには現れません。

ジャーナリング

ジャーナリングがオンの場合、GT.Mはトリガロジックによって実行されるデータベース更新のジャーナルレコードを生成します。明示的なデータベース更新の場合、ジャーナル・レコードは、その更新の一部としてトリガーが呼び出されたかどうかを指定します。GT.Mトリガーは、BEFORE IMAGEのジャーナル・レコードの生成および使用とロールバック/リカバリーのバックワードフェーズに影響を与えません。

ジャーナルされた領域(Region)内のグローバルに関連付けられたトリガーは、ジャーナルされていない領域(Region)で更新を実行できます。ただし、複数の領域(Region)のトリガーが非ジャーナル領域(Region)リージョン内の同じノードを同時に更新する場合、リカバリーまたはロールバックの再生順序が、オリジナルの更新の再生順序と異なる可能性があり、そして異なる結果が生じる可能性があります; したがって、このプラクティスでは、慎重な分析と実装が必要です。デバッグにトリガを使用する場合を除いて、FISはトリガを使用する領域(Region)をすべてジャーナリングすることを推奨します。

次のサンプルのジャーナル抽出は、GT.Mジャーナルが $ZTWORMHOLEのトリガ定義と情報の更新を記録する方法を示しています。

GDSJEX04
01\61731,15123\1\16422\gtm.node1\gtmuser1\21\0\\\
02\61731,15123\1\16422\0
01\61731,15126\1\16423\gtm.node1\gtmuser1\21\0\\\
08\61731,15126\1\16423\0\4294967297
05\61731,15126\1\16423\0\4294967297\1\4\^#t("trigvn","#LABEL")="1"
05\61731,15126\1\16423\0\4294967297\2\4\^#t("trigvn","#CYCLE")="1"
05\61731,15126\1\16423\0\4294967297\3\4\^#t("trigvn","#COUNT")="1"
05\61731,15126\1\16423\0\4294967297\4\4\^#t("trigvn",1,"TRIGNAME")="trigvn#1#
"05\61731,15126\1\16423\0\4294967297\5\4\^#t("trigvn",1,"CMD")="S"
05\61731,15126\1\16423\0\4294967297\6\4\^#t("trigvn",1,"XECUTE")="W $ZTWORMHOLE 
s ^trigvn(1)=""Triggered Update"" if $ZTVALUE=1 s $ZTWORMHOLE=$ZTWORMHOLE_"" 
Code:CR"""
05\61731,15126\1\16423\0\4294967297\7\4\^#t("trigvn",1,"CHSET")="M"
05\61731,15126\1\16423\0\4294967297\8\4\^#t("#TRHASH",175233586,1)="trigvn"_$C(0,0,0,0,0)_
"W $ZTWORMHOLE s ^trigvn(1)=""Triggered Update"" if $ZTVALUE=1 s $ZTWORMHOLE=$ZTWORMHOLE
_"" Code:CR""1"
05\61731,15126\1\16423\0\4294967297\9\4\^#t("#TRHASH",107385314,1)="trigvn"_$C(0,0)_"
W $ZTWORMHOLE s ^trigvn(1)=""Triggered Update"" if $ZTVALUE=1 s $ZTWORMHOLE=$ZTWORMHOLE_"" 
Code:CR""1"
09\61731,15126\1\16423\0\4294967297\1\1\
02\61731,15127\2\16423\0
01\61731,15224\2\16429\gtm.node1\gtmuser1\21\0\\\
08\61731,15224\2\16429\0\8589934593
11\61731,15224\2\16429\0\8589934593\1\"A process context like--> Discount:10%;Country:IN"
05\61731,15224\2\16429\0\8589934593\1\1\^trigvn="Initial Update"
09\61731,15224\2\16429\0\8589934593\1\1\BA
08\61731,15232\3\16429\0\12884901889
11\61731,15232\3\16429\0\12884901889\1\"A process context like--> Discount:10%;Country:IN Code:CR"
05\61731,15232\3\16429\0\12884901889\1\1\^trigvn="1"
09\61731,15232\3\16429\0\12884901889\1\1\BA
08\61731,15260\4\16429\0\17179869185
11\61731,15260\4\16429\0\17179869185\1\"A process context like--> Discount:10%;Country:IN Code:CR"
05\61731,15260\4\16429\0\17179869185\1\1\^trigvn="Another Update"
09\61731,15260\4\16429\0\17179869185\1\1\BA
02\61731,15263\5\16429\0
01\61731,15865\5\26697\gtm.node1\gtmuser1\21\0\\\
08\61731,15865\5\26697\0\21474836481
05\61731,15865\5\26697\0\21474836481\1\2\^trigvn(1)="Updated outside the trigger."
09\61731,15865\5\26697\0\21474836481\1\1\BA
02\61731,15870\6\26697\0
01\61731,15886\6\26769\gtm.node1\gtmuser1\21\0\\\
08\61731,15886\6\26769\0\25769803777
11\61731,15886\6\26769\0\25769803777\1\" Code:CR"
05\61731,15886\6\26769\0\25769803777\1\1\^trigvn="1"
09\61731,15886\6\26769\0\25769803777\1\1\BA
02\61731,15895\7\26769\0
01\61731,15944\7\26940\gtm.node1\gtmuser1\21\0\\\
08\61731,15944\7\26940\0\30064771073
05\61731,15944\7\26940\0\30064771073\1\3\^trigvn="Another Update"
09\61731,15944\7\26940\0\30064771073\1\1\BA
08\61731,16141\8\26940\0\34359738369
11\61731,16141\8\26940\0\34359738369\1\"A process context like--> Discount:10%;Country:IN  Code:CR"
05\61731,16141\8\26940\0\34359738369\1\1\^trigvn="1"
09\61731,16141\8\26940\0\34359738369\1\1\BA
08\61731,16178\9\26940\0\38654705665
11\61731,16178\9\26940\0\38654705665\1\"A process context like--> Discount:10%;Country:IN  Code:CR"
05\61731,16178\9\26940\0\38654705665\1\1\^trigvn="Another update"
09\61731,16178\9\26940\0\38654705665\1\1\BA
02\61731,16210\10\26940\0
01\61731,16517\10\5337\gtm.node1\gtmuser1\21\0\\\
08\61731,16517\10\5337\0\42949672961
05\61731,16517\10\5337\0\42949672961\1\2\^trigvn(1)="4567"
09\61731,16517\10\5337\0\42949672961\1\1\BA
08\61731,16522\11\5337\0\47244640257
11\61731,16522\11\5337\0\47244640257\1\" Code:CR"
05\61731,16522\11\5337\0\47244640257\1\1\^trigvn="1"
09\61731,16522\11\5337\0\47244640257\1\1\BA
08\61731,16544\12\5337\0\51539607553
11\61731,16544\12\5337\0\51539607553\1\"No context Code:CR"
05\61731,16544\12\5337\0\51539607553\1\1\^trigvn="1"
09\61731,16544\12\5337\0\51539607553\1\1\BA
02\61731,16555\13\5337\0
03\61731,16555\13\5337\0\0 

このジャーナル抽出の出力は、 ^trigvn へのトリガ更新ごとに $ZTWORMHOLE 情報を表示します。GT.Mがトリガ定義をどのようにグローバルな構造のノード ^#t のノードとして保存し、GT.Mが ^trigvn のトリガ定義と ^trgvn のトリガ更新をどのように記録したかに注意してください。

注:GT.MはMトランザクションとしてトリガを暗黙的にラップします。したがって、トリガを使用しているデータベースのジャーナル抽出ファイルは、トリガが更新を実行しない場合(つまり、No-op(なにもしない)と同じ効果であっても)、タイプ8およびタイプ9(TSTART / TCOMMIT)レコードを持ちます。

MUPIP JOURNAL -RECOVER / -ROLLBACK

MUPIP JOURNAL -RECOVER / -ROLLBACK によって生成された破損したトランザクション・ファイルには、トリガ定義情報が含まれています。これらのエントリは、+ または - を識別し、MUPIP TRIGGER と $ZTRIGGER() を使用して適切に処理できます。

マルチサイトのデータベース レプリケーション

レプリケーション中、GT.Mはトリガ定義を複製して、MUPIP TRIGGERが開始インスタンスでトリガを更新すると、レプリケートするすべてのインスタンスが論理的に同一のままであることを保証します。

レプリケーション・ストリームには、暗黙的なGT.Mトリガ・ロジックによって生成された更新に関するレコードはありません。トリガ・アクションがルーチンを呼び出す場合は、MUPIPでレプリケーションを呼び出す前に環境変数 gtmroutines の値を指定して、トリガ・アクションの一部として呼び出されたルーチンを更新プロセスが検出できるようにします。

上位互換性をサポートするために、V5.4-000では、オリジナルのプライマリが次のものにレプリケートすることができます。

  1. 異なるトリガ設定を持つインスタンス

  2. 以前のGT.Mバージョン(トリガ機能を持たない)を実行しているインスタンスでは、トリガされた更新をレプリケートします。

複製インスタンスが将来発生する可能性のあるインスタンスとして機能する必要がある場合は、レプリケート・フィルタを慎重に設計して、欠落しているトリガを処理したり、オリジナルのプライマリとの論理的整合性を維持します。

異なるトリガ設定を持つインスタンスでレプリケート

ローリング・アップグレードなどのイベント中に、レプリケート・インスタンスに新しいデータベース・スキーマ(アプリケーションのアップグレードによる)があり、次に新しいトリガ・セットが作成される場合があります。したがって、GT.Mレプリケーションを使用すると、オリジナルの(プライマリ)インスタンスと複製(セカンダリ)インスタンスに対して異なるトリガ構成を持つことができます。2つのインスタンス間でレプリケーションが開始されると、オリジナルのインスタンス上のトリガへの更新は自動的に(フィルタを介して)複製インスタンスに流れます。ローリング・アップグレードの期間中、アプリケーションはレプリケーション・フィルタを使用して、オリジナルのインスタンスのトリガ更新がレプリケート・インスタンスで適切なアクションを生成するようにする必要があります。しかしながら、他の適切なオリジナルのインスタンスのバックアップから複製インスタンスを作成する慣習に従うたびに、バックアップにはGT.Mトリガ定義が含まれているので、通常の条件下では自動的に同じトリガが適用されるため、追加のレプリケーション・フィルタを使用する必要はありません。

レプリケーション・ストリームはネイティブ・キー・フォームを運ぶため、レプリケート・ノード上のレプリケート・グローバルの照合順序と開始ノード上の照合順序が異なることについては、スキーマ変更が効果的であり、そして、添字を開始フォームから複製フォームへ適切に変換するための適切なフィルタが必要です。これはトリガがなくても当てはまります。しかし、トリガを使用すると、不一致も適切なトリガ呼び出しに影響する可能性があります。

GT.Mはトリガを擬似グローバル変数としてデータベース・ファイルに格納するため、トリガの変更を必要とするアプリケーションのアップグレードは、最悪の場合、データベース・スキーマを変更するアプリケーションのアップグレードと変わらず、現在のローリング・アップグレード方法で処理できます。GT.Mトリガの一部の変更は、データベース・スキーマの変更よりもはるかに簡単であり、ローリング・アップグレードは不要です。

トリガをサポートしないインスタンスに複製

レプリケーション接続で、オリジナルのプライマリがトリガをサポートしない複製インスタンスを検出すると、ソース・サーバーは操作ログとソース・サーバー・ログに警告を発行します。ソース・サーバーは、トリガに関連付けられた更新を最初にレプリケートする必要があるときに、操作ログとソース・サーバー・ログに警告メッセージを送信します。この構成では、GT.Mの内部フィルタは、$ZTWORMHOLE データやMUPIP TRIGGERまたは$ZTRIGGER() からトリガ定義の更新などのトリガ関連情報の複製ストリームを取り除きます。ソース・サーバーは、トリガー・ロジック内で更新を送信します。アプリケーションにトリガの不一致を適切に補うレプリケーション・フィルタがないかぎり、レプリケートするインスタンスがオリジナルのプライマリとの論理的整合性を維持しない可能性があることが、懸念される状況です。$ZTWORMHOLEの問題を処理するフィルタは、オリジナルのインスタンスに存在する必要があることに注意してください。

アップデートとヘルパープロセス

レプリケーション・ストリーム・レコードのトリガが発生したことを示すために、更新プロセスは、一致するGT.Mトリガをスキャンし、暗黙的にGT.Mトリガ・ロジックを実行します。

inserted by FC2 system