技術情報：GT.M - UNIX上でマルチサイトレプリケーションのサポート
Copyright © 2006 Fidelity National Information Services, Inc.
2006年6月14日
| 改訂履歴 | |
|---|---|
| Revision 1.0 | 2006年6月14日 |
|
|
|
目次
- 概要
- サマリ
- ユーザインタフェース
- レプリケーション インスタンス ファイル
- MUPIP REPLIC –INSTANCE_CREATE –NAME ( -name 修飾子を使ってレプリケーション インスタンス名を指定)
- -INSTSEC[ONDARY] 修飾子 (セカンダリインスタンスを指定する修飾子)
- -ROOT[PRIMARY] と –PROPAGATE[PRIMARY] 修飾子 (プライマリを指定する修飾子)
- 廃止された–UPDATE修飾子
- MUPIP REPLIC –SOURCE –START (ソースサーバを起動)
- MUPIP REPLIC –RECEIVER –START (レシーバを起動)
- MUPIP REPLIC –SOURCE –ACTIVATE (ソースサーバをアクティブにする)
- MUPIP REPLIC –SOURCE –DEACTIVATE (ソースサーバを非アクティブにする)
- インスタンスを起動する
- インスタンスをシャットダウンする
- プライマリとセカンダリの転移
- プライマリのバックアップからセカンダリをリフレッシュ
- ロストトランザクション処理
- MUPIP REPLIC –EDIT[INSTANCE] (インスタンスの編集)
- MUPIP REPLIC -SOURCE –JNLPOOL (ソースサーバのジャーナルプール)
- DSE DUMP -FILE[HEADER] (ファイルヘッダをDSEでダンプ)
- DSE CHANGE -FILE[HEADER] (ファイルヘッダをDSEで変更)
- MUPIP JOURNAL -ROLLBACK (MUPIP ジャーナル ロールバック)
- MUPIP BACKUP (MUPIP バックアップ)
- ローリングアップグレード
- エラーメッセージ
- 表記規則
GT.M V5.1-000 は、1つのプライマリサイトへの複数のセカンダリサイトを持つ論理マルチサイト構成でアプリケーションを配置する機能を提供します。
GT.Mの以前のバージョンでは、1つだけのセカンダリサイトを持つ論理デュアルサイト構成でアプリケーションを配置する機能が特徴でした。
オペレーションの効率化のために隣接するプライマリとセカンダリを持つ構成は、しかしながら、両方のシステムに影響を与える破壊に対する保護はありません。分離し遠隔操作の "災害復旧 ディザスタリカバリ"（DR）の第3のシステムは、ルーチンオペレーションのための直近システムの便利のよい操作性と、致命的なイベントに直面して事業を継続するための遠隔システムを、提供します。以前のGT.Mバージョンでは、複数のセカンダリ あるいは/または(and/or) ターシャリ( 3番目の)システムの設定はうまくできませんでした。GT.M V5.1-000は、そのようなマルチサイトの構成などを可能にします。ビジネスの継続性において新バージョンへの移行については、デュアルサイト構成がサポートされます。その環境は、一方のサイトがマルチサイトレプリケーションが有効になっているGT.Mバージョンで動作し、他方のサイトはレプリケーションが無効なGT.Mバージョンで動作する環境です。
![[注意]](images/note.png) | |
サイトとインスタンスの表現は、レプリケーションに関係するプライマリまたはセカンダリシステムを言及するこの技術情報を介して交互に使われます。GT.Mは、特定のマシンに依存するインスタンス数に制限が全くないことに、注意してください。 |
| |
1つのプライマリと1つのセカンダリ間のGT.Mレプリケーションを使用する構成を、今後は、デュアルサイト構成と呼び、一方、1つのプライマリと1つ以上のセカンダリ あるいは/または ターシャリ(3番目の) 間のGT.Mレプリケーションを使用する構成を、今後は、マルチサイト構成と呼びます 。同様に、1つのプライマリと1つのセカンダリの間のレプリケーションを、デュアルサイトレプリケーション と呼びます。1つのプライマリと1つ以上のセカンダリ あるいは/または ターシャリ(第3)の間のレプリケーションを、 マルチサイトレプリケーションと呼びます。 |
GT.M V5.1-000 は、 1つのプライマリサイトから複数のセカンダリサイトへのレプリケーションをサポートしています。GT.Mの以前のバージョンにおけるように、与えられたどんなインスタンスにおいても、1つだけのプライマリインスタンスが更新を実行します。GT.M V5.1-000では、このプライマリは16個もの数の追加インスタンスへ同時にレプリケートできます。セカンダリサイトのいくつかは、プライマリの想定外停止または計画停止のイベントで、新しいプライマリになることができます。
停止から回復した後、オリジナルのプライマリはセカンダリになり、もしかすると、（再）処理により新プライマリへ送信するために、ロストトランザクションファイルを生成します。
マルチサイト構成の機能は、ターシャリ(3番目)のインスタンスへトランザクションを渡すためのセカンダリインスタンスを可能にします。トランザクションデータは、プライマリからセカンダリへターシャリへ流れます。ここでは、セカンダリはターシャリのためにプライマリとして動作します。したがって、もし16個のセカンダリインスタンスのそれぞれが、16個のターシャリ(3番目)インスタンスへフィードされたならば、273インスタンスできます（1プライマリ+16セカンダリ+ 256 ターシャリ）。もしターシャリ(3番目)インスタンスが、クォータナリ(第4番目：quaternary) インスタンスへフィードされたならば、4,369インスタンスできます（1プライマリ+ 16 セカンダリ+ 256 ターシャリ + 4096 クォータナリ ）。など。
もし現在のプライマリがダウンするならば、プライマリ以下のインスタンスのツリー内での任意のインスタンスが潜在的に新プライマリになる可能性があるので、インスタンスの任意の再構成は実現可能となります。
| |
ツリー構造はレプリケーションに必要とされ、そして、サイクルはサポートされません。 |
 | |
