以下のMUPIPコマンドと修飾子は、GT.M環境でデータベースのレプリケーションを制御します。
コマンド シンタックス：
mupip set {-file db-file|-region reg-list} -replication={ON|OFF}
修飾子：
MUPIP SETのために、それらを使用する方法と同じように、これらの修飾子を使用します。詳細については、 第5章: “一般的なデータベース管理”を参照してください。
-replication=replication-state
GT.Mレプリケーション・サブシステムをON/OFFに切り替え、現在のジャーナリング [no-]before image フィールド（データベースファイルヘッダーに格納されている）を場合によっては変更します。
replication-state は、次のキーワードのいずれかです：
OFF
データベース・ファイルまたは領域(Region)の複製を無効にします。レプリケーションを無効にしても、以前と同じようにジャーナリングを継続動作します。
![[重要]](images/important.jpg) |
重要 |
|---|---|
GT.Mは、新しいジャーナル・ファイルのセットを作成し、replication-state がOFFの場合は以前のジャーナル・ファイルへのバック・リンクを切断し、その後再びONにします。データベースをONにする前の状態にロールバックすることはできません。したがって、replication-state がデータベース複製の期間中ONのままであることを確認してください。replication-state をOFFにするのは、データベースの複製が不要になった場合、または、インスタンスがオリジナルのインスタンスのバックアップからリフレッシュされる直前の場合のみです。 |
選択したデータベース・ファイルまたは領域(Region)の複製を有効にします。JOURNAL修飾子が指定されていない場合、このアクションは BEFORE_IMAGE ジャーナリングをオンにします。no-before-image ジャーナリングで複製を有効にするには、-JOURNAL=NOBEFORE_IMAGEを指定します。いずれの場合も、GT.Mはデータベース・ファイルまたは領域ごとに新しいジャーナル・ファイルを作成し、現在のジャーナルファイルを切り替えます。FISは、希望するジャーナリング特性を指定することをお勧めします（ MUPIP SET -JOURNAL=BEFORE_IMAGE または MUPIP SET -JOURNAL=NOBEFORE_IMAGE）。
レプリケーションがONの場合、JOURNAL修飾子を指定しないで MUPIP SET REPLICATION=ONコマンドを実行すると、現在のジャーナリング特性（データベース・ファイル・ヘッダーに格納されている）が引き継がれます。デフォルトでは、このコマンドによって複製の状態がOFFからONに変更され、JOURNAL=NOBEFORE_IMAGEが指定されていない場合、GT.Mはジャーナル操作をBEFORE_IMAGEに設定します。したがって、伝統的なスクリプトでは、MUPIP SETコマンドのJOURNAL修飾子を使用して、希望するジャーナリング特性を指定する必要があります。
ファイルヘッダーの複製状態 ONは、通常の複製操作を示します。
使用可能なディスクスペースがない、または、ジャーナル・ファイルを自動切り替えしようとするプロセスに許可がないなど、実行時の条件によってGT.Mがジャーナリングをオフにしても、GT.Mがレプリケーションを維持しようとしたときの暗黙のレプリケーション状態を示します。ジャーナリングをオフにしても、ソース・サーバーはレプリケーション・ジャーナル・プールで使用可能なレコードを使用してレプリケーションを続行しようとします。この状態では、必要なすべての情報がレプリケーション・ジャーナル・プール内にある限り、レプリケーションを続行できます。レプリケート・インスタンスまたは通信上の問題が操作上重大に変化するなどのイベントにより、ソース・サーバーにレプリケーション・ジャーナル・プール内の情報よりも古い情報が必要になり、ジャーナル・ファイル内のその情報をその時点で探すことができない可能性がありますソースサーバーがシャットダウンします。
![[注意]](images/note.jpg) |
注意 |
|---|---|
もしレプリケーションオン状態が自転車のように道路上をスムーズに走っているような場合、レプリケーションWAS_ONは自転車のようなもので、フラットな前輪タイヤは一輪車のように乗るようになっています - システムは意図した使用モード以外で動作しています。 |
WAS_ONは暗黙のレプリケーション状態です。WAS_ON状態の間は常に、トランザクションの現在のバックログとジャーナルプールの内容（MUPIP REPLICATE -SOURCE -SHOWBACKLOGおよびMUPIP REPLICATE -SOURCE -JNLPOOL-SHOW）を見ることができます。この情報は、複製OFF状態では使用できません。
WAS_ONからのインスタンスおよび複製インスタンスのリカバリーの詳細については、 レプリケーションのWAS_ON状態からのリカバリー を参照してください。
例：
$ mupip set -replication=on -file mumps.dat
この例では、データベースの複製を有効にし、mumps.dat の before-imageジャーナリングをオンにします。
$ mupip set -replication=on -journal=nobefore_image -file mumps.dat
この例では、データベースの複製を有効にし、mumps.dat の no-before-imageジャーナリングをオンにします。
$ mupip set -replication=off -file mumps.dat
この例では、mumps.datのデータベース複製をオフにします。
mupip replicate -instance_create -name=<instance name> [-noreplace] [-supplementary]
修飾子：
-instance_create
レプリケーション・インスタンス・ファイルを作成します。mupip replicate -instance_createは、複製インスタンスファイルのファイル名を環境変数 gtm_repl_instance から取得します。
もしインスタンス・ファイルがすでに存在する場合、GT.Mはそのファイルにタイムスタンプ接尾辞を付けて名前を変更し、新しい複製インスタンスファイルを作成します。この動作は、新しいジャーナルファイルの作成中に、GT.Mが既存のジャーナルファイルをリネームする方法と似ています。インスタンスファイルの作成は、スタンドアロンのアクセスが必要です。
-name
インスタンスを一意に識別し、不変であるインスタンス名を指定します。インスタンス名は1〜16文字です。GT.Mは環境変数 gtm_repl_instname からインスタンス名（インスタンスファイル名と同じではありません）を取ります。gtm_repl_instname が設定されておらず、-name が指定されていない場合、GT.Mはエラーを生成します。
既存のレプリケーション・インスタンス・ファイルの名前を変更しないようにします。
レプリケーション・インスタンス・ファイルが補足的インスタンスでの使用に適していることを指定します。
例：
$ export gtm_repl_instance=mutisite.repl $ export gtm_repl_instname=America $ mupip replicate -instance_create
この例では、環境変数 gtm_repl_instname で指定されたインスタンス名 America を持つ gtm_repl_instance で指定された multisite.repl という複製インスタンスファイルを作成します。
コマンド シンタックス：
mupip replicate
-edit[instance] {<instance-file>|-source -jnlpool}
{-show [-detail]|-change [-offset=] [-size=] [-value=]}
[-name=<new-name>]
指定された instance-file 属性を表示または変更します。SHOWまたはCHANGE修飾子と組み合わせて -editinstance を使用してください。
ジャーナル・プールの属性を表示または変更します。必ず -source を -jnlpool で指定してください。SHOWまたはCHANGE修飾子と組み合わせて -jnlpool を使用します。
-changeCHANGE 修飾子は、FISのガイダンスのもとでの使用のみを目的としており、2つの目的を果たします。-editinstance -offset -size とともに使用すると、レプリケーションインスタンスファイルの内容が変更されます。-jnlpool とともに使用すると、ジャーナル・プール・ヘッダーの内容が変更されます。インスタンス・ファイルまたはジャーナル・プールでこの機能を使用する場合、MUPIP はスタンドアロンのアクセスを強制しませんが、レプリケーションが活発に行われている場合は、致命的な障害につながる可能性があります。
レプリケーション・インスタンス・ファイルのヘッダー内のインスタンス名を new-name に変更します。インスタンス名を変更すると、インスタンス履歴が保持されることに注意してください。
レプリケーション・インスタンス・ファイルのファイル・ヘッダー、ソース・サーバー・スロット、履歴レコードを表示します。
指定すると、各セクション内のすべてのフィールドが、ファイルの先頭からのオフセットと各フィールドのサイズとともに表示されます。表示されるフィールドの -offset と -size を見つけるには、この修飾子を使用します。表示されているフィールドを編集するには、-change 修飾子を使用します。
新しい値の新しいサイズをバイト単位で示します。sizeの値は、1, 2, 4, 8 のいずれかになります。
-size の倍数である16進数の値をとります。-offset を指定しない場合、GT.Mはエラーを生成します。また、オフセットがインスタンス・ファイルまたはジャーナル・プール・ヘッダーのサイズより大きい場合、GT.Mはエラーを生成します。
指定された -offset と -size を持つフィールドの新しい16進値を指定します。値が指定されていない場合、GT.Mは指定されたオフセットに現在の値を表示し、何も変更を行いません。 -value=<new_value> を指定すると、変更が行われ、古い値と新しい値の両方が表示されます。
 |
注意 |
|---|---|
インスタンス・ファイルまたはジャーナル・プールは、FISの明示的な指示でのみ変更してください。 |
SHOW 修飾子は2つの目的を果たします。-editinstance と一緒に使用すると、レプリケーション・インスタンス・ファイルの内容が表示されます。-jnlpool と一緒に使用すると、ジャーナル・プールの内容が表示されます。
例：
$ mupip replicate -editinstance -show -detail multisite.repl
この例では、レプリケーション・インスタンス・ファイル multisite.repl の内容が表示されます。オプションの detail 修飾子は、各セクションをファイルの先頭からのオフセットと各フィールドのサイズとともに表示します。この情報は、インスタンスファイルを編集する必要がある場合に使用します。
例：
$ mupip replicate -editinstance -change -offset=0x00000410 -size=0x0008 -value=0x010 multisite.repl
このコマンドは、指定されたオフセットとサイズを持つフィールドの値を16に設定します。mupip replicate -editinstance -show -detail コマンドは、インスタンス・ファイル内のすべてのフィールドのオフセットとサイズを表示することに注意してください。
コマンド シンタックス ：
mupip replicate -source -start
{-secondary=<hostname:port>|-passive}
[-buffsize=<Journal Pool size in bytes>]
[-filter=<filter command>]
[-freeze[=on|off] -[no]comment[='"<string>"']
[-connectparams=<hard tries>,<hard tries period>,
<soft tries period>, <alert time>, <heartbeat period>,
<max heartbeat wait>]
-instsecondary=<replicating instance name>
[-[no]jnlf[ileonly]]
-log=<log file name> [-log_interval=<integer>]
{-rootprimary|-propagateprimary} [{-updok|-updnotok}]
[-cmplvl=<compression level>]
[-tlsid=<label>]
[-[no]plaintextfallback]
[-renegotiate_interval=<minutes>]
修飾子：
レプリケーションサブシステムにアクセスするために、この修飾子を使用します。
ソース・サーバーを識別します。
ソース・サーバーを起動します。
複製インスタンスを識別します。<hostname：port> は、"127.0.0.1", "::1", "[127.0.0.1]", "[::1] のように角かっこ（[]）でカプセル化されたIPv4またはIPv6アドレス、または、IPv4 または IPv6アドレスで解決されるホスト名と、レシーバー・サーバーが接続を待機しているポートを指定します。
ご使用の環境でIPv4とIPv6の両方で同じホスト名が使用されている場合、GT.MはデフォルトでIPv6になります。IPv4を使用する場合は、IPv6をサポートしていないGT.Mより前のV6.0-003バージョンのレシーバー・サーバーを実行しているために、環境変数 gtm_ipv4_onlyを "TRUE"、 "YES"、またはGT.MがIPv4を使用するようにするには、非ゼロの整数でなければなりません。
ソース・サーバーをパッシブモードで起動します。
ログファイルの場所を指定します。ソース・サーバーは、失敗した接続の再試行を頻繁に開始することを記録し、約5分に1回の割合で減速します。この間隔は、接続試行の速度には影響しません。
ソース・サーバーがログ・ファイルに書き込む前に待機するトランザクションの数を指定します。デフォルトのロギング間隔は1000トランザクションです。
-log_interval=0 はロギング間隔をデフォルト値に設定します。
-buffsize=<Journal Pool size in bytes>
ジャーナル・プールのサイズを指定します。そのサーバのニーズに合わせて、サイズを上下して丸めてください。1 MB未満のサイズは1 MBに切り上げられます。もし修飾子を指定しないなら、GT.Mのデフォルト値は64MBサイズです。システムが提供する最大共有メモリを超えることはできないことを、忘れないでください。高い更新レートを持つシステムでは、ソースサーバがジャーナルファイルからジャーナルレコードを読み取る時に発生するファイルI/Oとオーバーフローを避けるために、大きいバッファサイズを指定してください。
フィルタ・プログラムの完全なパスと関連する引数を指定します。引数を指定する場合は、コマンド文字列を引用符で囲みます。もしフィルタがアクティブならば、ソースサーバは、入力としてフィルタへ全出力ストリームを渡します。次に、フィルタ・ストリームからの出力が複製インスタンスに渡されます。もしフィルタプログラムが、OLD2NEW^FILTER の entry-ref(入り口参照)を持つMプログラム なら、次のパスを指定します：
filter='"$gtm_dist/mumps -run OLD2NEW^FILTER"'
STDIN からの入力を受け取り、その出力を STDOUT に書き込むUNIXプロセスとしてフィルターを書き込みます。
入力データと出力データのフォーマットは、MUPIP ジャーナル・ファイル抽出フォーマットです。フィルタは、入力ストリームのトランザクションと出力ストリームのトランザクションとの間に、厳密な 1 : 1 の関係を維持する必要があります。もし、入力トランザクションが、出力でSETとKILLが全く生じないならば、それでもフィルタは出力ストリームへ空のトランザクションを書き込む必要があります。
例：
extfilter
; A command like mupip replic -source -start -buffsize=$gtm_buffsize
;-instsecondary=$secondary_instance -secondary=$IP_Address:$portno
;-filter='"$gtm_exe/mumps -run ^extfilter"' -log=$SRC_LOG_FILE
;deploys this filter on the Source Server.
set $ztrap="goto err"
set TSTART="08"
set TCOMMIT="09"
set EOT="99"
set log=$ztrnlnm("filterlog") ; use the environment variable filterlog" (if defined)
;to specify which logfile to use
if logersion="" set log="logcharout" char
if $zv["VMS" sechar EOL=$C(13)_$C(10)
else set EOL=$C(10)
open log:newve:sion
use $principal:nowrap
for do
. use $principal
. read extrRec
. if $zeof halt
. set rectype=$piece(extrRec,"\",1)
. if rectype'=EOT do
.. if rectype'=TSTART set filtrOut=extrRec_EOL
.. else do
... set filtrOut=extrRec_EOL
... for read extrRec set filtrOut=filtrOut_extrRec_EOL quit:$zextract(extrRec,1,2)=TCOMMIT
... if $zeof halt
.. ; set $x=0 is needed so every write starts at beginning of record position
.. ; do not write more than width characters in one output operation to avoid "chopping".
.. ; and/or eol in the middle of output stream
.. ; default width=32K-1
.. ; use $zsubstr to chop at valid character boundary (single or multi byte character)
.. set cntr=0,tmp=filtrOut
.. for quit:tmp="" do
... set cntr=cntr+1,$x=0,record(cntr)=$zsubstr(tmp,1,32767),tmp=$zextract(tmp,$zlength(record(cntr))+1,$zlength(tmp))
... write record(cntr)
. use log
. write "Received: ",EOL,$s(rectype'=TSTART:extrRec_EOL,1:filtrOut)
. if rectype'=EOT write "Sent: ",EOL,filtrOut
. else write "EOT received, halting..." halt
quit
err
set $ztrap=""
use log
write !!!,"**** ERROR ENCOUNTERED ****",!!!
zshow "*"
halt
この例では、STDIN からのトランザクションに関連する論理データベースの更新を読み取り、UNIX の tee コマンドと同様にlog.out と STDOUTに書き込みます。GT.M V5.5-000上で実行され、フィルタ出力をトランザクションとして扱う必要がなくなりました。GT.M V5.5-000より前のバージョンでこの例を実行するには、次の行を次のように置き換えます：
.. if rectype'=TSTART set filtrOut=extrRec_EOL
with
.. if rectype'=TSTART set filtrOut=TSTART_EOL_extrRec_EOL_TCOMMIT_EOL
08 09 にミニ・トランザクションをラップする。
-freeze[=on|off] -[no]comment[='"<string>"']
領域(Region)がインスタンス・フリーズで有効になっているかどうかにかかわらず、インスタンス・フリーズを即座に設定またはクリアします。引数なしで-freezeを実行すると、インスタンス上のインスタンスフリーズの現在の状態が表示されます。
- [no]comment[='"<string>"'] は、インスタンス・フリーズに関連するコメント/理由を指定できます。コメント/理由を指定しない場合は、-nocommentを指定します。
カスタムエラーでインスタンス・フリーズを呼び出すための領域の有効化の詳細については、“SET” の章の -INST_FREEZE_ON_ERRORセクションを参照してください。
インスタンス・フリーズの詳細については、 “インスタンス・フリーズ” を参照してください。
-connectparams=<hard tries>,<hard tries period>, <soft tries period>,<alert time>,<heartbeat period><max heartbeat wait>
接続リトライパラメータを指定します。もし、ソースおよびレシーバサーバ間の接続が壊れているならば、または、ソースサーバが起動時に受信サーバへの接続に障害があるならば、ソースサーバが再接続を試行するには、これらのパラメータを適用します。
まず、ソースサーバは、<hard tries period>ミリ秒 (ハードトライ期間)毎に<hard tries>値(ハードトライ)によって指定される再接続の試行数を作ります。次に、ソースサーバは <soft tries period> 秒(ソフトトライ期間)毎に再接続を試み、そして、<alert time> 秒(警告時間)毎に警告メッセージをログに記録します。もし指定された<alert time>値(警告時間)が、<hard tries> * <hard tries period> / 1000 + <soft tries period> ( ハードトライ値 ＊ ハードトライ期間/ 1000 + ソフトトライ期間 ) より小さいならば、それは大きな値に設定されます。ソースサーバは、受信サーバへハートビートメッセージを<heartbeat period>秒毎に送信 し、受信サーバから<max heartbeat wait>秒以内で応答の返答を期待しています。
ソース・サーバーがデータを複製するための複製インスタンスを識別します。
-instsecondary を指定しない場合、ソース・サーバーは複製インスタンスの名前に環境変数 gtm_repl_instsecondary を使用します。
-instsecondary が指定されていない環境変数 gtm_repl_instsecondary が設定されていない場合、mupip replicate -source -checkhealthは、実行中および実行中のすべてのソースサーバ（アクティブまたはパッシブ）と異常終了しました（kill -9）。kill-15 または MUPIP STOPのソース・サーバは、GT.Mがソースサーバを通常の方法でシャットダウンしたとみなして無視されます。このコマンドは、稼働中であるか、異常終了している（kill -9）ソース・サーバーが少なくとも1つ検出された場合にのみ、何かを報告します。それ以外の場合は、ジャーナルプールが存在し、GT.Mプロセス（レプリケーション中のインスタンスの更新プロセスまたはレシーバサーバ）が起動していても、報告するものがない状態でゼロ（0）のステータスが返されます。
複数のソース・サーバーは、それぞれが -instsecondary の別の名前を指定する限り、同じオリジナルのインスタンスから開始できます。
パッシブ・ソース・サーバーを起動する場合でも -instsecondary を明示的に（値を指定して）指定するか、暗黙的に（環境変数gtm_repl_instsecondaryを介して）指定します。アクティブにすると、パッシブ・ソース・サーバーがこの複製インスタンスに接続します。
例：
$ mupip replicate -source -start -buffsize=$gtm_buffsize -secondary=localhost:1234 -log=A2B.log -instsecondary=B
このコマンドは、複製インスタンスとしてインスタンス B を持つオリジナルのインスタンスのソース・サーバーを起動します。
ソース・サーバーがジャーナル・プールの共有メモリの代わりにジャーナル・ファイルからトランザクションを読み込むようにします。SYNC_IOジャーナル・オプションと組み合わせると、ジャーナル・レコードがディスクに固まるまで、トランザクションのレプリケーションが遅延します。プライマリ上のクラッシュとロールバックは、受信側インスタンス上のローカル更新のロールバックを必要とする可能性があるため、補足的インスタンスにレプリケートするときに役立ちます。デフォルトは -NOJNLFILEONLY です。
現在のインスタンスをオリジナルのインスタンスとして割り当てます。-rootprimary を明示的または暗黙的に指定して、インスタンスをオリジナル・インスタンスとして開始することができます。
このインスタンスのローカル更新を許可するようにソース・サーバーに指示します。これは -rootprimary と同義ですが、その目的を明確に伝えるように名前が付けられています。
現在のインスタンスを伝播インスタンスとして割り当てるには、このオプションの修飾子を使用します。-propagateprimary を指定すると、現在のインスタンスの更新が無効になります。
ジャーナル・プールを停止せずに、オリジナルのインスタンスを伝播インスタンスに移行することはできません。ただし、すでに実行中のパッシブ・ソース・サーバーのジャーナル・プールを停止せずに、伝播中のインスタンスをオリジナルのインスタンスに移行することは可能です（実行していない場合は -propagateprimary で開始します）。
-rootprimary と -propagateprimary はオプションで、相互に排他的です。ただし、明快にするために、スクリプトに -rootprimary と -propagateprimary の両方を明示的に指定することをFISは推奨します。
例：
$ mupip replicate -source -activate -rootprimary
このコマンドは、ジャーナル・プールを停止させることなく、伝播中のオリジナルのインスタンスをオリジナルのインスタンスに遷移させます。
-rootprimary も -propagateprimary も指定されていない場合、GT.Mはパッシブ・ソース・サーバの起動コマンド（mupip replic -source -start -passive）とdeactivate修飾子（mupip replicate -source -deactivate）のデフォルト値 -propagateprimary を使用します。GT.Mは、mupip replicate -source -start -secondary=... と mupip replic -source -activate コマンドに対して、デフォルト値の -rootprimaryを使用します。これらのデフォルト値を使用すると、オリジナルのインスタンスと複数の複製インスタンス（それ以降のインスタンスを複製する必要はありません）に制限することを計画しているユーザーにとって、複製スクリプトが簡単になります。
$ export gtm_repl_instance=multisite.repl $ mupip set -journal="enable,before,on" -replication=on -region "*" $ mupip replicate -instance_create -name=America $ mupip replicate -source -start -buffsize=$jnlpool_size -secondary=localhost:1234 -log=A2B.log -instsecondary=Brazil
この例では、複製インスタンス Brazil のポート1234でソース・サーバーを起動します。ソース・サーバーは、ジャーナル・プールを作成します。GT.Mプロセスは、更新されたジャーナル・レコードをジャーナル・プールに書き込みます。次に、ソース・サーバー プロセスは、ジャーナル・プールから Brazil に各レコードをTCP / IP接続を介して転送します。
|
注意 |
|---|---|
レプリケーションを開始する前に、必ずレプリケートされたすべてのデータベース領域を停止してから、ソースサーバーを起動してください。 |
|
重要 |
|---|---|
複製された領域(Region)へのGT.Mの更新は、オリジナルのインスタンス上でのみ許可され、他のすべての複製インスタンスでは無効になります。 |
ソース・サーバは、A2B.log にアクションとエラーを記録します。また、現在のバックログ、最後のログ以降に送信されたジャーナル・レコードの数、送信レート、開始と現在のJNL_SEQNO、フィルタ・プログラムのパス（存在する場合）などの統計も定期的に記録します。
このインスタンスのローカル更新を許可しないようにソース・サーバーに指示します。これは -propagateprimary と同義ですが、その目的を明確に伝えるように名前が付けられています。
レプリケーション・ストリームの望ましい圧縮レベルを指定します。n は、望ましい圧縮レベルを示す正の整数値である。レベル0は圧縮を行いません。レベル1は最も圧縮率が低く、レベル9（zlibライブラリのバージョン1.2.3.3現在）は（ほとんどのCPU使用量を犠牲にして）圧縮率が最も高くなります。-start を指定せずに -cmplvl を指定すると、エラーが発生します。ソース・サーバの場合、N がzlibライブラリで受け入れられる範囲外の値を指定した場合、または-cmplvlが指定されていない場合、圧縮レベルはデフォルトでゼロ（0）になります。レシーバー・サーバの場合、Nが非ゼロである限り、解凍の機能が有効になります； ソース・サーバーの設定によって実際のレベルが決まるため、正当なゼロ以外の値があれば、受信側での圧縮処理が有効になります。
代わりに、環境変数 gtm_zlib_cmp_level は、（上記のNと同じ値の範囲内で）望ましい圧縮レベルを指定することができ、ソース・サーバは -cmplvl なしで起動することができます。-cmplvl を指定して起動するのと同じ効果があります。コマンドラインで明示的に指定された値は、環境変数で指定された値を上書きします。
ソース・サーバーとレシーバー・サーバーが相互に接続するたびに、ソース・サーバーが有効なゼロ以外の圧縮レベルで開始された場合、ソース・サーバーが有効な非ゼロ圧縮レベルで開始された場合、まず、レシーバー・サーバーが、圧縮されたレコードを処理し、非ゼロの圧縮レベルで開始されたGT.Mのバージョンを実行しているかどうかを判別します。これが真である場合に限り、それらは圧縮されたジャーナル記録を使用することに同意します。また、圧縮されたジャーナルデータを送信する前に、圧縮/解凍が正しく機能することをテストメッセージで確認します。このテストが失敗した場合、またはいずれの時点でどちらの側で圧縮または解凍が失敗したことが検出された場合は、自動的に非圧縮モードに移行します。つまり、圧縮/解凍ロジックの実行時エラーが発生すると、非圧縮レプリケーション（レプリケーションのスループットが低下します）が発生しますが、レプリケーションの機能的な健全性を損なうことはありません。
ソース および レシーバー・サーバーは、すべての圧縮に関連するイベントおよび/またはメッセージをそれぞれのログに記録します。また、ソース・サーバーは、ログファイルに圧縮データの長さ（非圧縮データ長に加えて）を記録します。
|
注意 |
|---|---|
もしレプリケーション用のオプションの圧縮機能を使用する予定であれば、圧縮ライブラリを提供する必要があります。圧縮ライブラリ用のGT.Mインタフェースは、適応作業を必要とせずに、zlib圧縮ライブラリを受け入れます。これらのライブラリは、多くのUNIXディストリビューションに含まれており、zlibのホームページからダウンロードできます。もし他の圧縮ライブラリを使用する場合、zlibが提供する同じAPIを提供するためにそれらを設定したり、適応させる必要があります。多くのプラットフォームでは zlibをコンパイルするための簡単な手順は以下のとおりです。GT.M は zlibを使用しますが、zlibはFISソフトウェアではなく、FISはzlibをサポートしていません。これらの指示は、単にあなたの便宜のために提供されています。 |
もしzlibのためのパッケージがあなたのオペレーティングシステムで利用可能ならば、構築よりはむしろその利用について、FISは提案します。
Sun StudioからSolaris/cc コンパイラ：
./configure --shared make CFLAGS="-KPIC -m64"
HP-UX(IA64)/HP Cコンパイラ：
./configure --shared make CFLAGS="+DD64"
AIX/XL コンパイラ：
./configure --shared Add -q64 to the LDFLAGS line of the Makefile make CFLAGS="-q64"
Linux/gcc:
./configure --shared make CFLAGS="-m64"
z/OS:
SourceForge.com の libpngプロジェクトのダウンロードページからzlib 1.1.4をダウンロードしてください。tarball のソースをダウンロードするための自動変換を実行しない転送メカニズムを使用してください。pax がアーカイブを読み取れない場合、ダウンロードがアーカイブを変更したという兆候です。ファイルをASCIIからEBCDICに変換して、tarballを解凍するにはpaxを使用します。
pax -r -o setfiletag -ofrom=ISO8859-1,to=IBM-1047 -f zlib-1.1.4.tar.gz
zlib 1.1.4ソースに以下のパッチを適用してください：
---------------------------------- zlib_1.1.4_zos.patch --------------------------------------------------diff -purN downloads/zlib/src.orig/configure downloads/zlib/src/configure--- downloads/zlib/src.orig/configure Tue Dec 16 14:09:57 2008+++ downloads/zlib/src/configure Mon Feb 9 14:30:49 2009@@ -116,6 +116,11 @@ else SFLAGS=${CFLAGS-"-Kconform_pic -O"} CFLAGS=${CFLAGS-"-O"} LDSHARED=${LDSHARED-"cc -G"};;+ OS/390*)+ CC=xlc+ SFLAGS=${CFLAGS-"-qascii -q64 -Wc,DLL,LP64,XPLINK,EXPORTALL -D_ALL_SOURCE_NOTHREADS"}+ CFLAGS=${CFLAGS-"-qascii -q64 -Wc,DLL,LP64,XPLINK,EXPORTALL -D_ALL_SOURCE_NOTHREADS"}+ LDSHARED=${LDSHARED-"xlc -qascii -q64 -Wl,dll,LP64,XPLINK "};; # send working options for other systems to support@gzip.org *) SFLAGS=${CFLAGS-"-O"} CFLAGS=${CFLAGS-"-O"}
環境変数 C89_CCMODE を1に設定して、zlib DLLをビルドしてインストールし、xlcコンパイラとモード互換性を持たせます。互換モードでない場合、xlc はコマンドラインオプションの厳密な配置に従います。 ./configure --shared && makeでzlibソフトウェアを設定し、ビルドします。デフォルトでは、configureスクリプトはzlibを /usr/local/ lib に置きます。make install でソフトウェアをインストールします。GT.Mがzlibを見つけられるようにするには、LIBPATHに/usr/local/libをインクルードします。環境変数は、プロセスがDLLをリンクするときに使用する検索パスを提供します。
デフォルトでは、GT.M検索libz.so共有ライブラリ（HPUX PA-RISC上でlibz.sl）の標準システム·ライブラリ·ディレクトリ（たとえば、/ usr / libには、/ usr / local / lib、/ usr / localに/ lib64に）。共有ライブラリは、レプリケーションを開始する前に、非標準の場所にインストールされている場合は、環境変数$ LIBPATH（AIXおよびz / OS）または$ LD_LIBRARY_PATH（その他のUNIXプラットフォームでは）ライブラリをcontainungディレクトリが含まれていること。ソースおよびレシーバ・サーバーは実行時に共有ライブラリをリンクします。これは何らかの理由（例えば、ファイルが見つからない、または不十分な承認など）で失敗した場合、複製ロジックがDLLNOOPENエラーをログに記録し、圧縮なしで続行されます。
ソースまたはレシーバー・サーバーに、gtmcrypt_config環境変数が指す構成ファイル内のTLSIDとして<label>を持つTLS証明書と秘密鍵のペアを使用するように指示します。インスタンス間のレプリケーション接続を保護するためにTLS / SSLを使用する場合、TLSIDは必須パラメータです。秘密鍵が暗号化されている場合、gtmtls_passwd_ <label>の形式の環境変数は難読化されたパスワードを指定します。暗号化プラグインとともに提供されている 'maskpass' ユーティリティを使用して、パスワードを難読化することができます。もし暗号化されていない秘密鍵を使用する場合は、gtmtls_passwd_ <label>環境変数をヌル以外のダミー値に設定します； これは、パスワードの不適切なプロンプトを防ぎます。
レプリケーション・サーバーが平文通信にフォールバックできるかどうかを指定します。デフォルトは -NOPLAINtextfallback です。もし NOPLAINTEXTFALLBACKが有効な場合、GT.MはTLS接続を確立できない場合にREPLNOTLSエラーを発行します。[注意：V6.1-000以前のGT.MバージョンはTLSをサポートしていませんでした。必要に応じてstunnel（http://stunnel.org）のような外部アプリケーションで実装することができます] 。 PLAINTEXTFALLBACKが有効な場合、TLS接続の確立に失敗した場合、GT.Mは警告としてREPLNOTLSを発行します。一度接続セッションに対して許可された平文レプリケーション接続が確立されると、GT.Mはその接続セッションをTLS接続に切り替えることはありません。
-RENEGotiate_interval=<minutes >
TLS 再ネゴシエーションを実行する前に待機する時間をミリ秒単位で指定します。デフォルトの -RENEGOTIATE_INTERVAL は120分を少し超えています。0 の値を指定すると、GT.Mは再ネゴシエーションを試みません。MUPIP REPLIC -SOURCE -JNLPOOL -SHOW [-DETAIL] コマンドは、次のTLS再ネゴシエーションがスケジュールされる時刻と、特定のセカンダリインスタンス接続でこれまでに発生した再交渉の数を示します。再ネゴシエーションでは、レプリケーションパイプラインを一時的にフラッシュし、その後に実際の再ネゴシエーションを行う必要があるため、TLS再ネゴシエーションによってレプリケーションバックログに瞬間的なスパイクが発生する可能性があります。
コマンド シンタックス ：
mupip replicate -source -shutdown [-timeout=<timeout in seconds>]
修飾子：
ソース・サーバをシャットダウン
ソース・サーバーをシャットダウンするように通知するまでに shutdown コマンドが待機する時間（秒）を指定します。-timeoutを指定しない場合、デフォルトのタイムアウト時間は120秒です。もし -timeout=0 を指定すると、シャットダウンがすぐに発生します。
コマンド シンタックス ：
mupip replicate -source -activate
-secondary=<hostname:port>
-log=<log file name>
-connectparams=<hard tries>,<hard tries period>,
<soft tries period>,<alert time>,<heartbeat period>,
<max heartbeat wait>]
-instsecondary=<instance_name>
{-rootprimary|-propagateprimary}
修飾子：
パッシブ・ソース・サーバーをアクティブにします。ソース・サーバーは、いったんアクティブ化されるとジャーナル・レコードをジャーナル・プールから読み取り、それらを -secondaryで指定されたシステムに転送します。
アクティブ化する前に、-activate はソース・サーバをACTIVE_REQUESTEDモードに設定します。アクティベーションが成功すると、GT.Mはソース・サーバ・モードをACTIVEに設定します。ACTIVE_REQUESTEDモードでソース・サーバをアクティブ化しようとすると、GT.Mはエラーを生成します。
-instsecondary=<instance_name>
アクティブ化後にパッシブ・ソース・サーバーが接続する複製インスタンスを識別します。
-instsecondaryを指定しない場合、パッシブ・ソース・サーバーは-instsecondaryの値として環境変数 gtm_repl_instsecondary を使用します。
オリジナルのインスタンスでパッシブ・ソース・サーバーのアクティブ化を実行することを指定します。
パッシブ・ソース・サーバーのアクティブ化が、伝播中のインスタンスで発生することを指定します。
-rootprimary も -propagateprimary もどちらも指定されていない場合、このコマンドは-propagateprimaryとみなされます。
例：
$ mupip replicate -source -activate -secondary=localhost:8998 -log=A2B.log -instsecondary=America
この例では、ソース・サーバーをパッシブモードからアクティブにします。
コマンド シンタックス ：
mupip replicate -source -deactivate -instsecondary=<instance_name>
修飾子：
アクティブなソース・サーバーをパッシブにします。ソース・サーバーが通信しているレプリケーション・インスタンスを変更するには、ソース・サーバーを非アクティブ化し、別のレプリケーション・インスタンスでアクティブ化します。
非アクティブ化の前に、-deactivate はソース・サーバーをPASSIVE_REQUESTEDモードに設定します。正常に非アクティブ化すると、GT.Mはソース・サーバーモードをPASSIVEに設定します。PASSIVE_REQUESTED モードでソース・サーバーを非アクティブ化しようとすると、GT.Mはエラーを生成します。
-instsecondary=<instance_name>
パッシブ（スタンバイ）状態に移行するアクティブなソース・サーバーを指定します。
-instsecondary を指定しない場合、$gtm_repl_instsecondary はアクティブ・ソース・サーバを決定します。
アクティブなソース・サーバーがオリジナルのインスタンスにあることを指定します。
アクティブなソース・サーバーが伝播中のインスタンス上にあることを指定します。
-rootprimary も -propagateprimary もどちらも指定されていない場合、このコマンドは-propagateprimaryとみなされます。
ソース・サーバー上でアクティブなフィルターを停止するには、2つの方法があります。
オリジナルのソース・サーバで mupip replicate -source - -stopsourcefilterを実行します。
レシーバー・サーバーを起動するオプションとして-stopsourcefilterを指定します。
|
|
フィルターがミニ・トランザクションまたはTPトランザクションの送達にわずか1分で応答しない場合、ソースまたはレシーバー・サーバーはFILTERTIMEDOUTエラーを出し、フィルターを停止して終了します。 |
ソースサーバが実行されているかどうかを検出するために、次のコマンドと修飾子を使用します。
コマンド シンタックス ：
mupip replicate -source -checkhealth [-instsecondary=<instance_instance>] [-he[lpers]]
修飾子：
ソース・サーバが実行されているかどうかを決定します。もしソースサーバーが実行されているならば、終了コードは0（ゼロ）です。もしソースサーバーが停止またはエラー終了ならば、終了コードはゼロではありません。
ヘルパーが指定されている場合、-checkhealth は、レシーバー・サーバーおよび更新プロセスのステータスに加えて、ヘルパープロセスのステータスを表示します。
-instsecondary=<instance_name>
ソース・サーバープロセスを識別します。
-instsecondary が指定されていない場合、-checkhealth はすべてのソース・サーバーのプロセスをチェックします。
例：
$ mupip replic -source -checkhealth -inst=INSTB Fri May 21 15:26:18 2010 : Initiating CHECKHEALTH operation on source server pid [15511] for secondary instance name [INSTB] PID 15511 Source server is alive in ACTIVE mode $ mupip replic -source -checkhealth -inst=INSTB Fri May 21 15:29:52 2010 : Initiating CHECKHEALTH operation on source server pid [0] for secondary instance name [INSTB] PID 0 Source server is NOT alive %GTM-E-SRCSRVNOTEXIST, Source server for secondary instance INSTB is not alive
コマンド シンタックス ：
mupip replicate -source -changelog -log=<log file name> [-log_interval=<integer>] -instsecondary=<instance_name>
修飾子：
-changelog
そのログファイルを変更するように、ソース・サーバに指示します。
-instsecondary=<instance_name>
ソース・サーバープロセスを識別します。
-log=<log file name>
新しいログファイルの名前を指定するために、この必須修飾子を使用します。もし現ログファイルの名前を指定するなら、変更はありません。
例：
$ mupip replicate -source -changelog -log=/more_disk_space/newA2B.log -instsecondary=Brazil
ソース・サーバーがログ・ファイルに書き込む前に待機するトランザクションの数を指定します。デフォルトのロギング間隔は1000トランザクションです。
-log_interval=0 はロギング間隔を以前の値に戻します。
コマンド シンタックス ：
mupip replicate -source -statslog={ON|OFF}
[-log_interval=<integer>
修飾子：
詳細なログを、有効または無効にします。ONの場合、システムは、ソースサーバの現在の状態の情報とソースと受信サーバ間の交換メッセージをログに記録します。デフォルトでは、詳細ログはOFFです。いったんそれを有効（ON）にすると、 -statslog をOFFに変更することで、詳細ログを停止することができます。
ソース・サーバーがログ・ファイルに書き込む前に待機するトランザクションの数を指定します。デフォルトのロギング間隔は1000トランザクションです。
-log_interval=0 はロギング間隔を以前の値に戻します。
コマンド シンタックス：
mupip replic -source -shutdown [-instsecondary=<instance_name>] [-timeout=<seconds>]
修飾子：
-instsecondary=<instance_name>
ソース・サーバープロセスを識別します。
もし -instsecondary が指定されていない場合、-shutdown はすべてのソースサーバープロセスを停止します。
ソース・サーバーがシャットダウンするまでの待機時間（秒）を指定します。もし -timeoutを指定しない場合、デフォルトのタイムアウト時間は30秒です。 -timeout=0を指定すると、すぐにシャットダウンが発生します。
コマンド シンタックス ：
mupip replicate -source -showbacklog
修飾子：
出力デバイス（通常は標準出力デバイス）上のジャーナル・レコードの現在のバックログ（JNL_SEQNOに関して）を報告します。この修飾子はログファイルに記録される統計情報には影響しません。バックログは、ジャーナルプールに書き込まれる最後のJNL_SEQNOと、ソースサーバによって受信サーバへ送信される最後のJNL_SEQNOとの間に違いがあります。WAS_ON状態では、ソース・サーバーがシャットダウンされていても、-showbacklog はバックログ情報を報告します。
例：
$ mupip replic -source -showbacklog -inst=INSTB Wed May 19 18:58:29 2010 : Initiating SHOWBACKLOG operation on source server pid [0] for secondary instance [INSTB] 101 : backlog number of transactions written to journal pool and yet to be sent by the source server 102 : sequence number of last transaction written to journal pool 1 : sequence number of last transaction sent by source server %GTM-E-SRCSRVNOTEXIST, Source server for secondary instance INSTB is not alive
バックログがゼロのときのフェイルオーバーを除いて、以前のオリジナルのインスタンスが新しい複製インスタンスとして登場するたびに、常に失われたトランザクション・ファイルが存在します。この失われたトランザクション・ファイルは、他のフェイルオーバー時に追加の失われたトランザクション・ファイルが存在する可能性があるため、できるだけ早く新しいオリジナルのインスタンスに適用します。たとえば、失われたトランザクション・ファイルが処理される前に、新しいオリジナルのインスタンスの障害。これらの追加失われたトランザクション・ファイルは、失われたトランザクション処理に必要なロジックを複雑にする可能性があります。
M-組み込み関数 $ZQGBLMOD() を使用して、手動で、または半自動化された方法で、新しいオリジナルのインスタンスで失われたトランザクションを適用します。$ZQGBLMOD() を使用すると、失われたトランザクション処理の一部として2つの追加のステップが実行されます（ mupip replicate -source -needrestart と mupip replicate -source -losttncomplete）。これらのステップを実行しないと、$ZQGBLMOD() が false のネガティブを返すことになり、アプリケーション・データの一貫性の問題が発生する可能性があります。
コマンド シンタックス：
mupip replicate -source
{-losttncomplete | -needrestart}
-instsecondary=<replicating instance name>
$ZQGBLMOD() を使って失われたトランザクション処理がすべて完了したことをGT.Mに示します。明示的または暗黙的にこの修飾子を使用すると、将来の失われたトランザクションを適用するときに、インスタンス上の将来の$ZQGBLMOD() が誤検出を防ぐことができます。これにより、将来の$ZQGBLMOD() の結果の精度が保証されます。
オリジナルのインスタンスが複製インスタンスとして起動する場合は、常にこの修飾子を使用します。
以下の場合を除いて、失われたすべてのトランザクション・ファイルを適用した後で、各複製インスタンスで常にMUPIP REPLICATE -SOURCE -LOSTTNCOMPLETEを実行します。
複製インスタンスは、オリジナルのインスタンス上でコマンドが実行された時点で、オリジナルのインスタンスに接続されます。
複製インスタンスは、オリジナルのインスタンスでコマンドを実行するときには接続されず、オリジナルのインスタンスが停止する前にオリジナルのインスタンスに接続されます。
オリジナルのインスタンスが起動されてから、オリジナルのインスタンスが指定された複製インスタンスと通信したかどうかを確認します（レシーバー・サーバーまたは複製インスタンス上のフェッチ再同期のロールバックがソース・サーバーと通信した場合）。その場合、このコマンドは、複製インスタンスがオリジナルのインスタンスと通信し、したがって再起動する必要がないことを示すメッセージである "SECONDARY INSTANCE xxxx DOES NOT NEED TO BE RESTARTED (セカンダリ・インスタンス xxxxは再起動する必要はありません)" を表示します。そうでない場合、このコマンドは "SECONDARY INSTANCE xxxx NEEDS TO BE RESTARTED FIRST (セカンダリ・インスタンス xxxxを最初に再起動する必要がある) "というメッセージを表示します。この場合、このインスタンスから失われたトランザクションが適用される前に、指定されたインスタンスを複製インスタンスとして起動します。対応する失われたトランザクションを適用する前にそうしなければ、$ZQGBLMOD() はfalse ネガティブを返すため、アプリケーションのデータが矛盾する可能性があります。
mupip replic -source -needrestart コマンドは、適用する必要のある失われたトランザクション・ファイルごとに1回呼び出す必要があります。失われたトランザクションを適用する前に、新しいオリジナルのインスタンスで呼び出される必要があります。失われたトランザクション・ファイルが生成された複製インスタンスのインスタンス名を与えるには、-instsecondaryを指定します。そうでない場合、環境変数 gtm_repl_instsecondary は暗黙的に複製インスタンスの名前を保持するものと見なされます。
失われたトランザクションファイルが適用される同じインスタンスから生成された場合、mupip replicate -source -needrestartコマンドは必要ありません。
複製するインスタンス（-needrestartコマンドで指定）を、現在のオリジナルのインスタンスの即時の複製インスタンスとしてもたらすことをいつも覚えておいてください。もし別の中間レプリケーション・インスタンスを介して複製インスタンスとして起動された場合、-needrestart コマンドは、インスタンスが起動していたとしてもインスタンスをオリジナルのインスタンスと通信していないものと無条件にみなします。
オリジナルのインスタンスおよび/またはレシーバー・サーバーまたは複製インスタンスのフェッチ再同期(fetchresync)ロールバックは、このコマンドを実行した時点で起動している必要はありません。
しかし、オリジナルのインスタンスが起動してからある時点でアップしていれば十分です。
このコマンドは、失われたトランザクション・ファイルが生成された時にオリジナルのインスタンスが、失われたトランザクションが適用されたときのプライマリ・インスタンスとは異なるシナリオを保護します（デュアルサイト構成の場合は決して異なることはありませんが、それにもかかわらず、このコマンドは依然として必要です）。
$ZQGBLMOD() は、オリジナルのインスタンスのデータベース・ファイル・ヘッダー内の2つのフィールドを使用して適切に設定されます。Zqgblmod Trans と Zqgblmod Seqno 。 LMS構成では、3つ以上のインスタンスが存在し、オリジナル・インスタンスと複製インスタンス以外のインスタンスがロールバックに含まれていない場合は、-fetchresync がシーケンス番号の決定に関与します。したがって、特定の失われたトランザクション・ファイルが生成されると、Zqgblmod Seqno（したがってZqgblmod Trans）が設定されません。参加していないインスタンスのいずれかが新しいオリジナルのインスタンスとして呼び出され、その特定の失われたトランザクション・ファイルがオリジナルのインスタンスに適用された場合、リファレンス・ポイント（Zqgblmod Trans）が適切に設定されていないので、$ZQGBLMOD() の戻り値は信頼できません。したがって、このコマンドは、失われたトランザクションが以前に生成された複製インスタンスが、オリジナルのインスタンスとして現れた後、現在のオリジナルのインスタンスと通信したかどうかをチェックします。もし肯定的であれば、Zqgblmod SeqnoフィールドとZqgblmod Transフィールドは適切に設定されているので、$ZQGBLMOD()の値は正しいでしょう。
例：
$ mupip replic -source -losttncomplete
このコマンドは、グローバル・ディレクトリ内のすべての領域のデータベース・ファイル・ヘッダーにあるZqgblmod Seqno とZqgblmod Transフィールド（dse dump-fileheaderコマンドで表示される）の値を 0 に更新します。そうすることによって、次の失われたトランザクション・ファイルが作成されるまで、後続の$ZQGBLMOD() が無条件に1(one)の安全な値を返すようになります。
失われたトランザクション・ファイルの最初の行には、最大4つのフィールドが含まれます。最初のフィールドには、ファイル形式のバージョンを示す GDSJEX04 が表示されます。2番目のフィールドには、失われたトランザクション・ファイルがロールバックまたはリカバリの結果であるかどうかが示されます。 もし2番目のフィールドがROLLBACKの場合、3番目のフィールドは、失われたトランザクション・ファイルが生成される直前のインスタンスが PRIMARY か SECONDARY かを示します。もし PRIMARY の場合、失われたトランザクション・ファイルは、主な失われたトランザクション・ファイル(primary lost transaction file)と呼ばれ、新しいオリジナルのインスタンスに適用する必要があります。4番目のフィールドは、失われたトランザクションが生成された複製インスタンスの名前を保持します。このインスタンス名は、失われたトランザクションが新しいオリジナルのインスタンスで適用されたときに、mupip replic -source -needrestartコマンドで-instsecondary修飾子として使用する必要があります。
失われたトランザクション・ファイルの最初の行は、次のようになります：
GDSJEX04 ROLLBACK SECONDARY Perth
コマンド シンタックス ：
mupip replicate -receiver -start
-listenport=<port number>
-log=<log file name> [-log_interval="[integer1],[integer2]"]
[-autorollback[=verbose]]
[-buffsize=<Receive Pool size in bytes>]
[-filter=<filter command>]
[-noresync]
[-stopsourcefilter]
[-updateresync=</path/to/bkup-orig-repl-inst-file>
{[-resume=<strm_num>|-reuse=<instname>]}
[-initialize] [-cmplvl=n]
[-tlsid=<label>]
修飾子：
-receiver
レシーバー・サーバを識別する。
-start
レシーバー・サーバーと更新プロセスを開始します。
レシーバー・サーバーがソース・サーバーからの着信接続をリッスンするTCPポート番号を指定します。レシーバー・サーバの現在の実装では、複数のIPアドレスを持つマシンのサポートはしていないことに注意してください。
mupip journal -rollback -backwardコマンドを使用してソース・インスタンスをロールバックするときに、SI または BC複製の受信インスタンスが必要に応じてロールバックすることを許可します。オプション値のキーワードVERBOSEは、より多くの診断情報を提供するロールバックを可能にします。
|
注意 |
|---|---|
自動ロールバックは裏側で mupip online rollback を使用するので、その機能がフィールド・テスト・グレードの機能性と見なされる限り、フィールド・テスト・グレード機能とみなすべきです。 |
-log=<recsrv_log_file_name >
レシーバー・サーバーのログファイルの場所を指定します。-log を指定すると、更新プロセスは <recsrv_log_file_name>.updproc という名前のログファイルに書き込みます。更新プロセス・ログファイル名の最後に .updproc が付いていて、レシーバー・サーバーのログファイル名と区別できることに注意してください。
-log_interval="[integer1],[integer2]"
integer1 は、レシーバー・サーバーがログ・ファイルに書き込む前に待機する必要があるトランザクションの数を指定します。integer2 は、更新プロセスがログファイルに書き込む前に待機するトランザクションの数を指定します。デフォルトのロギング間隔は1000トランザクションです。
integer1 または integer2 が0の場合、ロギング間隔はデフォルト値に設定されます。
-stopsourcefilter を使用してレシーバー・サーバーを開始すると、オリジナルのソース・サーバー上のアクティブなフィルターはすべてオフになります。ローリング・アップグレードが完了した後にレシーバー・サーバーを再起動するときに、このオプションを使用します。
-updateresync=</path/to/bkup-orig-repl-inst-file>
-updateresyncは、複製インスタンスがオリジナルのインスタンスと同期していたまたは同期していることをGT.Mに保証し、それは複製を再開するのが安全です。-updateresync は、次の場合にのみ使用します：
GT.Mバージョンへのアップグレードでインスタンス・ファイル形式が変更された場合、既存のレプリケーション・インスタンス・ファイルを置き換える場合。リリースノートを調べて、アップグレードに該当するかどうかを判断してください。
既存のレプリケーション・インスタンス・ファイルが破損または削除されたため使用できなくなり、新しいレプリケーション・インスタンス・ファイルで置き換えられた場合。
もし Pが、オリジナルのインスタンスに存在しない、または存在しないことが予想される既存の更新を含む既存のインスタンスである場合、A -> P構成を初めて設定する場合。
オリジナルのインスタンスのバックアップ（A->Pのみ）または複製するセカンダリ・インスタンスの1つから新しい複製インスタンスを設定する場合。
もしV5.5-000より前のGT.Mバージョンを実行しており、オリジナルのインスタンスのバックアップから複製インスタンスを設定する必要がある場合。
-updateresync は、複製インスタンスのデータベースに格納されているジャーナル・シーケンス番号と、オリジナルのインスタンス（</path/to/bkup-orig-repl-inst-file>）のレプリケーション・インスタンス・ファイルのバックアップコピーで使用可能な履歴レコードを使用して、レプリケーションを開始するジャーナル・シーケンス番号を決定します。
中断後にレプリケーションが再開されると（ネットワークまたはメンテナンスの問題により）、GT.Mは、複製インスタンスの複製インスタンス・ファイルに格納されている履歴レコードと、オリジナルのインスタンスの複製インスタンス・ファイルに格納されている履歴レコードとを比較して、複製を再開するポイントを決定します。このメカニズムにより、中断後にレプリケーション接続が再開されたときに、2つのインスタンスが常に同期した状態に保たれます。-updateresync は、複製インスタンスの複製した履歴を無視し、オリジナルのインスタンス履歴の現在のジャーナル・シーケンス番号とその履歴レコードのみに依存して複製を再開するためのポイントを決定することによって、このメカニズムをバイパスします。安全性チェックを無効にするので、-updateresync は慎重に検討した後に使用してください。状況に合わせて-updateresyncが適切かどうかについては、GT.Mのサポートチャネルで確認できます。
updateresync を実行するには、オリジナルのインスタンスに少なくとも1つの履歴レコードが必要です。ソース・サーバーの実行中に、オリジナルのインスタンスのレプリケーション・インスタンス・ファイルのバックアップ（BACKUP-REPLINST）を取る必要があります。これにより、インスタンスファイルに少なくとも1つの履歴レコードが確実に格納されます。オリジナルのインスタンスの複製インスタンスファイルのコピー（たとえばscp）をソースサーバーのシャットダウン後に使用することは安全ですが、ソースサーバーのシャットダウンを必要としないため、BACKUP -REPLINSTを推奨します。また、複製インスタンスの空のインスタンスファイル（-INSTANCE_CREATE）が必要です。これにより、現在および以前の状態の履歴情報をバイパスすることができます。
また、GT.Mバージョンのアップグレードでインスタンスファイル形式が変更された場合、既存のレプリケーションインスタンスファイルを置き換えるには、-updateresyncを使用する必要があります。V5.5-000ではインスタンス・ファイル形式が変更されました。したがって、複製インスタンスをGT.M V5.5-000より前のバージョンからV5.5-000以上にアップグレードするには、インスタンスファイルを置き換える必要があります。
V5.5-000より前のバージョンでは、-updateresyncに引数（<bckup_orig_repl_inst_file>）は必要ありませんでした。-updateresyncの構文はGT.Mのバージョンによって異なります。
-updateresyncを使用するプロシージャの詳細は、“オリジナルのインスタンスの新しいレプリケーション・インスタンスの設定（ A->B、P->Q、または A->P）”、“レプリケーション・インスタンスのレプリケーション・インスタンス・ファイルを置換（A->B および P->Q）”、“レプリケーション・インスタンスのレプリケーション・インスタンス・ファイルの置換（A-> P）”、“オリジナルのインスタンスのバックアップから新しいレプリケーション・インスタンスを設定（A-> P）” を参照してください。
-updateresync を指定してSIレプリケーション・ストリームのレシーバー・サーバーを起動し、これがインスタンス間の最初の接続であることを指定する場合に使用します。MUPIPは、BCレプリケーションを開始するとき（つまり、レシーバー・サーバーでインスタンスに対して更新が許可されていない）、これらの修飾子を無視します。この修飾子は、誤ったエラーに対する追加のプロテクションを提供します。
レシーバー・インスタンスが以前に同じソースから受信していて、しかし中間でそのインスタンス・ファイル（データベースファイルではない）だけを再作成した場合に、-updateresync を使用してSIレプリケーション・ストリームのレシーバー・サーバーを開始するときに使用されます（これにより、ソース・インスタンスに関するすべての情報とレシーバー・インスタンス・ファイルに記録されることに対応するストリーム番号が消去）。この場合、コマンド mupip replic -receiv -start -updateresync=<instfile> -resume=<strm_num>では、strm_num は1から15までの数字で、レシーバー・サーバーにデータベース・ファイル・ヘッダーを使用して<strm_num>で指定されたストリーム番号のレシーバー・インスタンスの現在のストリーム・シーケンス番号を検索するように指示しますが、しかし、入力インスタンス・ファイル（-updateresyncで指定）を使用してこのストリーム・シーケンス番号に対応する履歴レコードの位置をつきとめて、次に履歴をソースと交換して、レプリケーションを再開する前に2つのインスタンスが同期していることを確認します。-resumeが指定されておらず、SIレプリケーション・ストリームに対して-updateresyncのみが指定されている場合、-updateresyncで指定された入力インスタンス・ファイル名を使用して、ストリーム・シーケンス番号を決定し、ソース・インスタンスと交換するための履歴レコードを提供します（2つのファイルが同期していることを確認します）。インスタンスファイルが決して再作成されないと仮定すると（データベースが再作成されない限り）、この修飾子は通常の使用状況では必要ないはずです。
レシーバー・インスタンスが以前に15個（アーキテクチャ上許容されるすべての）異なる外部ソース・ストリームから以前に受信し、さらに、別のソース・ストリームから受信を開始している場合に、-updateresync を使用してSIレプリケーション・ストリームのレシーバー・サーバーを開始するときに使用されます。コマンド mupip replic -receiv -start -updateresync=<instfile> -reuse=<instname> では、instname はレプリケーション・インスタンスの名前で、レプリケーション・インスタンス・ファイル・ヘッダー内の既存のストリームを検索し、グループインスタンス名（レシーバー・レプリケーション・インスタンス・ファイル上で mupip replic -editinstance -showコマンドによって表示されます）が指定されたインスタンス名と一致する場合、レシーバー・サーバーに現在のソース接続にそのストリーム番号を再利用するよう指示します （同じストリーム番号を使用して古いグループのレコードを消去）。
受信者が送信元よりも先であっても、レシーバー・サーバーがSIレプリケーション・ストリームを受け入れるように指示します。この場合、ソースとレシーバー・サーバーは、レプリケーション・インスタンス・ファイルから履歴レコードを交換して、共通のジャーナル・ストリーム順序番号を決定し、その時点以降のレプリケーションを再開します。BCレプリケーション・ストリームで-noresyncを指定すると、NORESYNCSUPPLONLYエラーが発生します。受信インスタンスが -UPDNOTOK（更新が無効）で開始されたSIレプリケーション・ストリームのレシーバー・サーバー上で -noresyncを指定すると、NORESYNCUPDATERONLYエラーが発生します。noresync修飾子は、ロールバックのresync修飾子（mupip journal -rollback -resync）の反対ではなく、FIS GT.Mのサポートのもとで使用することを意図しています。
ソースまたはレシーバー・サーバーに、gtmcrypt_config環境変数が指す構成ファイル内のTLSIDとして<label>を持つTLS証明書と秘密鍵のペアを使用するように指示します。インスタンス間のレプリケーション接続を保護するためにTLS / SSLを使用する場合、TLSIDは必須パラメータです。秘密鍵が暗号化されている場合、gtmtls_passwd_ <label>の形式の環境変数は難読化されたパスワードを指定します。暗号化プラグインとともに提供されている 'maskpass' ユーティリティを使用して、パスワードを難読化することができます。もし暗号化されていない秘密鍵を使用する場合は、gtmtls_passwd_ <label>環境変数をヌル以外のダミー値に設定します； これは、パスワードの不適切なプロンプトを防ぎます。
もし受信サーバから独立してシャットダウンしているなら、次のコマンドは更新プロセスだけを開始します。
コマンド シンタックス ：
mupip replicate -receiver -start {-updateonly|-helpers[=m[,n]]
修飾子：
もし更新プロセスが受信サーバから独立してシャットダウンしていたなら、更新プロセスを再起動するために、この修飾子を使用します。
追加のプロセスを開始して、着信レプリケーション・ストリームからの更新が複製インスタンスに適用されるレートを向上させます。
m はヘルパー・プロセスの総数です、n はリーダ・ヘルパ・プロセスの数であり、換言すれば m >= n です。
ヘルパープロセスは、レシーバー・サーバーでのみ開始できます。
ヘルパープロセスがすでに実行されている場合、-helpers[=m[,n]] を指定すると、追加のヘルパープロセスが再び開始されます。レシーバー・サーバーには最大128のヘルパープロセスが存在します。
-helpers=0[,n] を指定すると、GT.Mはヘルパー処理を開始しません。
指定されたHELPERS修飾子が指定されていて、m も n も指定されていない場合、GT.Mはデフォルトの役割の割合でヘルパー・プロセスのデフォルト数を開始します。ヘルパー・プロセス合計のデフォルト数は8個であり、そのうち5個は読み取りヘルパーで、3個の書き込みヘルパーです。
m だけ指定で、フロア（5 * m/8）プロセスが読み取りヘルパーであることで、ヘルパープロセスが開始されます。
m とn の両方を指定すると、GT.Mは m個のヘルパープロセスを開始し、n は読み取りヘルパー、m-n は書き込みヘルパーです。m < nの場合、mupipはm個の読み取りヘルパーを起動し、nをm個に減らし、事実上書き込みヘルパーを起動しません。
GT.Mは、mupip replicate -updhelper -reader と mupip replicate -updhelper -writerとしてhelperプロセスを報告します（たとえば、ps コマンドと /procファイルシステムを実装するプラットフォーム上の/proc/<pid>/cmdline によって）。
例：
$ mupip replicate -receiver -start -listenport=1234 -helpers -log=B2C.log -buffsize=$recpool_size
このコマンドは、ヘルパー・プロセスを使ってレシーバー・サーバーを開始します。次の psコマンドの出力例は、5個のリーダー・プロセスと3個のライター・プロセスがあることを示しています。
gtmuser1 11943 1 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -receiver -start -listenport=1234 -helpers -log=B2C.log -buff=$rec_pool_size gtmuser1 11944 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updateproc gtmuser1 11945 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -reader gtmuser1 11946 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -reader gtmuser1 11947 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -reader gtmuser1 11948 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -reader gtmuser1 11949 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -reader gtmuser1 11950 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -writer gtmuser1 11951 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -writer gtmuser1 11952 11943 0 06:42 ? 00:00:00 /usr/library/GTM/mupip replicate -updhelper -writer
コマンド シンタックス ：
mupip replicate -receiver -shutdown [-updateonly|-helpers] [-timeout=<timeout in seconds>]
修飾子：
更新プロセスだけを停止するために、この修飾子を使用します。-updateonly と-helper のどちらも指定されていない場合、更新プロセス、すべてのヘルパー・プロセス（存在する場合）、およびレシーバー・サーバーがシャットダウンされます。
ヘルパー・プロセスのみをシャットダウンし、以前と同じように継続動作するようにレシーバー・サーバーと更新プロセスを残します。-helper 値が指定されていても、すべてのヘルパー・プロセスはシャットダウンします。
-timeout
レシーバー・サーバー、更新プロセス、および/または、ヘルパー・プロセスがシャットダウンするようにシグナルを通知する前に、shutdownコマンドが待機する時間（秒）を指定します。 -timeoutを指定しない場合、デフォルトのタイムアウト時間は30秒です。 -timeout=0を指定すると、すぐにシャットダウンが発生します。
例：
$ mupip replicate -receiver -shutdown -helper
この例では、現在のレシーバー・サーバーのヘルパー・プロセスのみをシャットダウンします。HELPER値が指定されていても、すべてのヘルパープロセスがシャットダウンすることに注意してください。
受信サーバが実行されているかどうかを検出するために、次のコマンドを使用します。
コマンド シンタックス ：
mupip replicate -receiver -checkhealth
コマンド シンタックス ：
mupip replicate -receiver -changelog -log=<log file name> [-log_interval="[integer1],[integer2]"]
-log_interval="[integer1],[integer2]"
integer1 は、レシーバー・サーバーがログ・ファイルに書き込む前に待機するトランザクションの数を指定します。integer2 は、更新プロセスがログファイルに書き込む前に待機するトランザクションの数を指定します。デフォルトのロギング間隔は1000トランザクションです。
integer1 または integer2 が0の場合、ロギング間隔は以前の値に戻ります。
コマンド シンタックス ：
mupip replicate -receiver -statslog={ON|OFF}
[-log_interval="[integer1],[integer2]"]
-log_interval="[integer1],[integer2]"
integer1 は、レシーバー・サーバーがログ・ファイルに書き込む前に待機するトランザクションの数を指定します。integer2 は、更新プロセスがログファイルに書き込む前に待機するトランザクションの数を指定します。デフォルトのロギング間隔は1000トランザクションです。
integer1 または integer2 が0の場合、ロギング間隔は以前の値に戻ります。
コマンド シンタックス ：
mupip replicate -receiver -showbacklog
修飾子：
-showbacklog
この修飾子を使用して、レシーバー・サーバー上のジャーナル・レコードの現在のバックログを報告します（つまりバックログは、レシーバー・プールに最後に書き込まれたJNL_SEQNOと更新プロセスによって最後に処理されたJNLSEQNOの差）
コマンド シンタックス ：
mupip journal -rollback
{[-fetchresync=<port number>|-resync=<JNL_SEQNO>]
[-rsync_strm=<strm_num>]}
-losttrans=<extract file> -backward *
修飾子：
データベースをロールバックするために、この修飾子を使用します。もし -fetchresync 修飾子を使用しないなら、データベースは最後に整合性のある状態へロールバックします。
-fetchresync=<port number>
<port number> は、ロールバックコマンドがリファレンス・ポイントを取得している時に使用しているその通信ポート番号です。受信側サーバーで使用されているものと同じロールバック用の、オリジナルのインスタンスで常に同じ<port number>を使用してください。
|
重要 |
|---|---|
同期外れ状態の可能性を避けるために、複製インスタンス上の任意のソースサーバを起動する前に、mupip journal -rollback -fetchresync コマンドを無条件にスクリプト化することを、FISはお勧めします。 |
オリジナルのインスタンスによって送信された参照ポイントは、オリジナルのインスタンスが一度保持していたRESYNC_SEQNO（後述）です。データベース/ジャーナル・ファイルは、以前のRESYNC_SEQNO（つまり、オリジナルのインスタンスから受信したものか、または、ローカルに維持されているもの）からロールバックされます。もし -fetchresync を使用しない場合、データベースは最後の一貫した複製インスタンス状態にロールバックされます。
FETCHRESYNC ROLLBACK 操作は、現在の作業ディレクトリをソース・サーバー・ログに送信します。
システムは、この必須の修飾子で指定されたファイル<extract file> の中で、抽出される失われたトランザクションを保存します。失われたトランザクションの検索の開始点は、-fetchresync操作でオリジナルのインスタンスから取得されたJNL_SEQNOです。 もし -fetchresync が指定されていない場合、<extract file>は、一貫性のある状態に到達するためにロールバックプロシージャによって取り消された整合性の悪い(post-consistent-state transaction)トランザクションをリストします。
|
注意 |
|---|---|
抽出された紛失トランザクションのリストには、処理中に発生したシステム障害のために壊れたトランザクションが含まれることがあります。これらのトランザクションを解決しないでください、それらはコミットされているとは見なされません。 |
|
注意 |
|---|---|
もし進行中の ROLLBACK -FETECHRESYNC 操作を中断した場合、または、もし2つのインスタンス間のTCP接続が切断された場合、データベース・ヘッダーが破損する可能性があります。回避策は、ROLLBACK -FETCHRESYNC操作を再始動するか、または、FETCHRESYNC操作がタイムアウトするまで60秒待つことです。 |
例：
$ mupip journal -rollback -fetchresync=2299 -losttrans="glo.lost" -backward *
このコマンドは、オリジナルのインスタンスが更新を送信してそれに追いつくことができる位置から共通の同期ポイントへ移動させるために、複製インスタンス上の ROLLBACK -FETCHRESYNC操作を実行します。また、複製インスタンス上に存在するが、しかし、ポート2299のオリジナルのインスタンス上には存在しない、すべてのそれらトランザクションの失われたトランザクションファイルglo.lostも生成されます。
この修飾子を使用すると、データベース/ジャーナル・ファイルを特定のポイントにロールバックする必要がある場合にのみJNL_SEQNO（10進数）で識別されるトランザクションにロールバックできます。もし最後の一貫性のある状態よりも大きいJNL_SEQNOを指定すると、データベース/ジャーナル・ファイルは最後の一貫性のある状態にロールバックされます。通常の動作条件下では、この修飾子を必要としません。
フェイルオーバーが発生した場合（つまり、オリジナルのインスタンスが失敗し、インスタンスの複製がオリジナルのインスタンスの役割を引き継ぐ場合）、A のデータベースにコミットされたトランザクションの一部が Bのデータベースに反映されないことがあります。以前のオリジナルのインスタンスが新しい複製インスタンスになる前に、オリジナルのインスタンスの役割を果たす前に、これらのトランザクションをロールオフする必要があります。これらのトランザクションは、"失われたトランザクション" として知られます。
システムは、この必須の修飾子で指定されたファイル<extract file> の中で、抽出される失われたトランザクションを保存します。失われたトランザクションの検索の開始点は、-fetchresync操作でオリジナルのインスタンスから取得されたJNL_SEQNOです。 もし -fetchresync が指定されていない場合、<extract file>は、一貫性のある状態に到達するためにロールバックプロシージャによって取り消された整合性の悪い(post-consistent-state transaction)トランザクションをリストします。
|
注意 |
|---|---|
抽出された紛失トランザクションのリストには、処理中に発生したシステム障害のために壊れたトランザクションが含まれることがあります。これらのトランザクションを解決しないでください、それらはコミットされているとは見なされません。 |
-resync修飾子を指定してロールバック・コマンドを開始するときに使用します。mupip journal -rollback -resync=<sequence_num> -rsync_strm=<strm_num> コマンドは、データベースを -resync=<sequence_num>修飾子で指定されたシーケンス番号にロールバックするように指示しますが、<sequence_num>は、ストリーム番号<strm_num>に対応するジャーナル・ストリーム・シーケンス番号（ジャーナル・シーケンス番号ではない）であり、0〜15の任意の値にすることができます。-resync修飾子と同様に、-rsync_strm修飾子もGT.Mサポートチャネルの指示の下で使用することを意図しています。