ただ、GT.Mがインスタンスの任意の再構成を可能にするだけの理由で、アプリケーションまたはアプリケーションの固有の配置が任意の再構成のような許可を必要とする、という訳ではありません。各アプリケーションの配置は、綿密な構成設定と、想定外の障害や計画的停止に対処するための戦略が必要です。 |
プライマリ（ターシャリ第3番目としても）としても動作しているセカンダリと実際のプライマリを区別するために、GT.M V5.1-000では、伝搬プライマリ対ルートプライマリの概念を紹介します。
ビジネスロジックが実行され、そして、データベース更新の結果が計算され＆コミットされるそのインスタンスは、ルートプライマリと呼ばれます 。プライマリ（ターシャリ第3番目へ伝搬）として動作するセカンダリは、伝搬プライマリと呼ばれます 。これはターシャリ(第3目)からクォータナリ(第4番目：quaternary)へなどのようにレプリケートできるように、さらに拡張ができます。この場合においては、ターシャリ(第3番目)もまた伝搬プライマリとして動作します 。GT.M V5.1-000の 1つのルートプライマリ を除いて、伝搬プライマリ群は任意数を作ることが可能です。
レプリケートされた領域へのGT.Mプロセスの更新は、ルートプライマリを除いてすべてのインスタンスで無効になっています（注意：万が一DSEので修理を必要としている破損した構造データベースの場合は、mupipの領域とデータベースの修復は、論理更新を考慮せず、そしてセカンダリ上で許可されてます）。現在のインスタンスがルートプライマリか伝搬プライマリかどうかを識別するには、ソースサーバーを -rootprimary または-propagate primaryのオプション修飾子を持つコマンドで 起動します。
マルチサイトレプリケーションをサポートするセントラル（中央）は、インスタンス名の概念です。各レプリケーションインスタンスは、1から15文字までの英数字が可能な名前でユニークに識別されます。この名前は、そのインスタンスのレプリケーションインスタンスファイルに格納されます。各サイトは1つだけレプリケーションインスタンスファイルを持つので、インスタンス名はマルチサイト構成ですべてのサイトをユニークに識別します。
| |
インスタンス名は固有でなければなりませんし、同じ名前を持つ2つのインスタンスがあってはなりません。 |
| |
セカンダリおよび/またはプライマリのすべてに対応しているレプリケーションインスタンスファイルは、インスタンス名のレコードを保持しているインスタンスへ接続しているので、一度インスタンスがプライマリ（rootまたは伝搬している）またはセカンダリのどちらか一方の役割が与えられたならば、インスタンス名は変更できません。 |
それらはプライマリインスタンス上で実行中の複数のソースサーバ（アクティブなセカンダリ当たりに1個）になることができるので、ソースサーバのコマンドは、特定のソースサーバを識別するためのセカンダリインスタンス名を指定する必要があります。
以前に示されていたように、GT.M V5.1-000上で実行しているセカンダリは、GT.Mの以前のバージョンで実行しているプライマリをサポートされていて、そして、その逆も同様です。これらはローリングアップグレードで起こります。プライマリとセカンダリの両方がGT.M V5.1-000にアップグレードされた後にのみ、複数のセカンダリインスタンスが可能になります。同様に、プライマリとセカンダリの両方ともがGT.M V5.1-000へアップグレードされている後にのみ、ターシャリ（第3番目）はセカンダリから可能になります。
| |
既存のデュアルサイト構成で両方のサイトがGT.M V5.1-000へアップグレードされる時にのみ、マルチサイトレプリケーションの追加機能が利用可能となります。 |
マルチサイトとデュアルサイト構成の両方で、V5.1-000のユーザーインターフェイスへの変更が適用します（例えば、もしインスタンス名がコマンドで必要とされるならば、デュアルサイト構成で操作している時はいつでもそれが必要です）。
UNIX上でデュアルサイトまたはマルチサイトのモードでレプリケーションを使用するためには、新しいレプリケーションインスタンスファイルを作成する必要があります。もしGT.Mの以前のバージョンからレプリケーションインスタンスファイルを使用する場合、 REPLINSTFMT エラーが発生します。もしインスタンスファイルが存在せずにレプリケーションを試みるならば、 FILENOTFND エラーが発生します。
インスタンスファイルを作成する時に与えられる名前は、ユニークなインスタンスを識別し、レプリケーションインスタンスファイルに格納されます。
インスタンスファイルは、他のインスタンスからローカルに生成されるかまたは受信されるジャーナルシーケンス番号の履歴のリポジトリとして提供します。履歴はレコードのセットとしてメンテナンスされます。すべてのレコードは、ジャーナルシーケンス番号の範囲と、それらジャーナルレコードを生成したルートプライマリインスタンスの名前を、識別します。最初の履歴レコードは、インスタンスの現在のジャーナルシーケンス番号で開始します。プライマリとセカンダリのルートが通信する時には、プライマリインスタンス名は、送信されるジャーナルシーケンス番号が生成されたそのインスタンとして、プライマリとセカンダリの両方のレプリケーションインスタンスファイルに記録されます。ターシャリ（第3番目）がセカンダリへ接続する時には、実際にレコードを生成したインスタンスがあるという理由で、ターシャリインスタンスファイルへの記録を取得するそのルートプライマリインスタンス名はまだ存在します（伝搬プライマリとして提供するそのセカンダリがない）。更新が mupip journal –rollbackの一部としてデータベースからロールバックされる時には、履歴レコードは常にインスタンスファイルの末尾に追加されますが、インスタンスファイルの末尾から削除されたレコードだけは例外です。
プライマリおよびセカンダリ（またはセカンダリとターシャリ）が接続を試みる時に、両方のインスタンスが同期することを通じてジャーナルシーケンス番号を確定するために、この履歴は非常に重要です。このジャーナルシーケンス番号は、両方のインスタンスファイルの履歴に戻ることによって、そして、同じルートプライマリインスタンスによって生成された一番最初の共有ジャーナルシーケンス番号を見つけることによって、確定されます。もし上記の決定された共有ジャーナルシーケンス番号がセカンダリインスタンスの現在のジャーナルシーケンス番号に一致する場合のみ、セカンダリ上の受信サーバーは通常のレプリケーションを継続します。それ以外の場合、 mupip journal –rollback –fetchresync は、追いつくためにそれを可能にする更新を送信することができるプライマリから、共通の同期ポイントへ、セカンダリにロールバックするために、セカンダリ上で実行する必要があります。同期していない(out-of-sync)状況が起こりそうなことを回避するには、それを推奨し、たとえそれが厳密には必要性がなくても安全なので、したがって、セカンダリインスタンス上の任意のソースサーバーを開始する前にmupip journal -rollback -fetchresyncを実行するために無条件にスクリプトを作成できます。
ソースサーバー、受信サーバーなどを処理してください、そしてmupip rollback がこの履歴をアクセスします。もしそれらが、インスタンスファイルに記録される最初のシーケンス番号より少ないシーケンス番号（例えば-rollback操作の一部として）に対応する履歴の記録をルックアップしようとするならば、 REPLINSTNOHIST エラーメッセージが生成されます。
レプリケーションインスタンスファイルは、インスタンスの現在の状態を保持し、バックアップでデータベースファイルのスナップショットと一致するこのバックアップを取ることが必要です。Mupip journal -backupは、データベースファイルのバックアップと同時に、インスタンスのバックアップを可能にします。
プライマリ上のレプリケーションインスタンスファイルは、開始されるソースサーバーによってそれぞれのセカンダリに関係する情報と、そのセカンダリへ最後に送信されたジャーナルシーケンス番号を、蓄積します。GT.Mの以前のバージョンでは、このジャーナルシーケンス番号は、レプリケートされたすべての領域のデータベースファイルヘッダの中でResync Seqnoとして保持され、そして、dse dump -fileheaderは、この情報を表示しました。GT.M V5.1-000では、この情報はレプリケーションのインスタンスファイルでのみ利用でき、そして、 mupip replic –source –showbacklogコマンドは、セカンダリインスタンスのためのバックログを表示するこの情報を使用します。
インスタンスファイルは、最大16セカンダリインスタンスに関係する情報を保管するための16スロットあります。当初は、すべてのスロットは使用されません。最初にセカンダリへ複製するソースサーバーは、そのセカンダリに関連する情報を格納するために未使用のスロットを利用し、そして、同じセカンダリへ複製を処理するいくつかの将来のソースサーバーは、この情報を更新するでしょう。
もし未使用のスロットも利用がないならば、ソースサーバーが開始する最初に、最近もっとも開始されていないセカンダリのスロットが再利用され、セカンダリのためのソースサーバーが生きていないことはもちろん事実で、そして、そのスロットで以前に保管されていた情報は上書きされます。先取りセカンダリインスタンスの上でいくつかの引き続くmupip replic –sourceは、 REPLINSTSECNONE メッセージを生成します。
| |
もしプライマリがそのライフタイムの間ずっと16以上の異なるセカンダリへ接続していないならば、スロットの先取りは問題はありません。 |
もしレプリケーションインスタンスファイルが破損されまたは削除されたならば、新しいインスタンスファイルが作成すべきです、そして、すべての下流のセカンダリはバックアップから再作成すべきです。
レプリケーションインスタンスファイルがコマンドラインで -name 修飾子を使って作成されている時には、インスタンス名を指定する必要があります。
nameは他のインスタンスへのレプリケーションインスタンスを識別し、それは不変です。
| |
このまれなインスタンスでは、以前のバージョンからのGT.Mコマンドは、GT.M V5.1-000と上位互換はありません。 |
もし -nameが指定されていない場合は、mupipは、名前の環境変数 gtm_repl_instname を使用します。もしその変数が定義されていない場合、コマンドは、REPLINSTNMUNDEFエラーメッセージを発行します。環境変数を使用することは、既存ユーザのレプリケーションスクリプトは変更なしで実行できます。明示的に指定されたスクリプトの修飾子は、明瞭さを改善します。
名前は1〜15文字です。15文字以上の長い名前または空の文字列の指定は、 REPLINSTNMLEN</ s0>エラーメッセージを発行します。
もしインスタンスのファイルがすでに存在する場合、それがタイムスタンプ接尾辞にリネームされ、新しいものが作成されます。この動作は、新しいジャーナルファイルの作成中に、GT.Mが既存のジャーナルファイルをリネームする方法と似ています。
インスタンスファイルの作成は、スタンドアロンのアクセスが必要です。そのインスタンスのファイルを作成(再作成)が試みている間に、もし インスタンスのファイルが使用されている場合（すなわち、そのインスタンスのためのジャーナルプールが存在）、 REPLINSTSTNDALN メッセージは発行されます。
プライマリインスタンス上で、ソースサーバプロセスは、各セカンダリインスタンスに対して実行されます。 -instsecondary修飾子は、ソースサーバがデータをレプリケートするためのセカンダリインスタンスを識別します。GT.M V5.1-000で、次のコマンドは、 -instsecondary修飾子を含むように変更されています。それは、これらのコマンドを発行しながら、-instsecondary 修飾子を指定することが必須です。
mupip replic –source –start mupip replic –source –deactivate mupip replic –source –activate mupip replic –source –stopsourcefilter mupip replic –source –changelog mupip replic –source –statslog mupip replic -source -needrestart
もし -instsecondary修飾子が指定されていない場合、mupipは、セカンダリインスタンスの名前のために環境変数 gtm_repl_instsecondary を使用します。もしその変数が定義されていない場合、 REPLINSTSECUNDFエラーが発行されます。
| |
このまれなインスタンスでは、以前のバージョンからのGT.Mコマンドは、GT.M V5.1-000と上位互換はありません。 |
15文字以上の長い名前または空の文字列の指定は、 REPLINSTNMLENエラーメッセージを発行します。
次のソースサーバのコマンドは、現在、オプションの修飾語として、 -instsecondary修飾子を可能にします。
mupip replic –source –checkhealth mupip replic –source –showbacklog mupip replic –source –shutdown
もし -instsecondaryが上記のコマンドで指定されていない場合、または、もし環境変数 gtm_repl_instsecondaryが定義されていない場合は、コマンドは、すべての現在のアクティブとパッシブのソースサーバ上で動作します。
パッシブソースサーバーの起動の間でさえも、セカンダリインスタンス名は、明示的に（修飾子を介して）、または、暗黙的（環境変数を介して）に指定する必要があります。それは、パッシブソースサーバがアクティブになった時に、パッシブソースサーバが遅れて接続するであろうこのセカンダリインスタンスの名前です。
もしセカンダリインスタンスに名前がない場合、たとえば、もしセカンダリインスタンスがGT.Mの古いバージョンを実行している場合、ダミーの名前で十分です。
-start コマンドを除く上記のソースサーバコマンドは、レプリケーションインスタンスファイル内の指定されたセカンダリインスタンスに対応する既存のスロットを探します。もし何も検出されない場合、 REPLINSTSECNONEエラーが発行されます。 -startの場合、GT.Mは、そのセカンダリインスタンスに対して以前に使用されていたスロットを探します。これには失敗し、それは空のスロットを検索し、もし使用可能でない場合、それは最近最も使われていないセカンダリインスタンスからスロットを引き継ぎます。もし16個のソースサーバがすでに存在する場合、開いているスロットはなくなり、SRCSRVTOOMANYエラーが発行されます。もし名前が接続の上でレシーバサーバによって送信された名前と一致しない場合、REPLINSTSECMTCHエラーが発行されます。
環境変数を定義することは、既存ユーザのレプリケーションスクリプトは変更なしで実行できます。明示的に指定されたスクリプトの修飾子は、明瞭さを改善します。
次のソースサーバのコマンドは、現在、–rootprimary と –propagateprimary 修飾子をサポートします：
mupip replic –source –start –secondary=... mupip replic –source –activate mupip replic –source –start –passive mupip replic –source –deactivate
これらは、オプションの修飾子です。もし指定がない場合、 -propagateprimary のデフォルト値はdeactivate コマンド(非アクティブ)と同様にパッシブソースサーバの起動コマンドのために使用され、そして、 -rootprimaryのデフォルト値は他の二つのコマンドのために使用されます。これらのデフォルト値は、もしあれば、それらのレプリケーションスクリプトに、最小限の変更を行うために、1つのプライマリと複数のセカンダリ（ターシャリ(3番目)なしで）に自分自身を制限するように計画しているユーザを有効にします。しかし、これらの修飾子は、わかりやすくするために、スクリプトで明示的に指定することを推奨します。
-rootprimaryや -propagateprimary修飾子は、相互に排他的です。
- rootprimary の指定は、明示的または暗黙的のどちらかで、指定されたレプリケーションインスタンス上でGT.Mアップデートを有効にします。
–propagateprimary の指定は、明示的または暗黙的に、レプリケーションインスタンス上でGT.Mアップデートが無効にします。複製された領域を更新するためにGT.Mプロセスによる試みは、SCNDDBNOUPDエラーを発行します。
GT.M V5.1-000は、mupip replic –source コマンドの中で–update修飾子をサポートしません。以前のGT.Mのバージョンでは、–activateでアップデートが有効になっていた間に、mupip replic –source –deactivate でアップデートが無効になりました。GT.M V5.1-000では、 -rootprimary と -propagateprimaryは、アップデートが有効か無効かどうかを制御します。
| |
レプリケートされた領域へのGT.Mの更新は、ルートプライマリインスタンスだけが許可されていて、その他のすべてのインスタンス（セカンダリ、ターシャリなどを含む）上では無効にされています。 |
| |
このまれなインスタンスでは、以前のバージョンからのGT.Mコマンドは、GT.M V5.1-000と上位互換はありません。 |
もし -rootprimary が明示的または暗黙的のどちらかで指定され、ジャーナルプールが既に存在し無効のアップデートを持っている場合（つまり、ジャーナルプールが、明示的または暗黙的に指定された- propagateprimaryをソースサーバの起動コマンドによって作成された）、 PRIMARYNOTROOTエラーが発行されます。ジャーナルプールを停止しないで伝搬プライマリインスタンスをルートのプライマリインスタンスへ遷移するために、既に実行しているパッシブソースサーバにmupip replic -source -activate -rootprimary を発行します（もし実行していない場合、 - propagateprimaryで1つをスタート）。
もし–propagateprimary が明示的または暗黙的のどちらかで指定され、ジャーナルプールが既に存在し有効なアップデートを持っている場合（つまり、ジャーナルプールが、明示的または暗黙的に指定された–rootprimaryをソースサーバの起動コマンドによって作成された）、 PRIMARYNOTROOTエラーが発行されます。ジャーナルプールを停止することなく、ルートプライマリインスタンスを伝搬プライマリインスタンスへ移行することは不可能です。
もしソースサーバの起動が発行された時にジャーナルプールが既に存在する場合は、GT.Mの以前のバージョンは “Source Server already exists”エラーメッセージを発行します。GT.M V5.1-000で、複数のソースサーバは、それらのそれぞれが -instsecondary修飾子によって異なった名前を指定する限りは、同じレプリケーションインスタンスから開始することができます。もしソースサーバが、プライマリインスタンス名と一致するセカンダリインスタンス名で開始されている場合、REPLINSTNMSAMEエラーメッセージが発行されます。もしソースサーバが、既にアップし動作している対応するソースサーバを持つセカンダリインスタンス名で開始されている場合は、SRCSRVEXISTSエラーメッセージが発行されます。
ルートのプライマリまたは伝搬プライマリインスタンス上で、複数のソースサーバは、デュアルサイトのセカンダリへ活発に接続された1つのソースサーバが存在する限り、開始することはできません（すなわち、マルチサイト機能をサポートしていないGT.Mのバージョン上でセカンダリを動作すること）。REPLUPGRADESECエラーの結果を実行しよう試みます。もしインスタンス上のアクティブなソースサーバが、同時にそのインスタンス上で動作する1つ以上のソースサーバ（アクティブまたはパッシブ）を検出する場合は、それはデュアルサイトのセカンダリに接続し、それはREPLUPGRADESECエラーを発行します。
伝搬プライマリインスタンス上で、ターシャリ(3番目)のデュアルサイトに接続するソースサーバは、REPLUPGRADESECエラーを発行します。さらに、もしレシーバサーバがデュアルサイトのプライマリに活発に接続されている場合は、アクティブなソースサーバの開始や伝搬プライマリでパッシブソースサーバを活発にすることは、REPLUPGRADEPRIエラーを発行します。
インスタンス内で、最大16のアクティブおよび/またはパッシブなソースサーバは、任意の時点で許容されます。もし16個のソースサーバがすでに実行され、別のソースサーバの起動が試行される場合は、それはSRCSRVTOOMANYエラーメッセージを発行します。
ルートになるプライマリからセカンダリへインスタンスに遷移するには、最初に現在の（新しい）ルートプライマリインスタンスのセカンダリとしてバックアップに導く必要があります。ロストトランザクションファイルが作成される二次的な原因として、それを始動します。このロストトランザクションファイルは、現在のルートプライマリインスタンス上でmupip replic -source -losttncomplete コマンドの実行に続き、現在のルートプライマリインスタンスに適用する必要があります（この間別の場所で説明したように、旧ルートプライマリは現ルートプライマリへセカンダリとして実行する必要があるか、または、mupip replic -source -losttncomplete>コマンドは旧ルートプライマリ上で別々に実行する必要があるかの、どちらかです）。いったん mupip replic -source -losttncompleteコマンドが実行されると、旧ルートプライマリインスタンスは、いくつかの伝搬プライマリのセカンダリとして立ち上げることができます。それらが最初にお互いに通信する時には、mupip replic -source -losttncompleteコマンドより優先して伝搬プライマリインスタンスのセカンダリとして、旧ルートプライマリをアップさせる試みは、レシーバサーバとソースサーバ（セカンダリとプライマリのインスタンス上でそれぞれ実行）がPRIMARYNOTROOTエラーを発行する原因となります。
| |
一旦 mupip replic -source -losttncomplete コマンドが正常に実行されると、旧ルートのプライマリインスタンスが現ルートプライマリに接続されている場合は現在の（新しい）プライマリ上で、または、コマンドが別々に実行されている場合は現プライマリと旧プライマリの両方の上で、どちらかの上で、旧ルートのプライマリインスタンスが、いくつかの伝搬プライマリのセカンダリとして立ち上がります。 |
もしジャーナルプールに有効なアップデートがある場合（すなわちジャーナルプールが、明示的に指定されるまたは暗黙的に想定されるソースサーバの起動コマンドによって作成された - root primary ）、そのインスタンス上でのレシーバサーバの起動は、 PRIMARYISROOTエラーメッセージを発行します。
もしレシーバサーバが、マルチサイトレプリケーションをサポートしていない、それがGT.Mの以前のバージョンを実行中のプライマリに接続するその時にセカンダリインスタンス上で実行中のアクティブなソースサーバーを見つける場合、それはREPLUPGRADEPRIエラーを発行します。
もしルートになるプライマリからセカンダリへインスタンスが遷移した場合、mupip replic -source -losttncomplete コマンドがそのインスタンス上で暗黙的または明示的に実行されるまで、それが現在のルートプライマリインスタンスのセカンダリとして起動することが必要です。そうしないと、それらが最初に相互に通信する時には、レシーバサーバとソースサーバ（セカンダリとプライマリのインスタンス上でそれぞれ実行）が原因で、PRIMARYNOTROOTエラーを発行します。
効果的なGT.M V5.1-000は、レシーバサーバは、ジャーナルプールにアタッチしている追加のプロセスです。実行中のレシーバサーバをシャットダウンした後にのみ、任意のインスタンス上で実行されている最後のソースサーバをシャットダウンする必要があることを意味します。そうでなければ、プロセスがそれにまだアタッチされているので、ジャーナルプールの共有メモリが削除されていないことを示しているソースサーバのログに、メッセージは記録されます。
もしソースサーバが、アクティブ化コマンド（新しい -instsecondary修飾子）で指定されたセカンダリインスタンス名を実行していない場合は、SRCSRVNOTEXISTエラーが発行されます。
パッシブソースサーバがすでに稼働していると仮定すると、4つのケースがあります：
もし -rootprimaryが明示的または暗黙的に指定されていて、ジャーナルプールが有効なアップデートを持つ場合は、このコマンドは、差し迫った活性化と正常リターンを記録をするジャーナルプールにフラグをセットします。このフラグは、後でアクティブなソースサーバであるための遷移で、同時に実行されているパッシブソースサーバによって、数秒以内に検出されます。
もし -rootprimaryが明示的または暗黙的に指定されていて、ジャーナルプールがアップデートを無効にしている場合に、正規の単一のパッシブソースサーバ以外のジャーナルプールにアタッチされているすべてのプロセスが存在するならば、このコマンドがチェックします。もしyesの場合、JNLPOOLACTIVATEエラーメッセージを発行して終了します。もしそうでない場合、このコマンドは、ジャーナルプールでアップデートを可能にし、インスタンスがこれからはルートプライマリであることを示すためにレプリケーションのインスタンスファイルを更新し、差し迫ったソースサーバの活性化と正常リターンを記録するジャーナルプールにフラグをセットします。このフラグは、後でアクティブなソースサーバであるための遷移で、同時に実行されているパッシブソースサーバによって、数秒以内に検出されます。
もし -propagateprimaryが明示的または暗黙的に指定され、ジャーナルのプールが有効なアップデートを持つ場合は、このコマンドはPRIMARYISROOTエラーメッセージを発行します。
もし -propagateprimaryが明示的または暗黙的に指定され、ジャーナルプールが無効にアップデートされる場合、このコマンドは、差し迫った活性化と正常リターンを記録するジャーナルプールにフラグをセットします。このフラグは、後でアクティブなソースサーバであるための遷移で、同時に実行されているパッシブソースサーバによって、数秒以内に検出されます。
もしソースサーバが、アクティブ化コマンド（新しい -instsecondary修飾子）で指定されたセカンダリインスタンス名を実行していない場合は、SRCSRVNOTEXISTエラーが発行されます。
アクティブソースサーバがすでに稼働していると仮定すると、4つのケースがあります：
もし -rootprimaryが明示的または暗黙的に指定されていて、ジャーナルプールが有効なアップデートを持つ場合は、このコマンドは、差し迫った非活性化(deactivation)と正常リターンを記録をするジャーナルプールにフラグをセットします。このフラグは、後にパッシブ(受動)なソースサーバであるための遷移で、同時に実行されているアクティブソースサーバによって、数秒以内に検出されます。
もし -rootprimaryが明示的または暗黙的に指定されていて、ジャーナルのプールが無効なアップデートがある場合は、このコマンドはPRIMARYNOTROOTエラーメッセージを発行します。
もし -propagateprimaryが明示的または暗黙的に指定され、ジャーナルのプールが有効なアップデートを持つ場合は、このコマンドはPRIMARYISROOTエラーメッセージを発行します。
もし -propagateprimaryが明示的または暗黙的に指定され、ジャーナルプールが無効にアップデートされる場合、このコマンドは、差し迫った非活性化(deactivation)と正常リターンを記録するジャーナルプールにフラグをセットします。このフラグは、後にパッシブ(受動)なソースサーバであるための遷移で、同時に実行されているアクティブソースサーバによって、数秒以内に検出されます。
区別がコンテキスト中で重要でない限り、GT.Mユーザーマニュアルでは、ルートプライマリは単にプライマリとしてと呼ばれ、そして、伝搬プライマリは単にセカンダリとして呼ばれます。いかなるセカンダリも伝搬プライマリとなることに注意してください。
プライマリとしてインスタンスを起動するには、ユーザの起動スクリプトは、以前にプライマリとしてインスタンスを起動したときと同じステップを実行します。さらに、今、複数のソースサーバを起動できます。どのようなGT.Mプロセスがアクティブ化される前に、前と同じように、ジャーナルのプールを作成するには、少なくとも1つのソースサーバが起動されていなければなりません。しかし、追加のソースサーバは、任意の時に起動ができます。
セカンダリとしてインスタンスを起動するには、ユーザの起動スクリプトは、以前にセカンダリとしてインスタンスを起動したときと同じステップを実行します。もしターシャリ(3番目)へレプリケートする場合は、さらに同様に今、1つ以上のアクティブまたはパッシブのソースサーバを起動できます。ターシャリ(3番目)があることに注意し、必要に応じて、セカンダリが起動される前か後のいつでも起動できます。セカンダリとターシャリ間のレプリケーションストリームは、両方が起動し実行し相互に接続されるときに、確立されます。
プライマリまたはセカンダリがGT.M V5.1-000にアップグレードされ、最初に立ち上がる時には、セカンダリ上でレシーバサーバの起動コマンドに、さらに -updateresync修飾子を指定する必要があります。この修飾子を指定しない場合は、レシーバサーバがREPLINSTNOHISTメッセージを出して起動時に失敗する原因です。少なくとも1つのデータベース更新がレプリケーションパイプを介して送信され更新プロセスによって処理された後にのみ、セカンダリは -updateresync修飾子なしでシャットダウンし起動します。
プライマリとして実行しているインスタンスを停止するために、インスタンス上で実行されているすべてのソースサーバ（アクティブまたはパッシブ）をシャットダウンする必要があります。最初にすべてのGT.M, mupip reorg, mupip load などジャーナルプールにアタッチできるプロセスをシャットダウンし、次にすべてのアクティブ および/またはパッシブのソースサーバをシャットダウンするために必要であることを意味します（-instsecondary 修飾子なしでmupip replic –source –shutdown -instsecondary コマンド、または、1つのmupip replic -source -shutdown コマンドをそれぞれ使用）。
そのセカンダリがプライマリ（すなわち伝搬プライマリ）としても作用している場合を除き、セカンダリとして動作しているインスタンスを停止するために、変更はありません。このような場合には、セカンダリに関連するサーバ（レシーバサーバ、アップデートプロセス、そのヘルパープロセス）がシャットダウンした後に、プライマリに関連するサーバ（すべてのアクティブおよび/またはパッシブなソースサーバ）を一つでもシャットダウンすることが必要です。セカンダリでは、アップデートが無効になっているので、ジャーナルプールにアタッチされているすべての他のGT.MまたはMUPIPプロセスは存在しないはずです（プライマリ上のみで有効）。もしデータベースは操作するが、しかしジャーナルプールへのアタッチがない mupip reorg のようなプロセスがある場合、これらのプロセスもダウン状態にする必要があり、そして、最終的にmupip rundown –reg *は、すべて停止するデータベース、ジャーナルプール、受信プールの共有メモリを確保するために実行する必要があります。
シャットダウン時に、少なくとも1つのソースサーバは - 必ずしも、もとは最初に起動した1つ - シャットダウンする最後のGT.Mプロセスである必要があり、終了時にジャーナルプールをクリーンアップします。
任意のインスタンスには、次の4つの状態遷移(state transition) のいずれかを受けることができます。
プライマリはプライマリとしてアップ(primary coming up as primary)
セカンダリはプライマリとしてアップ(secondary coming up as primary)
プライマリはセカンダリとしてアップ(primary coming up as secondary)
セカンダリはセカンダリとしてアップ(secondary coming up as secondary)
プライマリまたはセカンダリをシャットダウンするコマンドのシーケンスに変更はありません、そして、Starting up an instanceまたはShutting down an instanceで既にアウトライン化されたこれら以外のプライマリまたはセカンダリとしてそれを戻します。
いくつか注意すべきポイントは次のとおりです：
セカンダリとして起動できる前にプライマリはシャットダウンする必要があります。すなわち、プライマリ上でセカンダリへのオンザフライ(実行中)の移行をする mupip replic –source –deactivate は実行することができません。
これに反して、セカンダリがシャットダウンされることなく、プライマリとして起動ができます。それを行うには、1つは、mupip replic –receiv –shut （プロセスとヘルパープロセスを更新し、レシーバサーバをシャットダウン）を発行する必要があり、次に、パッシブソースサーバーをアクティブにするmupip replic –source –activate –secondary= コマンドを発行します。
もしアクティブなソースサーバがアップデートを伝搬している場合、それをパッシブにするため非アクティブにし、その後に -rootprimary 修飾子でアクティブにすることができます。
これはまた、ルートのプライマリ主を作ります（ -propagateprimaryフラグが使用されていないかぎりは、この場合セカンダリのまま）。セカンダリで実行されている単一のソースサーバがあり、それがパッシブなサーバである場合のみ、これが動作することに注意してください。もし存在しない場合は、1つのパッシブソースサーバを除いて、すべてのアクティブソースサーバとすべてのパッシブソースサーバは、アクティブ化される前に停止する必要があります。
それが以前にセカンダリまたはプライマリであったかどうかに関係なく、セカンダリとしてアップする任意のインスタンスは、 現在のプライマリでmupip journal –rollback –fetchresyncを実行する必要があります。これを行わないと、レシーバサーバの起動時に、エラー（プライマリ等より先にセカンダリ）を引き起こす可能性があります。
GT.M V5.1-000で、データベース / ジャーナルがプライマリと同期をとっていない(get out-of-sync)ときに、セカンダリをリカバリするために使用される手続きにマイナーな変更があります。
セカンダリをリカバリする手順は、プライマリデータベースのオンラインバックアップをとり、セカンダリへそれを送り、セカンダリ上でフレッシュなジャーナルを作成し、セカンダリで -updateresync修飾子を使ってレシーバサーバを起動します。GT.M V5.1-000で、追加のステップは、以前のように、同じ名前でレプリケーションインスタンスファイル（一度にフレッシュなジャーナルが作成される）を再作成することです。また、バックアップソースの選択には多くのチョイスがあります。一つは、ルートプライマリまたは別のセカンダリのいずれかからオンラインバックアップを取ることができます。
オプションで、新しいインスタンスが追いつくためにある必要なことからプライマリ上のネットワーク帯域幅とシステム負荷を軽減するためには、mupip journal -recover -forwardコマンドは、セカンダリとして新しいインスタンスを起動する前に、バックアップへプライマリの後で作成されたジャーナルファイルからアップデートを適用するために使用されました。この手順が変更されます。
バックアップからセカンダリインスタンスを起動するための新しい手順を以下に示します：
（プライマリまたは別のセカンダリインスタンスから）バックアップをリストアします。複数の領域(マルチリージョン)のデータベースのイベントで、バックアップはすべての領域にわたって一貫でなければならないことに注意してください。
オプションで、mupip journal -recover -forward コマンドを使って、ジャーナルファイル（データベースバックアップを取り込んだ場所と同じインスタンスから）を適用します。各データベース領域に対して複数のジャーナルファイルが存在することができます。それぞれの領域では、最新のジャーナルファイル上でmupip journal -show=header -forwardを実行し、そして、表示されたEnd Region Sequence Number(最終領域のシーケンス番号) の最大値に注意してメモしてください。注意してメモしておいた数値と等しくなるように領域のシーケンス番号をセットするために、対応する領域でdse change -file -reg_seqno コマンドを使用してください。インスタンス内のすべてのレプリケートされた領域に対して同じことを行います。
レストアされたデータベース領域用に新しいジャーナルファイルを作成します。
セカンダリインスタンス上の以前のインスタンスファイルと同じ名前で、新しいインスタンスファイルを作成します。
-updateresync修飾子で、レシーバサーバを起動します。
セカンダリが始動されるたびに、mupip journal -rollback -fetchresync コマンドは現在、常に必要です。 A が B とC にレプリケートする場合を考えてみます； B は D へレプリケートし、C は E へレプリケートします。B が新しいプライマリになるにはフェイルオーバーの後に、B へセカンダリとしてアップする前に、C は -fetchresync修飾子を使用する必要があります。 D は正常に動作し続けます。イベントCの -fetchresyncでは、いくつかのトランザクションをロールバックするためにそれが必要で、E（と、そのルートとして C を持つツリーの一部にある他のインスタンス）もまた、それが再びバックアップ状態になる前に、停止することと mupip journal -rollback -fetchresync を実行することが必要です。オリジナルのプライマリ A が（Bへの）新しいセカンダリになる時、それがセカンダリになる前に、mupip journal -rollback -fetchresync を最初に実行する必要があります。これらmupip journal -rollback -fetchresync コマンドは、潜在的に、それぞれのセカンダリにロストトランザクションファイルを生成しますが、しかし、Bに適用する必要があるたった1つは、オリジナルのプライマリ A からのロストトランザクションファイルです。ロストトランザクションファイルのフォーマットは、ファイルが再処理のために新しいプライマリへ送信する必要があるかどうかを簡単に区別できるようにそれゆえに変更されています。
ロストトランザクションファイルの最初の行にある新しいフィールドは、適用されることが必要とされるロストトランザクションファイルを、識別します。以前は、最初の行は、最初で唯一のフィールドとしてファイルのフォーマットを特色にしていました、そして、それはGDSJEXnn形式の文字列でした、ここでの nn はロストトランザクションファイルの存在するフォーマットでした。
現在のバージョンは、最初の行に複数のフィールドを備えています。これらは次のとおりです。
最初のフィールドはファイル形式のバージョンを意味するGDSJEX03が表示されます。
2番目のフィールドは、ロストトランザクションファイルを作成した、ロールバックかリカバリがあるかどうかを示します。
もし2番目のフィールドがロールバックの場合は、3番目のフィールドは、ロストトランザクションファイルの直前に、インスタンスがプライマリまたはセカンダリであったかどうかを示します。もしそれがプライマリだった場合、ロストトランザクションファイルは、プライマリのロストトランザクションファイルと呼ばれ、それは新しいプライマリに適用される必要があります。4番目のフィールドは、ロストトランザクションが生成された上でレプリケーションインスタンスの名前を保持します。ロストトランザクションが新しいプライマリに適用される時に、このインスタンス名は mupip replic -source -needrestartコマンドにある-instsecondary 修飾子として使用されるべきです。
バックログがゼロの時のフェイルオーバーの後を除いて、旧プライマリを新セカンダリとしてアップするたびに、ロストトランザクションファイルは存在します。ロストトランザクションファイルが処理される前に、他のフェイルオーバーのイベントで追加のロストトランザクションファイルがあるかもしれない、例えば新プライマリの障害によって引き起こされる、として、このロストトランザクションファイルは、実用としてすぐに新プライマリで適用する必要があります。これらの追加のロストトランザクションファイルは、ロストトランザクションの処理に必要なロジックを複雑にします。
ロストトランザクションは、Mの組み込み関数$ZQGBLMOD() を使用して手動または半自動化の方法のどちらかで新プライマリに適用することができます。もし$ZQGBLMOD() を使用する場合、2つの追加手順（mupip replicate -source -needrestart と mupip replicate -source -losttncomplete 6>）は、レプリケーションがデュアルサイトまたはマルチサイトモードに設定されているかどうかに関係なく、ロストトランザクション処理の一部として実行されるべきである。これらの手順を実行するための障害は、順番がアプリケーションデータ整合性の問題を生じさせる false negatives(偽陰性)を返す$ZQGBLMOD() の原因となります。
mupip replic –source –needrestartコマンドは、適用する必要がある各ロストトランザクションファイルに対して一度は呼び出されるべきです。そのファイルからロストトランザクションを適用する前に、新プライマリで呼び出すべきです。 -instsecondary修飾子は、このロストトランザクションファイルが生成された場所のセカンダリインスタンスの名前を提供するために、このコマンドで指定する必要があります。もしない場合、環境変数gtm_repl_instsecondaryは、暗黙的にセカンダリインスタンスの名前を保持することを仮定されます。もしそのどちらかが定義されていない場合は、 REPLINSTSECUNDFエラーが発行されます。
mupip replic –source –needrestart –instsecondary=...
このコマンドの目的は、プライマリがアップしてから、プライマリが指定されたセカンダリインスタンス（もしレシーバサーバまたはセカンダリインスタンス上のfetchresyncロールバックが、ソースサーバと通信していた場合）といつも通信するかどうかを、チェックすることです。その場合、このコマンドは、セカンダリインスタンスがプライマリと通信していたことを示す SECONDARY INSTANCE xxxx DOES NOT NEED TO BE RESTARTED メッセージが表示され、それ故に再起動する必要はありません。もしそうでない場合、このコマンドはSECONDARY INSTANCE xxxx NEEDS TO BE RESTARTED FIRSTメッセージが表示されます。この場合、指定されたレプリケーションインスタンスは、このファイルからロストトランザクションを適用する前に、セカンダリとして起動する必要があります。対応するロストトランザクションを適用する前に、これを怠ると、前述したようにアプリケーションデータの不整合が生じさせる false negatives(偽陰性) を返す$ZQGBLMOD()の原因となります。
結果的にロストトランザクションファイルは、それが適用されるために、同じインスタンスから生成されました、もしREPLINSTNMSAMEエラーを生じさせる試みの場合は、mupip replicate -source -needrestartコマンドは不要です。
現在のプライマリに隣接するセカンダリとして起動すべきセカンダリインスタンス（ -needrestartコマンドで指定）が必要です。もし現プライマリへ（異なる中間セカンダリインスタンスを介して）ターシャリ(第3次)として起動される場合、 -needrestart コマンドは、ターシャリが起動して動作しているにもかかわらず、プライマリと通信がないものとして、無条件にターシャリ(第3次)インスタンスとみなします。
| |
プライマリおよび/またはレシーバのサーバ上のソースサーバ、または、特定のセカンダリが必要とするこの上での fetchresync ロールバックは、このコマンドの実行時には、起動と実行はしません。しかし、プライマリインスタンスが始動した後に、ある時点でアップした場合に、それは十分です。 |
このコマンドは、ロストトランザクションファイルが生成される時に、プライマリインスタンスが、ロストトランザクションを適用した時にプライマリインスタンスと異なっているケースから再び保護します（デュアルサイト構成のケースでは異なることがけっしてないにもかかわらず、このコマンドの使用がそれにもかかわらず依然として必要なことに注意してください）。
$ZQGBLMOD() は、適切に設定するプライマリインスタンスのデータベースファイルのヘッダー内の2つのフィールドに依存しています。GT.Mの以前のバージョンでは、Resync Transとしてこれらのフィールドのいずれかを表示します （dse dump –fileheaderコマンドを使用して）。 GT.M V5.1-000では、これは今Zqgblmod Transに変更されます。新フィールドZqgblmod SEQNO は、GT.M V5.1-000で導入され、それは、dse dump -fileheader コマンドによって表示されます。
rollback –fetchresyncが実行される時に、デュアルサイト構成では、2つのインスタンスのみに存在し、それらの両方は、セカンダリにロールバックするためにジャーナルシーケンス番号の決定に関係します。これにより、任意の追加のコマンドを必要とせずに生成されるロストトランザクションと同時にそれぞれのファイルのヘッダ内で、両方のインスタンスが同じシーケンス番号の情報（Zqgblmod SEQNOと対応するZqgblmod Transのトランザクション数）を記録できるようになります。
マルチサイト構成では、2つ以上のインスタンスが存在し、rollback –fetchresyncにプライマリとセカンダリに関わる以外のインスタンスは、シーケンス番号の決定に関係しません。したがって、ロストトランザクションファイルのその特定のが生成されている時に、それらZqgblmod Seqno （と、したがって Zqgblmod Trans）のセットは持っていません。もしいずれかの非関係インスタンスが新プライマリとして起動する場合とロストトランザクションファイルのその特定がプライマリに適用されている場合、参照点（Zqgblmod Trans）が適切に設定されていないので、$ZQGBLMOD()の戻り値は信頼できなくなります。したがって、このコマンドは、プライマリとしてアップした後に、ロストトランザクションが以前に生成されたかどうかについて、セカンダリインスタンスが、現プライマリインスタンスと通信しているかどうかをチェックします。もしそれが肯定である場合、 Zqgblmod Seqno と Zqgblmod Transフィールドを適切に設定されていたし、それゆえに、$ZQGBLMOD() の値が正しいことを意味します。
-needrestart修飾子は、- instsecondaryを除くすべてのソースサーバの修飾子と互換性がありません。
プライマリとしてダウンした状態とセカンダリとしてアップした状態のすべてのセカンダリからロストトランザクションファイルが、いったん、新しいプライマリに適用されていると、次のコマンドは、$ZQGBLMOD()を使用してロストトランザクション処理が完了する事実を記録するために、新プライマリで実行する必要があります。
mupip replic –source –losttncomplete
このコマンドは、値0にグローバルディレクトリ内のすべての領域のデータベースファイルのヘッダー内のZqgblmod Seqno と Zqgblmod Trans フィールド（dse dump –fileheaderコマンドで表示される）を更新します。そうすることで、次のロストトランザクションファイルが作成されるまで、無条件に一つの安全な値を返すために、その後の$ZQGBLMOD()を引き起こします。
このコマンドは、理想的にはセカンダリインスタンスのそれぞれの上で実行する必要があります。
しかし、以下次の条件に該当する場合、同じ効果が暗黙のうちに達成されるので、コマンドは明示的に実行する必要はありません：
セカンダリは、コマンドをプライマリで実行する時には既にプライマリに接続されています。
セカンダリは、コマンドを実行する時には接続されていません。しかし、プライマリがコマンドの実行後にダウンされる前に、最終的にプライマリに接続します。
コマンドは、将来のロストトランザクションを適用する時に false positives(偽陽性)を返すことから、そのインスタンス上で未来の$ZQGBLMOD()を防ぐために明示的または暗黙的のどちらかで、インスタンス上で実行する必要があります。これは、未来の $ZQGBLMOD()の正確性を確実にします。
そのインスタンスがターシャリ(第3次)のように起動する前に、旧プライマリインスタンス上で、明示的または暗黙的に、mupip replic -source -losttncomplete コマンドの実行が必要とされます； そうでなければ、Zqgblmod Seqnoが非ゼロのままで、そして、伝搬プライマリソースサーバに対抗してそのインスタンス上でレシーバサーバの起動時に、発行されるPRIMARYNOTROOTエラーを生じる原因となる可能性があります。
-losttncomplete修飾子は、他のすべてのmupip replicate -source修飾子と互換性がありません。
このコマンドは、レプリケーションインスタンスファイルの内容を表示または編集するために使用されます。インスタンスファイル名は、このコマンドの最後のパラメータとして指定する必要があります。インスタンスファイル名を指定しないと、発行されるMUPCLIERRエラーの原因を引き起こします。インスタンスのファイルを編集するとインスタンスのファイルへのスタンドアロンのアクセスを必要としませんが、同時並行プロセスがそれから / へ (from/to)読み込み/書き込み(reading/writing) している時には出来る限り避けるべきです。
このコマンドは、もしインスタンスファイルが見つからなければ、FILENOTFNDエラーを発行し、そして、もしレプリケーションインスタンスのファイルが以前のV5.1-000のGT.Mのバージョンで作成されている場合は、REPLINSTFMTエラーメッセージを発行します。
-editinstance修飾子は、他のmupip replic修飾子と互換性がありません、すなわち、-receiver, -source, -updateproc, -updhelper, or -instance_create。インスタンスファイルの内容を表示するために... -show 修飾子使用してください。すなわち、 -receiver, -source, -updateproc, -updhelper, or -instance_create。このコマンドは、次の各セクションが表示されます。
ファイル ヘッダ
ソース サーバ のスロット
履歴レコード
もしオプションの-detail修飾子が追加で指定される場合、各セクション内のすべてのフィールドは、そのファイルの先頭と各フィールドサイズからのそれらのオフセットとともに表示されます。これは、インスタンスのファイルを編集する必要がある場合に使用されます。任意の表示フィールドを編集するには、 -change修飾子を使用してください。さらに、一つは-offset修飾子を使用して変更するオフセットを指定し、-size修飾子を使用して変更のサイズを指定し、-value修飾子で新しい値を指定します。
効果的な編集を行うための完全なコマンドは、 mupip replic –edit –change –offset= -size= -value= <instance-file> です。
-size修飾子は、変更すべきバイト数を示す 1、2、4、8 のどれかです。他の値を指定すると、 SIZENOTVALID8エラーが発行される原因になります。
-offset修飾子は、サイズ修飾子の複数の16進数値をとり、そうでない場合、適切なエラーメッセージが発行されます。同様に、もし指定されたオフセットがインスタンスファイルのサイズより大きい場合、適切なエラーメッセージが発行されます。
-value修飾子は、指定されたオフセットで新しい16進値を指定します。 -value修飾子を指定しない場合は、指定されたオフセットで現在の値が表示され、変更は実行しません。 -valueの指定は、変更を行い、そして、古い値と新しい値の両方を表示します。
-detail修飾子は–changeと互換性はありません。-change または -showの一つだけは、単一のコマンド行で指定することができます。 -offset, -sizeや -value修飾子は、 -changeだけと互換性があります。
| |
インスタンスファイルは、FISのGT.Mサポートからの指示があったときにのみ、編集すべきです。 |
mupip replic -source -jnlpool コマンドは、ジャーナルプールのコンテンツを表示し編集する１つを可能にします。 -show修飾子は、ジャーナルプールの内容を表示します。オプションの修飾子 -detail は、オフセットと各フィールドのサイズを表示します。
Mupip replic -source -jnlpool -show –detail は、オフセットとともにジャーナルプールの内容が表示されます。
-change修飾子は、ジャーナルプールの内容を編集する1つを可能にします。追加の修飾子-offset, -size, -value は、mupip replic –edit[instance] コマンドのように実際の変更を指定します。
-detail修飾子は–changeと互換性はありません。-change または -showの一つだけは、単一のコマンド行で指定することができます。 -offset, -sizeや -value修飾子は、 -changeだけと互換性があります。
| |
このコマンドは、FISのGT.Mサポートからの指示があったときにのみ、使うべきです。 |
以前のバージョンでは、 dse dump -fileheader は、フィールドのResync Seqnoを表示していました。これまは、プライマリとセカンダリの両方へアップするジャーナルシーケンス番号が同期化されていることを表していました。論理的なデュアルサイトで、ある時点で、そして、それゆえに、他のインスタンスだけが存在している各インスタンスの観点から、2つのインスタンスだけがそこにありました。これにより、各インスタンスのデータベースファイルヘッダー内の他のインスタンスに関しては同期ポイントを格納するために可能になりました。マルチサイトで、一定のインスタンスは、、、複数のセカンダリインスタンスのプライマリとして機能でき、各セカンダリはプライマリに対して異なるシーケンス番号を同期させることができます。この情報は、各セカンダリインスタンスに対して区別してメンテナンスされているレプリケーションインスタンスファイルへ移動されます。GT.M V5.1-000では、 dse dump -fileheader は、もはやResync Seqnoフィールドを印刷しなくなります。
GT.Mの以前のバージョンでは、 Resync Transは、Resync Seqnoと同じ行に印刷されていました。このフィールドは、GT.M V5.1-000ではZqgblmod Transと名前を付けられ、そして、それはM関数$ZQGBLMOD()のリファレンストランザクション番号として提供します。さらに、Zqgblmod Transに一致するジャーナルシーケンス番号は、Zqgblmod SeqnoとしてResync Seqnoによって以前より占有されている場所に表示されます。
このように、dse dump -fileheaderの出力の最終行は、変更されます。
Resync Seqno 0x0000000000000001 Resync Trans 0x0000000000000001
を
Zqgblmod Seqno 0x0000000000000001 Zqgblmod Trans 0x0000000000000001
DSE DUMP -FILEで説明が変更されたため、dse change -fileheaderコマンドは、-resync_seqno と -resync_tn</s5 修飾子を、もはやサポートされなくなりました。その代わりに、データベースファイルヘッダのZqgblmod Seqno と Zqgblmod Transフィールドをそれぞれに修正するために、-zqgblmod_seqno と -zqgblmod_tn をポートしています。
| |
このまれなインスタンスでは、以前のバージョンからのGT.Mコマンドは、GT.M V5.1-000と上位互換はありません。 |
もしルートになるプライマリからセカンダリへインスタンスが遷移した場合、mupip replic -source -losttncompleteコマンドが、そのインスタンス上で暗黙的または明示的に実行されるまで、それは、現在のルートプライマリインスタンスのセカンダリとして起動することが必要です。そうではなく、ターシャリ(第3番目)として起動を試みるこの旧プライマリインスタンス上で実行されるmupip journal -rollback -fetchresync コマンドによって発行されるPRIMARYNOTROOTエラーの原因になります。ロールバックが通信する伝搬プライマリインスタンス上のソースのサーバでも同じエラーを発行します。なお、一旦mupip replic -source -losttncompleteコマンドが正常にインスタンス上で実行される場合、ロールバックコマンドが、ターシャリインスタンスとしてインスタンスの起動を有効にするために実行できることに注意してください。
GT.M V5.1-000で、 mupip backupは、新しいオプションの修飾子 -replinstance=<destination-file-or-directory>を介して、レプリケーションインスタンスファイルの一貫性オンラインまたはオフラインバックアップを作る能力を持っています。
もしコピー先のディレクトリが指定されている場合、インスタンスファイルは、インスタンスファイルと同じ名前でコピー先のディレクトリにバックアップされます。この修飾子は、指定されたすべてのデータベース領域がバックアップの開始時点で得られるだけでなく、インスタンスファイルの一貫性バックアップのケースで、バックアップするデータベース領域のリストと一緒に指定することができます。この修飾子は、唯一のレプリケーションインスタンスのファイルがバックアップされているケースには、他のデータベース領域なしで指定することができます。この場合、他のmupip backup修飾子のいずれもが適用できません。
GT.Mマルチサイトバージョンのいずれかの機能を使用する前に、既存のデュアルサイト設定のプライマリとセカンダリの両方は、マルチサイトレプリケーションをサポートするGT.Mの新しいバージョンにアップグレードしておく必要があります。このGT.Mバージョンアップは、マニュアルと以下の要約で説明したように、アップグレード中にアプリケーションの連続可用性を提供する、ローリングソフトウェアのアップグレード手順を使用して行うことができます。
アップグレード前に、サイトAがプライマリである2つのサイト、サイトAとサイトBがあることを想定し、ここでは、ローリングアップグレードを実行するステップは次のとおりです。
サイトAは、正常に動作を継続します。
サイトBで：
アプリケーションプロセス、レシーバとソースサーバをシャットダウンします。
データベースを停止し、バックアップコピーを作成します。
マルチサイトレプリケーションをサポートする新しいバージョンにGT.Mをアップグレードします。
もしGT.M V4からGT.M V5へバージョンをアップグレードする場合、データベースもまた、 GT.M Database Migration Technical Bulletin (GT.Mデータベース移行技術速報)でのプロシージャを使用してアップグレードする必要があります。簡略化のため、2つのアップグレードを区別することをFISは推奨することに注意してください。
新しいGT.Mのバージョンからmupip replic -instance_createを使用して、レプリケーションインスタンスファイルを再作成してください。インスタンスファイルのフォーマットが変更されたとして、これは必須です。レプリケーションインスタンスファイルの作成時に、インスタンス名を指定する必要があることに注意してください。
サイトBでセカンダリを起動します。レシーバサーバでは、- updateresync修飾子を使って起動する必要があります。
この時点で、デュアルサイトのレプリケーションは、サイトAは、古いGT.Mデュアルサイトのバージョンを実行し、サイトBは新しいGT.Mマルチサイトのバージョンを実行し、復元されます。正しい動作を検証するために必要に応じて、このモードで動作してください。
制御されたフェールオーバーを実行してください。セカンダリをサイトAに作成し、プライマリをサイトBに作成してください。
サイトBは、新しいプライマリとして正常に動作を継続します。
サイトBをアップグレードするために使用したのと同じ手順で続いて、Aサイトをアップグレードしてください。
この時点で、デュアルサイトレプリケーションは、新しいGT.Mマルチサイトのバージョンを実行している両方のサイトで復元され、正しい動作を検証するために必要に応じてこのモードで動作してください。
制御されたフェールオーバーを実行してください。プライマリをサイトAに作成し、セカンダリをサイトBに作成してください。正しい動作を検証するために必要に応じて、このモードで動作してください。
必要に応じて、追加セカンダリやターシャリ(3番目) を追加することができます。
ACTIVATEFAIL | Failed to activate passive source server for secondary instance name xxxx. ( セカンダリインスタンス名の xxxx のために、パッシブソースサーバをアクティブすることに失敗) | |||
Severity: 重大度 | Error | |||
MUPIP Error: | パッシブソースサーバをアクティブ化しようと試み、そして、同時にルートプライマへセカンダリになる伝搬プライマリからインスタンスを切り替えることを試みるときに、このエラーは、mupip replic –source –activateによって発行されます。 rootprimary修飾子を指定していると同時に、そのインスタンス上で既にに実行されているパッシブソースサーバのアクティブ化よって、ルートプライマリへセカンダリからインスタンスを切り替えることができます。しかし、そのインスタンス上で実行している1つのパッシブソースサーバ以外のプロセスはありません。もしない場合は上記のエラーが発行されます。 | |||
Action: | そのレプリケーションインスタンス上での実行していて（ソースサーバ、レシーバサーバ、アップデートプロセス、GT.Mプロセスなど）そして、ジャーナルプールにアクセスしているパッシブソースサーバ以外のすべてのプロセスをシャットダウンしてください。次に、mupip replic –source –activateコマンドを再発行してください。 | |||
PRIMARYISROOT | Attempted operation not valid on root primary instance xxxx (ルートプライマリインスタンス xxxx で試した操作は有効ではありません) | |||
Severity: 重大度 | Error | |||
MUPIP Error: | もしレプリケーションインスタンスがルートプライマリである（ジャーナルプールがすでに存在しrootprimaryで指定されたソースサーバのコマンドによって作成された）場合に、このインスタンス上で、明示的に指定（または暗黙的に仮定される）されるpropagateprimary修飾子を持つ、start, activate または deactivate 修飾子を使ってソースサーバコマンドを発行すること、または、レシーバサーバを起動しようと試みることは、発行されるこのエラーの原因となります。 | |||
Action: | ルートプライマリインスタンス上でレシーバサーバを起動しないでください。ソースサーバのコマンドで propagateprimaryの代わりにrootprimary修飾子を使用してください。 | |||
PRIMARYNOTROOT | Attempted operation not valid on non-root primary instance xxxx ( root でないプライマリインスタンス xxxx で試した操作は有効ではありません。 | |||
Severity: 重大度 | Error | |||
MUPIP Error: | もしレプリケーションインスタンスがルートプライマリである（ジャーナルプールがすでに存在しpropagateprimaryで指定されたソースサーバのコマンドによって作成された）場合に、このインスタンス上で明示的に指定（または暗黙的に仮定される）されるrootprimary 修飾子を持つ、start または deactivate 修飾子を使ってソースサーバコマンドを発行することは、発行されるこのエラーの原因となります。もしソースサーバが実行されているインスタンスがプライマリルートではない場合、このエラーはレシーバサーバまたはmupip roolbackによって発行することもでき、そして、以前はルートプライマリであったインスタンス上でレシーバサーバまたは実行しているmupip journal -rollback -fetchresyncに接続し、そして、その上で明示的または暗黙的のどちらかで実行するmupip replic -source -losttncompleteコマンドをまだ受けていません。 | |||
Action: | ソースサーバのコマンドで rootprimaryの代わりにpropagateprimary修飾子を使用してください。もしこのエラーがレシーバサーバ または fetchresyncロールバックによって発行される場合は、セカンダリインスタンスは、それがこの直前にルートプライマリだったので、ルートプライマリのセカンダリとして起動されます。ルールは、以前にルートプライマリであったすべてのインスタンスは、新ルートプライマリのセカンダリとして起動されるべきことが規則です。これは、新ルートプライマリに適用する必要があるロストトランザクションファイルが作成されます。一旦これが行われていると、 mupip replic -source -losttncompleteコマンドは、伝搬プライマリのセカンダリとしてこれを起動しようとする前に、このインスタンス上で明示的または暗黙的のどちらかで実行する必要があります。 | |||
REPLINSTDBMATCH | Replication instance file xxxx has seqno xxxx while database has a different seqno yyyy (データベースが別の seqno yyyy を持っている間、レプリケーションインスタンスファイル xxxx がseqnoに xxxx を持っています) | |||
Severity: 重大度 | Error | |||
MUPIP Error: | もしインスタンスファイルに保存されているジャーナルシーケンス番号は、データベースファイルヘッダーに格納されているものと一致していない場合、このエラーは、レプリケーションインスタンス、または、mupip journal -rollbackコマンドの上で起動された最初のソースサーバによって発行されます。もしデータベースが、インスタンスファイルを再作成することに応じることなく、別のインスタンス上にバックアップから再作成または更新された場合、これは可能です。 | |||
Action: | もしこのインスタンスがルートプライマリではない場合、このエラーは、以前のバックアップ（同時に一緒になる一貫性のあるインスタンスファイルのバックアップとデータベースファイル）と再起動するインスタンスから、データベースおよびインスタンスの両方のファイルをリストアすることによって処理することができます。このようなリストアに続いて、最後のバックアップ以降のすべてのトランザクションは、このインスタンスのプライマリから越えて送信されます。あるいは、これは、他のインスタンス（プライマリまたは他のセカンダリ/ターシャリのいずれか）からデータベースのコピーを運び、インスタンスファイルを再作成し、 -updateresync修飾子でセカンダリとしてこのインスタンスを起動することによって、処理することができます。どちらの場合でも、この手順は、すべてのプライマリ-セカンダリインスタンスのペアに対して確実にこのインスタンスから降りてくる、すべてのターシャリインスタンスなどで反復する必要があります。セカンダリはジャーナルシーケンス番号の条件ではプライマリの前方にありません。もしこのインスタンスがルートプライマリの場合は、バックアップ後に発生したトランザクションの損失を意味する可能性があるので、以前のバックアップからリストアしても存在可能な場合があります。このエラーを処理する別の方法は、ルートプライマリ上のインスタンスファイルを再作成し、プライマリからデータベースのコピーを出荷し、すべてのセカンダリ(ターシャリーなと)上のインスタンスファイルを再作成し、 -updateresync修飾子でセカンダリを再起動します。加えて、FISのGT.Mサポートには、この発生を報告してください。 | |||
REPLINSTFMT | Format error encountered while reading replication instance file xxxx. Expected yyyy. Found zzzz. (レプリケーションインスタンスファイル xxxx を読み取り中にフォーマットエラーが発生しました)Expected yyyy. (yyyyを期待)Found zzzz. (zzzzを発見) | |||
Severity: 重大度 | Error | |||
Runtime Error: | レプリケーションインスタンスファイルを開こうとするたびに、そして、GT.Mの現バージョンが解釈できないフォーマットで作成されたことを検出するたびに、このエラーはGT.MまたはMUPIPによって発行されます。 | |||
Action: | GT.M.の現バージョンでmupip replic –instance_createコマンドを使用してインスタンスファイルを再作成してください。 | |||
| ||||
REPLINSTNMLEN | Replication instance name xxxx should be 1 to 15 characters long (レプリケーションインスタンス名 xxxx は、1〜15文字長でなければなりません) | |||
Severity: 重大度 | Error | |||
MUPIP Error: | もしインスタンス名が、name修飾子を経由するか、または、、環境変数gtm_repl_instnameを経由するかのいずれかで指定されている場合ともし名前が15文字より長いまたは空の文字列であった場合、このエラーは mupip replic instance_createコマンドによって発行されます。 | |||
Action: | 1〜15文字の長さの有効なインスタンス名を指定します。 | |||
REPLINSTNMSAME | Primary and Secondary instances have the same replication instance name xxxx (プライマリとセカンダリインスタンスは、同じレプリケーションインスタンス名 xxxxを持ちます) | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by any source server command where the -instsecondary qualifier specifies a secondary instance name that matches the name of the primary instance the command is started from. | |||
Action: | Two instances should never have the same name. Recreate the instance file on the secondary with a different name and restart the receiver server with the updateresync qualifier. | |||
REPLINSTNMUNDEF | Replication instance name not defined | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by the mupip replic -instance_create command if the -name qualifier was not specified and if the environment variable gtm_repl_instname is not defined either. | |||
Action: | Specify the instance name using the -name qualifier | |||
REPLINSTNOHIST | History record for xxxx not found in replication instance file yyyy | |||
Severity: 重大度 | Error or Warning | |||
MUPIP Error: | The source server or receiver server issue this message as an error while mupip rollback issues this message as a warning when they scan the replication instance file looking for a history record corresponding to a journal sequence number that is lesser than the earliest sequence number or greater than the latest sequence number stored in the instance file. This means that the replication instance files on the primary and secondary have differing level of history detail (possible if the instance file was later recreated in one instance) and that it is no longer possible to determine the sync point (resync seqno) between the two instances. | |||
Action: | If mupip rollback issues this error, it truncates the replication instance file history. This means that if this instance is a secondary, it should be brought up with the -updateresync qualifier. If the source or receiver server issue this error, this error needs to be handled by ensuring the primary and secondary databases are in sync (by shipping a copy of the database from the primary to the secondary if not already done), recreating the instance file on the secondary (if not already done) and start the receiver server on the secondary with the -updateresync qualifier. | |||
REPLINSTSECLEN | Secondary replication instance name xxxx should be 1 to 15 characters long | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by any mupip replic -source command that specifies a secondary instance name. This error is issued if the secondary instance name was specified either through the -instsecondary qualifier or through the environment variable gtm_repl_instsecondary and if the name was longer than 15 characters or was the empty string. | |||
Action: | Specify a valid secondary instance name that is 1 to 15 characters long. | |||
REPLINSTSECMTCH | Secondary replication instance name xxxx sent by receiver does not match yyyy specified at source server startup | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by a source server that connects to a receiver server on the secondary and finds that the secondary instance name sent by the receiver does not match the secondary instance name specified (INSTSECONDARY qualifier) when the source server was started. The source server terminates after issuing this error. | |||
Action: | Restart the source server with the correct -instsecondary qualifier value. Also make sure the instance name in the -instsecondary qualifier and the host/port information in the secondary qualifier of the source server startup command correspond to each other. | |||
REPLINSTSECNONE | No slot found for secondary instance xxxx in instance file yyyy | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by any mupip replic source command that specifies a secondary instance name (except for the one which specifies –start). There are 16 slots in the instance file to store information pertaining to 16 different secondary instances. When the secondary instance name is specified, an attempt is made to find an unused or already used slot corresponding to the specified secondary instance in the replication instance file. If such a slot is not available, this error is issued. | |||
Action: | Ensure the primary instance does not connect to more than 16 secondaries for the life of the instance file. | |||
REPLINSTSECUNDF | Secondary replication instance name not defined | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by any mupip replic -source command that requires a secondary instance name to be specified. The source server commands that require this qualifier are those that have any of -activate, changelog, deactivate, needrestart, start, statslog or stopsourcefilter specified. The secondary name can be specified either through the INSTSECONDARY qualifier or through the environment variable gtm_repl_instsecondary. If neither of them is specified, this error is issued. | |||
Action: | Specify the secondary instance name using the INSTSECONDARY qualifier. | |||
REPLINSTSEQORD | ssss has seqno xxxx which is less than last record seqno yyyy in replication instance file zzzz | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued in one of two scenarios. The instance file consists of a sequence of history records that should correspond to an increasing range of sequence numbers. They need to hence have their starting sequence number in increasing order. If an attempt is made to append a history record with a starting sequence number that is lesser than the last history record currently existing in the instance file, the source or receiver server issues this error. In this case ssss would be the string New history record. This error is also issued if at journal pool creation time, the source server notices that the instance file header has a value of the current seqno that is lesser than the starting seqno of the last history record in the instance file. In this case ssss would be the string Instance file header. | |||
Action: | もしこのインスタンスがルートプライマリではない場合、このエラーは、以前のバックアップ（同時に一緒になる一貫性のあるインスタンスファイルのバックアップとデータベースファイル）と再起動するインスタンスから、データベースおよびインスタンスの両方のファイルをリストアすることによって処理することができます。このようなリストアに続いて、最後のバックアップ以降のすべてのトランザクションは、このインスタンスのプライマリから越えて送信されます。Alternatively, this can be handled by shipping a copy of the database from any other instance (either the primary or any other secondary/tertiary), recreating the instance file and starting this instance as a secondary with the UPDATERESYNC qualifier. In either case, this procedure has to be repeated on all tertiary instances etc. that descend from this instance ensuring that for every primary-secondary instance pair, the secondary is not ahead of the primary in terms of journal seqno. もしこのインスタンスがルートプライマリの場合は、バックアップ後に発生したトランザクションの損失を意味する可能性があるので、以前のバックアップからリストアしても存在可能な場合があります。The alternative way to handle this error is to recreate the instance file on the root primary, ship a copy of the database from the primary and recreate instance files on ALL secondaries (tertiaries etc.) and restart the secondaries with the UPDATERESYNC qualifier. 加えて、FISのGT.Mサポートには、この発生を報告してください。 | |||
REPLINSTSTNDALN | Could not get exclusive access to replication instance file xxxx | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by MUPIP REPLIC INSTANCE_CREATE if it finds that the replication instance file it is attempting to create already exists and is being used (the journal pool for that instance exists) by GTM and/or MUPIP process(es). | |||
Action: | Shutdown all GTM and/or MUPIP processes that are using the replication instance file and reissue the command. If it fails even though you know for sure there is no other GT.M or MUPIP process accessing the replication instance file, delete the instance file and reissue the command. | |||
REPLREQROLLBACK | Replication instance file xxxx indicates abnormal shutdown. Run MUPIP JOURNAL ROLLBACK first. | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by MUPIP REPLIC SOURCE –START if it is about to create the journal pool and finds that the replication instance file header indicates the journal pool was not cleanly shutdown previously. This may cause the instance file not to correspond to the database and/or journals. | |||
Action: | Run MUPIP JOURNAL ROLLBACK to cleanup the instance file, database and journal files before starting a source server on this instance. | |||
REPLUPGRADEPRI | Attempted operation requires primary instance xxxx to support multi-site replication | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued if an attempt is made to start an active source server or activate a passive source server on a propagating primary instance while the receiver server on that instance is connected to a primary that has not yet been upgraded to the multi-site version of GT.M. This error is also issued when the receiver server on a propagating primary finds that the primary it connects to does not support multi-site replication and that there is at least one active source server running on the instance at that time. | |||
Action: | An active source server cannot be running on a secondary instance at the same time that the receiver server on this instance is connected to a primary that does not support multi-site functionality. Upgrade the primary instance identified in the message to the version of GT.M that supports multi-site replication functionality and then start active source servers. | |||
REPLUPGRADESEC | Attempted operation requires secondary instance xxxx to support multi-site replication | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued in three cases. 1) If a source server is currently connected to a dual-site secondary (i.e. a secondary running on a version of GT.M that does not support multi-site functionality), starting additional source servers will issue this error. 2) If a source server finds more than one source server (active or passive) running on the same instance at the time it connects to a dual-site secondary it will issue this error. 3) On a propagating primary instance, a source server that connects to a dual-site tertiary instance will issue a this error at connection time. | |||
Action: | Upgrade the secondary instance identified in the message to the version of GT.M that supports multi-site replication functionality and then start multiple source servers. | |||
SRCSRVEXISTS | Source server for secondary instance xxxx is already running with pid yyyy | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by a source server startup command if there is already a source server up and running for the secondary instance name specified in the command. | |||
Action: | Do not start multiple source servers for the same secondary instance. | |||
SRCSRVNOTEXIST | Source server for secondary instance xxxx is not alive | |||
Severity: 重大度 | Error | |||
MUPIP Error: | This error is issued by a mupip replic -source command that specifies any one of activate, changelog, checkhealth, deactivate, shutdown, statslog, stopsourcefilter if it finds no source server up and running for the secondary instance name specified in the command. | |||
Action: | Make sure source server for the specified secondary instance name is up and running before attempting any of the above commands. | |||
SRCSRVTOOMANY | Cannot start more than xxxx source servers in primary instance file yyyy | |||
Severity: 重大度 | Error | |||
MUPIP Error: | A maximum of 16 active and/or passive source servers are allowed at any point in time per instance. If 16 source servers are already running and another source server startup is attempted, it will issue this error. | |||
Action: | Shutdown any active or passive source server to allow the new source server to start up. | |||
JNLPOOLBADSLOT | Source server slot for secondary instance xxxx is in an inconsistent state. Pid = pppp, State = ssss, SlotIndex = iiii | |||
Severity: 重大度 | 警告 | |||
MUPIP Warning: | This is a debugging message sent to the syslog (operator log) whenever a source server startup or showbacklog command finds a structure in the journal pool holding inconsistent information. | |||
Action: | Forward the information to GT.M Support. No action otherwise necessary. The source server command will automatically fix the inconsistency of that structure. | |||
REPLINSTOPEN | Error opening replication instance file xxxx | |||
Severity: 重大度 | Error | |||
Runtime Error: | There was an error when GT.M or MUPIP tried to open the replication instance file. The error detail accompanies this message. | |||
Action: | Look at the accompanying error detail. Possible causes are file permissions, system quotas, etc. Fix the cause if possible. If not report to GT.M Support along with the error detail. | |||
REPLINSTCLOSE | Error closing replication instance file xxxx | |||
Severity: 重大度 | Error | |||
Runtime Error: | There was an error when GT.M or MUPIP tried to close the replication instance file. The error detail accompanies this message. | |||
Action: | Look at the accompanying error detail. Possible causes are file permissions, system quotas, etc. Fix the cause if possible. If not report to GT.M Support along with the error detail. | |||
REPLINSTREAD | Error reading xxxx bytes at offset yyyy from replication instance file ffff | |||
Severity: 重大度 | Error | |||
Runtime Error: | There was an error when GT.M or MUPIP tried to read from the replication instance file. The error detail accompanies this message. | |||
Action: | Look at the accompanying error detail. Possible causes are file permissions, system quotas, etc. Fix the cause if possible. If not report to GT.M Support along with the error detail. | |||
REPLINSTWRITE | Error writing xxxx bytes at offset yyyy from replication instance file ffff | |||
Severity: 重大度 | Error | |||
Runtime Error: | There was an error when GT.M or MUPIP tried to write to the replication instance file. The error detail accompanies this message. | |||
Action: | Look at the accompanying error detail. Possible causes are file permissions, system quotas, etc. Fix the cause if possible. If not report to GT.M Support along with the error detail. | |||
REPLINSTFSYNC | Error fsyncing replication instance file xxxx | |||
Severity: 重大度 | Error | |||
Runtime Error: | There was an error when GT.M or MUPIP tried to sync the replication instance file (using the fsync() call). The error detail accompanies this message. | |||
Action: | Look at the accompanying error detail. Possible causes are file permissions, system quotas, etc. Fix the cause if possible. If not report to GT.M Support along with the error detail. | |||
REPLINSTCREAT | Error creating replication instance file xxxx | |||
Severity: 重大度 | Error | |||
Runtime Error: | There was an error when GT.M or MUPIP tried to create the replication instance file. The error detail accompanies this message. | |||
Action: | Look at the accompanying error detail. Possible causes are file permissions, system quotas, etc. Fix the cause if possible. If not report to GT.M Support along with the error detail. |
Command Syntax: UNIX syntax (i.e., lowercase text and "-" for flags/qualifiers) is used throughout this document. OpenVMS accepts both lowercase and uppercase text; flags/qualifiers on OpenVMS should be preceded with "/".
リファレンス番号 ： 括弧()で表示されるリファレンス番号は、ソフトウェア強化を突き止めたり、カスタマーサポートの要求するために使用します 。
Platform Identifier: If a new feature or software enhancement does not apply to all platforms, the relevant platform or platforms appear in brackets [ ].