GT.Mデータベースレプリケーションは、レプリケーションの待ち時間を除いて、オリジナルのインスタンスとその複製インスタンスが論理的に同一であることを保証します。ローリング・アップグレード中に、オリジナルのインスタンスとそのレプリケート・インスタンスは論理的には同等ですが、Mグローバル変数の正確なストレージは異なる場合があります。FISでは、レプリケートされた領域(Region)に対するすべてのデータベースの更新が、オリジナルのインスタンス上でのみ行われるようにすることを推奨します。GT.Mは、オリジナルのインスタンスのすべての変更を複製インスタンスに複製します。
LMSアプリケーションは、通常の操作シナリオと障害シナリオの両方を含む多くの状況の手順を必要とします。LMSアプリケーションは手動で動作することができますが、要件はスクリプティングによる自動化を保証するほど十分に複雑です。数秒で複製インスタンスへの自動カットオーバーを提供する手順を、慎重に設計し、実装し、テストすることが不可欠です。GT.Mは、LMSによる継続的な可用性を実現するために必要な機能を提供します； しかし、円滑な操作には、実装するために重要なシステム・エンジニアリングが必要です。
現在および以前のインスタンスの状態（発動/複製）を決定します。
必要なデータベースのリカバリ/ロールバックを実行してください。異なる障害モードには異なる回復シナリオがあります。それは、後続の処理のために以前にコミットされたトランザクションのロールバックを含まれます。自動または手動でトランザクションのロールバックを調整してください。
新しいジャーナルファイルを作成します。必須ではありませんが、これはシステム管理を簡素化します。
ジャーナル・プールを確立するために、レプリケートする各インスタンスでソース・サーバーを起動します。カットオーバの場合、新しいオリジナルのインスタンスは、データを複製するためにジャーナル・プールが確立されている必要があります。オリジナルのインスタンスで、アクティブ・モードでソース・サーバーを起動します。
複製インスタンスでは、パッシブモードでソース・サーバーを起動します。複製インスタンス上でGT.M レシーバー・サーバーを起動します。
オリジナルのインスタンスを起動するときは、アプリケーション・サーバーを起動します。必要に応じて、複製インスタンス上でアプリケーション・サーバーを起動して、迅速なカットオーバーを容易にすることができます； ただし、複製インスタンスに対する更新は実行しないでください （常にゴールデン・ルール(金科玉条)を覚えておいてください：すべてのデータベースの更新は、オリジナルのインスタンスでのみ実行する必要があります）。
もし新しいオリジナルのインスタンスを開始していて、オリジナルのインスタンスがダウンしたときにバッチ操作が進行中であった場合は、新しいオリジナルのインスタンスでこれらのバッチ操作を再開します。
アプリケーションインスタンスの初期のスタートアップでは、以前の状態は全くありません。LMSアプリケーションを起動するために2つの方法があります： オリジナルのインスタンスとそれに続く複製インスタンスを起動することと、両方を同時に起動することです。
シングルサイト
従来のシングル・サイトとしてマルチサイト・アプリケーションを起動する場合は、レプリケートするインスタンスを後で起動するシングル・サイトとして起動するよりも、Mプロセスがデータベースにアクセスする前に常にジャーナル・プールを確立してください。ジャーナルプールを作成するためにパッシブモードでソースサーバーを起動します。次に、アプリケーションを起動します。後で、レプリケートするインスタンスが起動すると、ソース・サーバーをアクティブモードに切り替えます。
システムが以前のクラッシュがあった時から、整合性がある状態の最後までデータベースのリカバリ/ロールバックを実行してください。もしデータベースがクリーンにシャットダウンされたならば、最後まで整合性がある状態のリカバリ/ロールバックは本質的に "no-op" です。この操作は、最後にコミットされたトランザクションへデータベースを復元します。（no-op = NOP（ノップ）あるいは NOOP（ノープ）とは no operation （何もしない）） （メディアにダメージがないことを前提としています）
新しいジャーナルファイルを作成します。
パッシブモードでソースサーバをスタートしてください。
アプリケーションサーバをスタートしてください。
もしバッチ処理がプロセス内に存在したことをデータベースの状態として示すならば、バッチ処理を再起動してください。
デュアルサイト - 同時起動
ネットワークまたはタイミングの問題により複数のインスタンスが生成されたり複製されたりする可能性があるため、LMS構成のインスタンスの同時起動は、FISは推奨しません。ただし、デュアルサイト構成では、発信インスタンスと複製インスタンスを同時に起動することは可能です。手順は次のとおりです：
外部エージェントを使用して、起動インスタンスと複製インスタンスを識別し、両方のサイトを同時に起動します。
両方のデータベースが論理的に同一で、同じジャーナル・シーケンス番号を持っていることを確認してください。（起動時に、インスタンスはそのジャーナルシーケンス番号をレプリケートされた領域の最大 reg_seqno とみなします。したがって、起動時のインスタンスとその複製インスタンスに同一のファイルがない場合、つまり、論理的には同じだが構成が異なる場合は、複製インスタンス上の少なくとも1つの領域(Region)に、オリジナルのインスタンス上の最大 reg_seqno と同じreg_seqnoおよびresync_seqnoがあることを確認します。
もし両者が同一でない可能性がある場合は、両者を同時に持ち込まないでください。
シングル-サイトからマルチサイトへ
FISは、最初にシングル-サイトとしてアプリケーションを起動し、複製インスタンスを起動することを推奨します。
A -> Bレプリケーション構成をはじめて設定する
オリジナルのインスタンス Philadelphia(フィラデルフィア) とその複製インスタンス Shanghai(シャンハイ) をセットアップするには、次の手順を実行します：
-
Philadelphia(フィラデルフィア) で：
レプリケーションをオンにします。
レプリケーション・インスタンスファイルを作成します。
ソースサーバを起動します。
-
Shanghai(シャンハイ) で：
レプリケーションをオンにします。
レプリケーション・インスタンスファイルを作成します。
パッシブ・ソース・サーバーを起動します。
レシーバー・サーバを起動します。
![[注意]](images/note.jpg) |
ダウンロードの例 | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
msr_proc1.tar.gz には、A -> Bレプリケーション構成を設定するためのすぐに実行できるサンプルが含まれています。ダウンロード msr_proc1.tar.gz をクリック
この例では、ローカル・テスト・システムで A -> Bレプリケーション構成をセットアップするために使用できるコマンド・シーケンスを示します。この例で使用されているスクリプトに関して著作権は主張されていません。この環境を使用する前に、このモジュールを理解し、適切に調整する必要があります。 |
初めて A -> Pレプリケーション構成を設定する
オリジナルのインスタンスPhiladelphia(フィラデルフィア)と補足的なインスタンスPerth(パース)を設定するには、次の手順を実行します：
-
Philadelphia(フィラデルフィア) で：
レプリケーションをオンにします。
レプリケーション・インスタンスファイルを作成します。
ソースサーバを起動します。
-
Perth(パース) で：
レプリケーションをオンにします。
-supplementary 修飾子を使用してレプリケーション・インスタンス・ファイルを作成します。
パッシブ・ソース・サーバーを起動します。
-updateresync="/path/to/bkup_orig_repl_inst_file" -initialize を使用して、レシーバー・サーバーおよび更新プロセスを開始します。-updateresync -initialize 修飾子は一度だけ使用してください。
その後のレシーバー・サーバーおよび更新プロセスの起動では、-updateresync -initialize修飾子を使用せずに、-rollback -fetchresyncを実行してレシーバー・サーバーおよび更新プロセスを開始します。
|
ダウンロードの例 | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
msr_proc2.tar.gz には、A -> Pレプリケーション構成を設定するためのすぐに実行できるサンプルが含まれています。ダウンロード msr_proc2.tar.gz をクリック
この例では、ローカル・テスト・システムで A -> Pレプリケーション構成をセットアップするために使用できるコマンド・シーケンスを示します。この例で使用されているスクリプトに関して著作権は主張されていません。この環境を使用する前に、このモジュールを理解し、適切に調整する必要があります。 |
シャットダウンまたはクラッシュ後のインスタンスの複製の開始
もしシャットダウンまたはクラッシュ後にレプリケートされた領域(Region)が影響されない場合は、レプリケートするインスタンスを再起動するだけです。オリジナルのインスタンスに自動的に追いつきます。シャットダウン操作またはクラッシュ後に複製インスタンスを開始するには、次の手順を実行します：
最後まで整合性がある状態にするためにデータベースをリカバリ/ロールバックします。
新しいジャーナルファイルを作成します。
最初にパッシブ・ソース・サーバーを起動し、次にレシーバー・サーバーを起動します。
必要に応じて、アプリケーション・サーバを起動します。
オリジナルのインスタンスのコピーからインスタンスを複製する
このシナリオでは、複製インスタンスを起動するために使用されるデータベースは、オリジナルのインスタンスが起動したデータベースと論理的に同一であり、同じジャーナル・シーケンス番号を持ちます。複製インスタンスが開始されると、オリジナルのインスタンスに適用されたすべてのトランザクションが、オリジナルのインスタンスに追いつくと複製インスタンスに複製されます。
オリジナルのインスタンスのコピーから複製インスタンスを開始するには、次の手順を実行します：
データベース・ファイルをロード/復元します。
レプリケーション・インスタンス・ファイルを再作成します。
レプリケーションをオンにします。
パッシブ・ソース・サーバをスタートし、その次に、レシーバー・サーバをスタートします。
必要に応じて、アプリケーション・サーバを起動します。
バックポインタとともにオリジナルのインスタンスのすべてのジャーナルファイルを保持します。これは、ソース・サーバーがジャーナル・ファイルにアクセスして、もはやジャーナル・プールにないトランザクションを読み取るためです。
|
注意 |
|---|---|
データベースファイルを複製インスタンスにコピーする前に、複製インスタンス内のすべてのGT.Mアクティビティを停止し、開いているすべてのデータベースファイルをRUNDOWNするか、または、新しいデータベース・ファイルを作成し、オリジナルのインスタンスの抽出をロードします。 |
オリジナルのインスタンスのバックアップからのインスタンスの複製の開始
複製インスタンスを起動するためのより一般的なシナリオは、オリジナルのインスタンスのバックアップを取得し、それを複製インスタンスとして起動することです。もしバックアップが包括的なバックアップである場合、ファイル・ヘッダーにはジャーナルシーケンス番号が格納されます。
バックアップは、新しいジャーナル・ファイルを作成するために MUPIP backupの -newjnlfilesスイッチを使用する必要があります。複製インスタンスが操作可能になると、複製インスタンスに送信するトランザクションを見つけるために、ソース・サーバーをバックアップの前に戻す必要はありません。
オリジナルのインスタンスのバックアップから複製インスタンスを開始するには、次の手順を実行します：
データベースをロード/レストア します。もし複製データベースが、オリジナルのインスタンスからの包括的またはデータベース・バックアップのものでない場合は、複製インスタンス上の少なくとも1つの複製された領域(Region)のバックアップのちょうどその時点からのジャーナル・シーケンス番号を設定します。
-noprevjnlfileフラグを使用して、以前の世代のジャーナル・ファイルへのバック・ポインターを持たない新規ジャーナル・ファイルを作成します。このデータベースはこのインスタンスの先頭を表すので、前世代のジャーナルファイルを持つことは無意味です。
レシーバー・サーバーの他の起動修飾子とともに、-updateresync修飾子を使用してパッシブ・ソース・サーバーとレシーバー・サーバーを開始します。オリジナルのインスタンスが複製インスタンスに送信された最後のジャーナル・シーケンス番号を格納するので、この修飾子は複製インスタンス内の実際のジャーナル・シーケンス番号からの複製開始を強制するために必要です。-updateresyncを指定しないと、レシーバー・サーバーは、複製インスタンスのジャーナルシーケンス番号が、オリジナルのインスタンスが予期しているものよりも高くなる可能性があるため、複製の開始を拒否することがあります。
必要に応じて、アプリケーション・サーバを起動します。
オリジナルのインスタンスをバックアップの開始以前の状態にロールバックする必要はないため、オリジナルのインスタンスのオンラインバックアップコマンドによって作成されたジャーナルファイルで、オリジナルのインスタンスの生成リンクを切断することができます。ジャーナル・ファイルの前世代のリンクを切断するには、MUPIP SET -jnlfile <jnl_file> -noprevjnlfileを使用します。SETコマンドのスタンドアロン要件を無効にするには、-bypass修飾子を使用します。
通常の操作では、マルチサイトからシングルサイトへ移行するときは、レシーバー・サーバーと更新プロセス、およびすべてのパッシブ・ソース・サーバーとすべての非アクティブなアプリケーションサーバーをシャットダウンします。次に、データベースのMUPIP RUNDOWN操作を実行します。
拡張シャットダウンの場合は、オリジナルのインスタンスのアクティブなソースサーバーをパッシブに切り替えて、レプリケートするインスタンスに接続しないようにします。通常のシナリオでは、オリジナルのインスタンスは単独で動作し、複製インスタンスが戻ったときに、中断したところから複製を再開します。
オリジナルのインスタンスと複製インスタンスがロールを切り替える制御されたカットオーバーを実行するには、次の手順に従います。このようなステップは、カットオーバをテストするため、または、メンテナンスのためにオリジナルのインスタンスを停止させるために必要です。次のステップでは、B が以前の複製インスタンスおよび新しいオリジナルのインスタンスである間、A は以前のオリジナルのインスタンスと新しい複製インスタンスです。
クライアントがタイムアウトしてメッセージを再試行する可能性を最小限に抑えるため、またバッチ処理が実行されていない場合は、データベースの更新頻度が低い時間を選択します。
起動/複製ステータスの識別を担当する外部システムは、サイトBが現在のインスタンスであり、サイトAが複製インスタンスであるはずであることを認識する必要があります。もしクライアントとサーバー間のメッセージング・レイヤーが外部の制御メカニズムと異なる場合は、レプリケートするインスタンスにメッセージをルーティングするように指示します。カットオーバー中にメッセージを一時的に保持する必要があるかもしれません。
Aで：
アプリケーションサーバを停止してください。
適切なタイムアウトでソース・サーバーをシャットダウンします。タイムアウトは、保留中のトランザクションを複製インスタンスに複製するのに十分な長さである必要がありますが、クライアントがアプリケーションが利用できないと結論づけるには余りに長くはなりません。GT.Mのデフォルトのソース・サーバ待機時間は最大120秒です。
Bが、オリジナルのインスタンスとして機能するのを待ってから、オリジナルのインスタンスになったときにジャーナル・シーケンス番号のB（-EDITINSTANCE -SHOWを使用）を照会し、この番号にロールバックします。オリジナルのインスタンスからロールオフされたトランザクションは、「複製されないトランザクション」になり、その後、自動的にまたは手動でB上で調停する必要があります。
新しいジャーナルファイルを作成します。
パッシブソースサーバをスタートし、その次に、受信サーバをスタートしてください。
必要に応じて、アプリケーション・サーバを起動します。
Bで：
適切なタイムアウトを持ってレシーバーサーバをシャットダウンします。
新しいジャーナルファイルを作成します。
アクティブなパッシブソースサーバを作成します。
アプリケーションサーバを起動してください（もしそれらが以前にパッシブであったならば、それらをアクティブしてください）。
もしバッチ処理がプロセス内に存在したことをデータベースの状態として示すならば、バッチ処理を再起動してください。
オンライントランザクションを受け入れて開始してください。
オリジナルのインスタンスをシャットダウンするには：
ジャーナルプールに接続されている可能性のあるすべてのGT.Mとmupipプロセスをシャットダウンします。
オリジナルのインスタンスが補足的なインスタンスでもある場合は、レシーバー・サーバーをシャットダウンします（将来のGT.Mバージョンでは複数のレシーバー・サーバーが存在する可能性があります）。
すべてのアクティブおよび/またはパッシブ・ソース・サーバーをシャットダウンします。
mupip rundown -region を実行して、データベース、ジャーナルプール、レシーバー・プールの共有メモリーが正常に終了していることを確認します。
伝播するインスタンスをシャットダウンするには：
複製するすべてのインスタンス・サーバー（レシーバー・サーバー、更新プロセス、およびそのヘルパープロセス）をシャットダウンします。
オリジナルのインスタンス・サーバー（すべてのアクティブおよび/またはパッシブソースサーバー）をシャットダウンします。
レプリケートするインスタンスでは、ジャーナルプールに接続されているGT.MまたはMUPIPプロセスがないことを確認します（これらのプロセスは、元のインスタンスでのみ有効です）。
mupip rundown -region を実行して、データベース、ジャーナルプール、レシーバー・プールの共有メモリーが正常に終了していることを確認します。
ネットワーク障害
もしクライアントからオリジナルのインスタンスへのネットワークに障害が発生し、クライアントから複製インスタンスへのネットワークがまだ機能している場合、オリジナルのインスタンスから複製インスタンスへのカットオーバーを実行します。
もしクライアントから使用可能なすべての複製インスタンスへのクライアントからネットワークへのネットワークに障害が発生すると、アプリケーションはもはや使用できなくなります。
もしオリジナルのインスタンスと複製インスタンス間のネットワークに障害が発生した場合、GT.Mレプリケーションを管理するためのアクションは必要ありません。オリジナルのインスタンスは引き続きアプリケーションを利用可能にします。インスタンスの複製は、ネットワークの復元時にオリジナルのインスタンスに追いつきます。
もしクライアントから複製インスタンスへのネットワークに障害が発生した場合、GT.Mレプリケーションを管理するためのアクションは必要ありませんが、できるだけ早くネットワークを運用可能にすることは賢明です。
シングルサイトの障害
インスタンスの複製の障害
複製後のインスタンスが失敗した後にオリジナルの状態に戻ると、その複製インスタンスは引き続き複製インスタンスになります。詳細については、"シャットダウンまたはクラッシュの後にセカンダリをスタート" の項を先立ってを参照してください。
オリジナルのインスタンスの障害
もしオリジナルのインスタンスが失敗した場合は、複製インスタンスが引き継ぐ必要があります。オリジナルのインスタンスが元に戻ったとき、それは新しい複製インスタンスとして出現するはずです。
外部制御機構は、オリジナルのインスタンスが失敗したことを検出し、そして、複製インスタンスをオリジナルのモードに切り替えるアクションを実行し、トランザクションを新しいオリジナルのインスタンス（以前の複製インスタンス）にルーティングするか、または、トランザクションを新しいオリジナルのインスタンスにルーティングすることクライアントに通知するか、どちらか一方をします。
もし以前のインスタンスが特定のトランザクションに応答しなかった場合、それらが処理されたかどうか、および、データベースの更新が以前の複製インスタンスにコミットされたかどうかは特定できません。これらのトランザクションは、新しい複製インスタンスで処理する必要があります。以前のインスタンスが新しい複製インスタンスとして起動すると、GT.Mは処理されたトランザクションとデータベースの更新をロールオフして、新しいオリジナルのインスタンスの調整を行います。
新しいオリジナルのインスタンス（以前の複製インスタンス）で
レプリケーションサーバーを停止してください。
新しいジャーナルファイルを作成します。
ソース・サーバーをパッシブモードからアクティブモードに切り替えて、新しい複製インスタンス（以前のオリジナルのインスタンス）がバックアップされると複製を開始します。
アプリケーションサーバをスタートするか、または、もしそれらがパッシブされたなら、それらがアクティブになる必要があります。新しいオリジナルのインスタンスは、クライアントからトランザクションを受信する準備が整いました。
もしバッチ処理がプロセス内に存在したことをデータベースの状態として示すならば、バッチ処理を再起動してください。
新しい複製インスタンス（以前のオリジナルのインスタンス）がバックアップされると、オリジナルのインスタンスに、オリジナルのインスタンスとなったそのときのジャーナル・シーケンス番号を問い合せます（詳細は、“複製インスタンス・ファイルとジャーナル・プールの属性の表示/変更” を参照してください。この時点まで複製インスタンスをロールバックします（詳細は、 “システム障害発生後のデータベースのロールバック”の章を参照してください）。失われたトランザクション・ファイルまたはロールバック操作の結果として破損したトランザクション・ファイルからトランザクションを調停します。
新しいジャーナルファイルを作成します。
パッシブモードでソースサーバをスタートしてください。
レシーバー・サーバーを起動して、新しい複製インスタンスとして複製を再開します。デュアルサイト・オペレーションは、復元されます。
必要に応じて、パッシブ・アプリケーション・サーバーを起動します。
様々なデュアルサイト障害のシナリオが起こりえます。各ケースは完全なシステム停止です - つまり、アプリケーションはもはや利用できません（マルチサイトが魅力的な理由です）。このセクションでは、各シナリオに基づきリカバリーのメカニズムを識別します。各シナリオでは、サイトA は最初はオリジナルのインスタンスであり、サイトB は最初は障害が発生する前の複製インスタンスです。
インスタンスの複製（サイトB）が最初に失敗する
以下のシナリオでは、複製インスタンスが最初に失敗します。複製インスタンスが失敗すると、オリジナルのインスタンスは引き続き動作します。オリジナルのインスタンスの複製ソース・サーバーは複製インスタンスに更新を送信できません。したがって、オリジナルのインスタンスの障害ポイントに複製されていないトランザクションのキューがあります。その後、複製インスタンスが回復する前にオリジナルのインスタンスが失敗し、デュアルサイト停止が発生します。操作の手順は、どのサイトを最初にリカバリーするかよって異なります。
最初にサイトAを回復する場合
サイトAで：
最後にコミットされたトランザクション（最後の整合性があるアプリケーション状態）へデータベースをロールバックしてください。
新しいジャーナルファイルを作成します。
ソースサーバを起動します。
アプリケーションサーバをスタートしてください。アプリケーションの可用性は、すぐに復元されます。
もしバッチ処理中であることをインスタンスの状態が示している場合は、バッチ処理を再開します。
サイトBで、それが回復するとき：
最後にコミットされたトランザクションへデータベースをロールバックしてください。
新しいジャーナルファイルを作成します。
パッシブモードでソースサーバをスタートしてください。
レシーバー・サーバを起動します。デュアルサイト・オペレーションは、復元されます。
可能なら、パッシブアプリケーションサーバを起動してください。
最初にサイトBを回復する
サイトBで：
最後にコミットされたトランザクション（最後の整合性があるアプリケーション状態）へデータベースをロールバックしてください。
新しいジャーナルファイルを作成します。
ソースサーバを起動します。
アプリケーションサーバをスタートしてください。アプリケーションの可用性は、すぐに復元されます。
もしバッチ処理がプロセス内に存在したことをデータベースの状態として示すならば、バッチ処理を再起動してください。
サイトAで、それが回復するとき：
オリジナルのインスタンスになったジャーナル・シーケンス番号については、オリジナルのインスタンスを問い合せてください（詳細は、 “レプリケーション・インスタンス・ファイルとジャーナル・プールの属性の表示/変更” を参照）、そして、この時点まで複製インスタンスをロールバックします。次に、紛失したトランザクション・ファイルをオリジナルのインスタンスに適用して、調整/再適用を行います。
新しいジャーナルファイルを作成します。
パッシブモードでソースサーバをスタートしてください。
新セカンダリとしてレプリケーションを再開するために受信サーバをスタートしてください。デュアルサイト・オペレーションは、復元されます。
可能なら、パッシブアプリケーションサーバを起動してください。
オリジナルのインスタンス（サイトA）が最初に失敗する
以下のシナリオでは、オリジナルのインスタンスが最初に失敗し、サイトBへの切り替えが発生します。サイトBはオリジナルのインスタンスとして動作し、失敗します。
最初にサイトBを回復する
サイトBで：
最後にコミットされたトランザクションへデータベースをロールバックしてください（最後の整合性があるアプリケーション状態）。
新しいジャーナルファイルを作成します。
ソースサーバを起動します。
アプリケーションサーバをスタートしてください。アプリケーションの可用性は、すぐに復元されます。もしバッチ処理がプロセス内に存在したことをデータベースの状態として示すならば、バッチ処理を再起動してください。
サイトAで、それが回復するとき：
オリジナルのインスタンスになったジャーナル・シーケンス番号については、オリジナルのインスタンスを問い合せてください（詳細は、 “レプリケーション・インスタンス・ファイルとジャーナル・プールの属性の表示/変更” を参照）、そして、この時点まで複製インスタンスをロールバックします。次に、紛失したトランザクション・ファイルをオリジナルのインスタンスに適用して、調整/再適用を行います。破損したトランザクション・ファイルには、完了していないトランザクションに関する情報が含まれており、作業の再開場所を調べる際に役立ちます。しかし、破損したトランザクションは、失われたトランザクションとは異なり、本質的に不完全です。
新しいジャーナルファイルを作成します。
パッシブモードでソースサーバをスタートしてください。
新セカンダリとしてレプリケーションを再開するために受信サーバをスタートしてください。デュアルサイト・オペレーションは、復元されます。
可能なら、パッシブアプリケーションサーバを起動してください。
最初にサイトAを回復する場合
サイトAで：
最後にコミットされたトランザクションへデータベースをロールバックしてください（最後の整合性があるアプリケーション状態）。
新しいジャーナルファイルを作成します。
ソースサーバを起動します。
アプリケーションサーバをスタートしてください。アプリケーションの可用性は、すぐに復元されます。
もしバッチ処理がプロセス内に存在したことをデータベースの状態として示すならば、バッチ処理を再起動してください。
サイトBで、それが回復するとき：
プライマリであった時に処理されたすべてのトランザクションをロールバックしてください。ロールバックによってデータベースからバック・アウト(backed out ：ディスクレコードに加えられた変更を取消して元に戻す)されたトランザクションを元のインスタンスに送信して、調整/再適用します。
新しいジャーナルファイルを作成します。
パッシブモードでソースサーバをスタートしてください。
新セカンダリとしてレプリケーションを再開するために受信サーバをスタートしてください。デュアルサイト・オペレーションは、復元されます。
可能なら、パッシブアプリケーションサーバを起動してください。
複雑なデュアルサイト障害が発生すると、インスタンスの再起動方法に応じて、多数のレプリケートされないトランザクションが発生する可能性があります。この状況は、両方のインスタンスが停止している場合に発生し、レプリケートするインスタンスがある期間にわたって発生し、オリジナルのインスタンスの状態を想定し、最初のインスタンスがダウンしている間に再び失敗した場合に発生します。
次の図でサイトAとして表される、2番目の障害後最初に最初のオリジナルのインスタンスが起動すると、それがオリジナルのインスタンスになります。サイトBが起動すると、複製インスタンスとして動作し、オリジナルのインスタンスであってサイトAがダウンしている間に実行されたすべてのトランザクションをロールバックします。これらのトランザクションは、レプリケートされていないトランザクションになります。もしサイトBが最初に立ち上がったならば、まず、サイトAが再起動した時に、レプリケートされていないトランザクションが発生するでしょう。AはBが失敗した後のオリジナルのインスタンスだった間、これらはトランザクションです。
このような状況から復旧する場合、複製インスタンスが起動すると、オリジナルのインスタンスは常に現在の記録システムになります。複製インスタンスは、両方のインスタンス内で共通のジャーナル・シーケンス番号が最も高いトランザクションにロールバックし、そこから「追いつく」必要があります。オリジナルのインスタンスでは、ロールバック操作の結果生じた、失われたトランザクションファイルと破損したトランザクションファイルをすべて調整します。
ローリング・ソフトウェア・アップグレードは、新しいソフトウェア・リリースをシステムに適用しながら、継続的なサービスを提供します。つまり、ローリング・ソフトウェア・アップグレードでは、各システムが新しいソフトウェアリリースで独立して更新され、この間に他のシステムがオリジナルのインスタンスとして機能するため、アプリケーションのダウンタイムが不要になります。
デュアルサイト・ローリング・アップグレード
このローリング・アップグレード・シーケンスでは、レプリケーション・インスタンスが1つのみであることが前提です。これはアップグレード中に停止します。したがって、アップグレード中にオリジナルのインスタンスが停止した場合、アプリケーションは使用できなくなります。
|
注意 |
|---|---|
適切に設定されたLMS設定は、この危急を回避します。 |
アップグレード前にサイトAがオリジナルのインスタンスであると仮定して、ローリング・アップグレードを実行する手順は次のとおりです：
サイトAは正常に動作し続けます（つまり、オリジナルのインスタンスに複製インスタンスのアップグレードは複製インスタンスの障害のように見えます）。
サイトBで：
ソースとレシーバサーバおよびアプリケーションをシャットダウンしてください。MUPIP RUNDOWN操作を実行し、バックアップコピーを作成します。
ソフトウェアをアップグレードしてください。
もしデータベース・レイアウトまたはスキーマに変更がない場合は、レプリケートするインスタンスを持ち上げ、計画されたカットオーバを実行します（次のように）。
いくつかのレプリケートされたデータベース領域の中にある、ジャーナルシーケンス番号の最大値に注意してください。
データベースをアップグレードしてください。
上記の注意のように、ジャーナルシーケンス番号の最大値へレプリケートされた領域のジャーナルシーケンス番号をセットしてください。
もしデータベース・スキーマに変更がない場合は、複製インスタンスをバックアップして、計画されたカットオーバーを続行します（次のように）。
もしデータベースのスキーマが何も変わらなかったならば、ソース・サーバ上の、新から旧へのフィルタ(new-to-old filter)で複製インスタンスを立ち上げ、そして、レシーバ・サーバ上の、旧から新へのフィルタ(old-to-new filter )でセカンダリバックアップを立ち上げてください。
この時点で、デュアルサイトの動作は、新しいソフトウェアが実行しているサイトBと、古いソフトウェアを実行しているサイトAで、復元されます。これは、正しい動作を確認するために、しばらくの間このモードでの動作が適切でしょう。
-
その後、次のコマンドを実行してアップグレードを完了できます：
システム間で制御されたカット・オーバーを実行します。
サイトAを複製インスタンス、サイトBを残りのアップグレードの元のインスタンスにします。
サイトAで：
いったん、サイトBで新ソフトウェアの動作に満足したら、ソースとレシーバサーバおよびアプリケーションをシャットダウンしてください。データベースを停止し、バックアップコピーを取ってください。
ソフトウェアをアップグレードしてください。
いくつかのレプリケートされたデータベース領域の中にある、ジャーナルシーケンス番号の最大値に注意してください。
データベースをアップグレードしてください。
上記の注意のように、ジャーナルシーケンス番号の最大値へレプリケートされた領域のジャーナルシーケンス番号をセットしてください。
もしデータベース・スキーマに変更がない場合は、複製インスタンスをバックアップします。 正常な操作が復元され、アップグレードが完了します。
もしフィルタがある場合は、サイトAをセカンダリとして起動します。サイトB上のフィルターをオフにするには、サイトA上のレシーバー・サーバー上で -stopsourcefilter修飾子を使用します。これにより、通常の操作が復元されます。
ローリング SI レプリケーション・アップグレード
V5.5-000 は SIレプリケーション用に1つのソース・ストリームのみをサポートしていますが、アーキテクチャーは15個の外部ソース・ストリーム（番号1〜15）を許可し、ストリーム 0 はローカルに生成された更新です。通常の状態では、補足的なインスタンス(SI)では、ストリーム 0 と1からの更新が表示されます。もし SI ストリームの受信者があるソースから別のソースにレプリケーションを受信することから移動された場合、他のストリーム番号（他のストリームからの更新にも対応）が表示されることがあります。
SIレプリケーションを追加する際には、（a）SIレプリケーションのソース側とレシーバー側の両方がV5.5-000でなければなりません。（b）インスタンスをV5.5-000にアップグレードするには、新しいレプリケーションインスタンスファイルが必要で、なぜなら SIのレプリケーション・インスタンス・ファイル形式は以前のリリースのものと互換性がありません。そして、（c）ソースとレシーバーの両方がV5.5-000の場合、-updateresync修飾子には以前のレプリケーション・インスタンス・ファイルの名前が必要です。
インスタンスが複製されていない単独のインスタンス以外の場合は、オリジナルのプライマリ・インスタンスではなく、複製するセカンダリ・インスタンスをアップグレードする必要があります。BCレプリケーション（たとえば、オリジナルのプライマリとして Ardmore(アードモア) 、レプリケーション・セカンダリとして BrynMawr(ブリンマー) ）から起動し、SIレプリケーションをMalvern(マルバーン)に開始する最も簡単な手順は次のとおりです：
BrynMawr(ブリンマー) を停止してV5.5-000にアップグレードしてください。BrynMawr(ブリンマー)には新しい複製インスタンス・ファイルが必要です。データベース・ファイルとグローバル・ディレクトリのアップグレードの詳細については、関連するリリースノートを参照してください。 FISから別途指示がない限り、常にオブジェクトおよびジャーナルファイルはGT.Mの各リリースに固有のものとみなされます。
Ardmore(アードモア) から BrynMawr(ブリンマー)へのBC複製を再開します。Ardmore(アードモア) はV5.5-000よりも古いGT.Mリリースになっているため、BrynMawr(ブリンマー)でレシーバー・サーバーを初めて起動するときに、-updateresync修飾子には以前のレプリケーション・インスタンス・ファイルの名前は必要ありません。
より便利な場合は、BrynMawr(ブリンマー) または Ardmore(アードモア)のバックアップから補助インスタンスMalvern(マルバーン) を作成します。Malvern(マルバーン)には、-supplementary修飾子で作成された新しい複製インスタンスファイルが必要です。
BrynMawr(ブリンマー) から Malvern(マルバーン)へのSIレプリケーションを開始します。Malvern(マルバーン) と BrynMawr(ブリンマー)は両方ともV5.5-000であるため、Malvern(マルバーン) レシーバー・サーバーの初回起動時に使用される-updateresync修飾子には、BrynMawr(ブリンマー) からその値としてBACKUPの一部としてコピーされた古い複製インスタンス・ファイルが必要です。
BrynMawr(ブリンマー) をアップグレードすると、次のことが可能になります：
BrynMawr(ブリンマー) が Ardmore(アードモア) へのBCレプリケーションと Malvern(マルバーン)へのSIレプリケーションのオリジナルのプライマリ・インスタンスになるようにスイッチオーバーします。これは現在のLMS手続きと変わりはありません。BrynMawr(ブリンマー) から Malvern(マルバーン)へのSIレプリケーションはスイッチオーバーを通じて動作します。
Ardmore(アードモア)を停止してV5.5-000にアップグレードしてください。新しいレプリケーション・インスタンス・ファイルが必要です。
BrynMawr から ArdmoreへのBCレプリケーションを開始します。Ardmore(アードモア) と BrynMawr(ブリンマー) は両方ともV5.5-000であるため、Ardmore(アードモア)の最初のレシーバー・サーバー開始の -updateresync修飾子には、以前の複製インスタンス・ファイルの名前が必要です。Ardmore(アードモア)のV5.5000より前の形式の複製インスタンスファイルを使用することはできないため、この特殊なケースでは、以前のファイルとしてBrynMawr(ブリンマー) からのバックアップコピーを使用してください。
ソース側で：
コピーするインスタンスをバックアップするには、-REPLINSTANCE修飾子を付けたMUPIP BACKUPコマンドを使用します。
バックアップされたデータベースとインスタンス・ファイルを受信側に発送します。
受信側では：
バックアップされたインスタンス・ファイルに対してMUPIP REPLIC -EDITINSTコマンドを実行して、インスタンス名を変更してターゲットインスタンスを反映させます。これにより、インスタンス・ファイル内の履歴レコードを保持しながら、ソース・レプリケーション・インスタンス・ファイルをターゲット・インスタンスで使用できるようになります。
新しいジャーナル・ファイルを作成し、パッシブ・ソース・サーバとレシーバー・サーバーを開始します（-updateresync修飾子なし）。
ソース・サーバーの接続を許可します。
レプリケーション・インスタンス・ファイルをアップグレードするには、次の手順を実行します：
ソースとレシーバのサーバー・プロセスを除くすべてのmumps、MUPIP、DSEプロセスをシャットダウンします； レシーバー・サーバー（および更新プロセスとともに）とすべてのソース・サーバー・プロセスをシャットダウンします。MUPIP RUNDOWNを使用して、インスタンスのすべてのデータベース・ファイルが閉じられ、それらにアクセスするプロセスがないことを確認します。
バックアップ・コピーを作成した後、既存のレプリケーション・インスタンス・ファイルの名前を変更します。
-
新しいレプリケーション・インスタンス・ファイルを作成します（管理および操作ガイドに記載されているように、コマンドライン・オプションまたは環境変数でインスタンス名とインスタンスファイル名を指定する必要があります）。
-
もしこれがSI複製（上記の例ではMalvern(マルバーン)）を受け取る場合、またはSI複製を受け取るインスタンス（上記の例のNewtown(ニュータウン)）からBC複製を受け取る場合は、次のコマンドを使用します：
mupip replicate -instance_create -supplementary
-
それ以外の場合は、次のコマンドを使用します。
mupip replicate -instance_create
-
-
レプリケーション・ストリームを受け入れる準備をする：
-updokフラグを使用してパッシブ・ソース・サーバーを起動します。
- レシーバー・サーバーを updateresyncフラグを使用して開始します。例：mupip replicate -receiver -start -updateresync=filename フラグ。 ファイル名はソースがV5.5-000の場合は以前のレプリケーションファイルです、古いGT.Mの場合はファイル名はありません（その他の必要なコマンドラインフラグについては、「管理および操作ガイド」を参照してください）。
このインスタンスにレプリケートするルート・インスタンスまたは伝播するプライマリ・インスタンスでソース・サーバーを起動します。ソース・インスタンス上での更新が受信側インスタンスに正常に複製されていることを確認します。
-updateresync修飾子は、相互に合意された同期の共通開始点を取り決める代わりに、受信側インスタンスが現在のソース・インスタンスまたは過去のある時点と一致する有効な状態を保障することを示します。一般に、これは、受信インスタンスがソース・インスタンスからのバックアップ・コピーで更新されたばかりであることを意味します。
|
注意 |
|---|---|
GT.M V5.5-000インスタンスは、このドキュメントの「制限」の章で説明した制限に従って、古いGT.MリリースとのBC複製ストリームのソースまたはBC複製ストリームを受け取ることができます。ソースと受信者の両方がV5.5-000でなければならないのは、SIレプリケーションの場合のみです。 |
補助的インスタンス(SI)は、V5.5-000にアップグレードする最初のインスタンスまたは単独のインスタンスにすることはできません。補足インスタンスにレプリケーション・ストリームを提供するには、すでにV5.5-000を実行しているインスタンスを作成しておく必要があります。
（a）別インスタンスのバックアップコピー、補助的インスタンス、オリジナルのプライマリまたは複製セカンダリに新しいアイデンティティを与えることによって、または（b）新しく作成された新しいインスタンスから補助インスタンスを作成できます。補助的インスタンスを作成するために使用されるインスタンスは、すでにV5.5-000にアップグレードされている必要があります。
別のインスタンスのバックアップを開始して、上記の mupip replicate -instance_create コマンドに -supplementaryフラグを使用して レプリケーション・インスタンス・ファイルをアップグレードするの手順に従ってください。
既存のインスタンスのバックアップから補助的インスタンスを作成すると、既存のインスタンス内のすべてのデータベース状態を持つSI複製インスタンスが作成され、おそらく最も一般的なアプリケーションのニーズになります。しかし、補助的インスタンスが新しいデータだけを必要とする状況、例えば新規の顧客にのみレポート・サービスを提供する場合や、古い顧客の履歴データが過剰な手荷物である場合などがあります。この場合、新しいインスタンスを作成し、必要なデータを事前にロードし、データベース・ファイルのレプリケーションを有効にして補助的インスタンスを作成することもできます（更新プロセスではレプリケートおよびジャーナル・データベース領域にのみ更新が適用されるため）、上記の mupip replicate -instance_createコマンドの -supplementary=onフラグを使用したレプリケーションインスタンスファイルのアップグレードの下の手順を実行します。レプリケーション・インスタンス・ファイルをソースから発送して、初めてレシーバー・サーバーを開始するときに必要な -updateresync=filename修飾子を指定します。
B <- A -> P <- Q構成でオリジナルのプライマリの補助的インスタンス P上でSI複製を開始する場合、手順は対応する非補助的インスタンス（この場合はAまたはB）から更新を受信するためにレシーバー・サーバーを開始する（ジャーナル・プールを設定するソース・サーバーを起動した後）必要があることを除いて、非補足的なインスタンスと同様です。同様に、オリジナルのプライマリ補助的インスタンスをシャットダウンする一環として、レシーバー・サーバをシャットダウンしてから（もしソース・サーバが起動している場合）、ソースサーバをシャットダウンします。
GT.Mのレプリケーションでは、レシーバー・サーバーがTCPポートをリッスンし、ソース・サーバーがそのポートに接続することに注意してください。もしレシーバ・サーバがソース・サーバよりも先にない場合、レプリケーションが単純に開始され、ソースからレシーバへの更新がストリームされます。レシーバ・サーバがソース・サーバよりも先にある場合、BCおよびSIレプリケーションではケースが異なります。
BCまたはSIレプリケーションの場合、もしレシーバー・サーバーが -autorollback修飾子で開始されている場合、レシーバー・サーバーは受信インスタンスのオンライン・ロールバックを実行し、オリジナルのインスタンスよりも先に進まないようにして、 データベースからロールオフされるトランザクションのレプリケーションしないトランザクション・ログを作成します。-autorollback修飾子なしで開始すると、ソース・サーバーからロールバックを通知されたレシーバー・サーバーは、コンディションをログに記録して終了し、オペレーターは適切な手順を開始できます。
SIレプリケーションの場合、-noresync修飾子は、レシーバーがソースよりも先であっても、データベースをロールバックしないようにレシーバー・サーバーに指示します。この場合、ソース・サーバーは、2つのインスタンスに共通の最後のジャーナルシーケンス番号からレプリケーションを開始します。
同じレプリケーション・ストリームのソースを別のインスタンスに変更する場合（例えば、Ardmore(アードモア) と Malvern(マルバーン)がクラッシュし、Newtown(ニュータウン) が BrynMawr(ブリンマー)からレプリケーション・ストリームを受け取る例では）、レシーバー・サーバーを正常に開始し（必要に応じて、-autorollbackまたは-noresyncのいずれかを使用）、BrynMawrがそれに接続できるようにします。-autorollbackを使用する代わりに、レシーバー・サーバーを起動する前にmupip journal -rollback -backward -fetchresyncを実行することもできます。
たとえば、Malvern(マルバーン)が{Ardmore(アードモア), BrynMawr(ブリンマー)}のセットから完全に無関係なインスタンス・セット{Pottstown(ポストタウン), Sanatoga(サナトガ)}にSIレプリケーションの受信から切り替える場合など、BCインスタンスの1つのセットから完全な異なるセットへのSIレプリケーションの受信から補助的インスタンスを移行するには。
GT.Mはトリガ定義をマップする領域に保存し、メンテナンス関連の情報をデフォルト領域に保存します。グローバル変数でトリガーを呼び出すには、GT.Mは領域内(in-region)情報を使用しますが、$ZTRIGGER() と MUPIP TRIGGERでは、デフォルト領域のルックアップ情報を検索してトリガー定義を保持する領域を検索します。
レプリケート領域とレプリケートされていない領域を混在させたLMS構成のトリガー・メンテナンス・アクションとスイッチオーバー・プロセスを設計する際に、この点を考慮してください。
デフォルト領域が複製されるが、トリガ定義を格納する領域が複製されないLMS構成を設定するときは、注意が必要です。スイッチオーバーが発生した場合に適切な操作を行うために、複製されていない領域のトリガーが必要な場合は、オリジナルのインスタンスとオリジナルのインスタンスになる可能性がある各複製インスタンスで別々に定義して維持する必要があります。複製インスタンスでトリガを定義または維持するには、次の手順を実行します：
複製インスタンスのレシーバー・サーバーをシャットダウンします。
MUPIP TRIGGERまたは$ZTRIGGER() を使用してトリガー定義を適用します。
デフォルトの領域のシーケンス番号を、オリジナルのインスタンスのデフォルトの領域のシーケンス番号と一致するように設定します。
複製インスタンスのレシーバー・サーバーを再起動します。
オリジナルのシステムと複製システム間のフィルタは、データベース・スキーマの変更を伴うローリング・アップグレードを実行します。システム上のソフトウェアのリビジョンレベルが異なるときに、フィルタは異なるスキーマの下でデータを操作します。
GT.Mはフィルタを呼び出す機能を提供します； ただし、アプリケーションの開発者は、スキーマの変更があった場合に、各アプリケーションのリリース・アップグレードの一部としてフィルタを記述する必要があります。
フィルタはアップグレードされたシステム上に存在し、論理データベースの更新を使用してスキーマを更新してから、それらの更新をデータベースに適用する必要があります。オリジナルまたは複製のどちらかとしてのシステムの状態に応じて、レプリケーションのソース・サーバー（新しいスキーマを古いものへ）または、データベース・レプリケーションのレシーバー・サーバー（古いスキーマを新しいものへ）にフィルタを呼び出す必要があります。フィルターの詳細については、 “フィルター”を参照してください。
もしレプリケーションのWAS_ON状態に気づいた場合は、GT.Mがジャーナリングをオフにした原因を修正し、MUPIP SET-REPLICATION=ONを実行します。
ストレージ・スペースを利用可能にするには、まず不要な非ジャーナリング・データとテンポラリ・データを移動することを検討してください。次に、最後のバックアップよりも前にくるジャーナル・ファイルを移動することを検討してください。現在リンクされているジャーナル・ファイルを移動することは非常に最善の方法です。バックリンクを中断し、オリジナルの場所に戻すことができない限り、ロールバックまたはリカバリはこの不連続部分を越えて戻ることができません。
もしオリジナルの側でレプリケーションWAS_ON状態が発生した場合：
もしソース・サーバーが欠落しているジャーナル・ファイルを参照しない場合、-REPLICATION=ON はダウンタイムなしでレプリケーションを再開します。
もしソース・サーバーに欠落しているジャーナル・ファイルが必要な場合は、REPLBRKNTRANS または NOPREVLINKエラーを出してシャットダウンします。このようなロールバックを実行するための情報が不十分なため、ジャーナリングをオフにした後にロールバックすることはできません。
この場合、次の手順を実行します：
オリジナルのインスタンスのバックアップ（MUPIP BACKUP -BKUPDBJNL=OFF -REPLINST=<bckup_inst>）を取ってください。
複製WAS_ON状態でジャーナリングがオフになっているため、オリジナルのインスタンスをバックアップの開始前の状態にロールバックすることはできません。したがって、オリジナルのインスタンス上のジャーナル・ファイルの前世代のリンクを切断し、レプリケーションを元に戻してください。両方の操作は、MUPIP SET -REPLICATION="ON" で実行できます。
オリジナルのインスタンスのバックアップから複製インスタンスを復元します。<bckup_inst> のインスタンス名を複製インスタンスの名前（MUPIP REPLIC -EDITINST -NAME）に変更します。
復元された複製インスタンスでレプリケーションとジャーナリングを有効にします。MUPIP SET -JOURNAL=filename=<repinst_jnl_location>を使用して、ジャーナル・ファイルのパス名を明示的に指定します（バックアップ・データベースは、オリジナルのインスタンスのジャーナル・ファイルのパス名を持ちます）。
オリジナルのインスタンスのソース・サーバー・プロセスを再起動します。
レプリケートするインスタンスをレシーバー・サーバー（ -UPDATERESYNCはなしで）で開始します。
受信側で複製WAS_ON状態が発生した場合：
MUPIP SET -REPLICATION=ON を実行して、複製のON状態に戻ります。これは、受信側で通常のレプリケーションを再開します。追加の安全性チェックとして、オリジナルのインスタンスのレプリケーションWAS_ON状態中に発生した更新のジャーナル・レコードを抽出し、受信インスタンスにそれらの更新が存在するかどうかをランダムにチェックします。
レプリケーションが正常に再開しない場合（レシーバー・サーバー または 更新プロセスのエラーのため）、次の手順を実行します：
オリジナルのインスタンスのバックアップ（MUPIP BACKUP -BKUPDBJNL=OFF -REPLINST=<bckup_inst>）を取ってください。
オリジナルのインスタンスのバックアップから複製インスタンスを復元します。<bckup_inst> のインスタンス名を複製インスタンスの名前（MUPIP REPLIC -EDITINST -NAME）に変更します。
復元された複製インスタンスでレプリケーションとジャーナリングを有効にします。MUPIP SET -JOURNAL=filename=<repinst_jnl_location>を使用して、ジャーナル・ファイルのパス名を明示的に指定します（バックアップ・データベースは、オリジナルのインスタンスのジャーナル・ファイルのパス名を持ちます）。
オリジナルのインスタンスのソース・サーバー・プロセスを再起動します。通常、ソース・サーバーは依然としてオリジナル側で実行されている可能性があります。
レプリケートするインスタンスをレシーバー・サーバー（ -UPDATERESYNCはなしで）で開始します。
最初にオリジナルのインスタンスの新しい複製インスタンスを設定するか、または、データベースとインスタンス・ファイルが削除された場合に、複製インスタンスを置き換えるには、複製インスタンスをオリジナルのインスタンスのバックアップまたはその複製インスタンスの1つから作成する必要があります。
GT.M V5.5-000以降を実行している場合：
BACKUP -REPLINSTANCEを使用して、データベースとオリジナルのインスタンスの複製インスタンス・ファイルを同時に作成し、複製インスタンスの場所に転送します。発信元の複製インスタンスファイルが新しく作成された場合は、バックアップが少なくとも履歴レコードに含まれていることを確認するために、ソース・サーバーの実行中にそのバックアップを取ってください。
レプリケートするインスタンスの名前を変更するには、MUPIP REPLICATE -EDITINST -NAME=<secondary-instname>を使用します。
-udpateresync なしで複製インスタンスを開始します。
GT.M pre-V5.5-000を実行している場合：
複製インスタンス上に新しい複製インスタンス・ファイルを作成します。
-updateresync修飾子（値が指定されていない）を使用して、この新しい複製インスタンスファイルを使用して複製インスタンスを開始します。
この場合、複製インスタンスのデータベース・ファイルがオリジナルのインスタンスよりも古い可能性があります。レプリケーションを再開するには、オリジナルのインスタンスのデータベースおよびレプリケーション・インスタンス・ファイルのバックアップを転送する必要はありません。
既存の複製インスタンス・ファイルを新しい複製インスタンスファイルで置き換えるには、以下の手順を実行します：
GT.M V5.5-000以降を実行している場合：
レプリケーション・インスタンス・ファイル（BACKUP -REPLINST=</path/to/bkup-orig-repl-inst-file>を含むデータベース・ファイルなし）だけをバックアップし、レプリケート・インスタンスのサイトに転送します。
-updateresync=</path/to/bkup-orig-repl-inst-file>を使用して、複製インスタンスを開始します。
この場合、レシーバ・サーバは、複製インスタンス上のデータベース・ファイル・ヘッダ内の領域シーケンス番号の最大値を取ることにより、現在のインスタンスのジャーナル・シーケンス番号を決定し、入力インスタンス・ファイルを使用して、このジャーナル・シーケンス番号この履歴情報を移行元サーバーと交換します。
GT.M pre-V5.5-000を実行している場合：
複製インスタンス上に新しい複製インスタンス・ファイルを作成します。
-updateresync修飾子（値が指定されていない）を使用して、この新しいインスタンス・ファイルを使用して複製インスタンスを開始します。
P上で：
これが補助的インスタンス・ファイルであることを示すには、MUPIP REPLICATE -INSTANCE_CREATEコマンドで -SUPPLEMENTARY修飾子を使用します。
-UPDOKを指定してP上のソース・サーバーを起動し、P上でローカル更新が有効になっていることを示します。
-UPDATERESYNC=</path/to/bkup-orig-repl-inst-file>修飾子と-RESUMEを指定して、レシーバー・サーバーをP上で開始します。 -RESUME は、AとPが以前に複製されたことを示します。レシーバー・サーバーは、P上のデータベース・ファイル・ヘッダー内のローカル（ストリーム #0）シーケンス番号を調べ、最大値をとってP上の新しいストリームのジャーナル・シーケンス番号を決定します。次に、これをA上のインスタンス・ジャーナル・シーケンス番号として使用してレプリケーションを再開します。
Aで：
BACKUP -REPLINSTANCEを使用して複製インスタンス・ファイルとデータベースを同時にバックアップし、Pに転送します。Aのレプリケーション・インスタンス・ファイルも新しく作成された場合は、ソース・サーバーがオリジナルのインスタンスで実行されている間にバックアップを取ってください。これにより、バックアップされたレプリケーション・インスタンス・ファイルに少なくとも1つの履歴レコードが確実に格納されます。
P上で：
新しい複製インスタンス・ファイルを作成します。これが補助的インスタンス・ファイルであることを示すには、MUPIP REPLICATE -INSTANCE_CREATEコマンドで -SUPPLEMENTARY修飾子を使用します。
データベース・バックアップをAからPにリストアするか、またはMUPIP LOADを使用してデータをロードします。
-UPDOKを指定してP上のソース・サーバーを起動し、P上でローカル更新が有効になっていることを示します。
-UPDATERESYNC=</path/to/bkup-orig-repl-inst-file>修飾子と -INITIALIZEを指定して、レシーバー・サーバーをP上で起動します。-INITIALIZE は、AとPが複製している最初の時刻を示します。
この場合、レシーバー・サーバーは、</path/to/bkup-orig-repl-inst-file>の現在のジャーナル・シーケンス番号を、ジャーナル・レコードの送信を開始するポイントとして使用します。GT.Mは、この値を反映するために、P上のインスタンスファイル内のストリーム #1のストリーム・シーケンス番号を更新します。この時点から、GT.Mは、A上のジャーナル・シーケンス番号をP上のストリーム・ジャーナル・シーケンス番号（たとえば、ストリーム #1）にマッピングします。
P上で：
パッシブ・ソース・サーバーとレシーバー・サーバーをオフにします（アクティブな場合）。
レプリケーションをオフにしてデータベースを停止します。
Aで：
レプリケーション・インスタンス・ファイルとデータベースのバックアップを BACKUP -REPLINSTANCEと共に使用し、それをPに転送します。もしAのインスタンス・ファイルも新しく作成された場合は、ソース・サーバーがオリジナルのインスタンスで実行されている間にバックアップを取ってください。これにより、バックアップされたレプリケーション・インスタンス・ファイルに少なくとも1つの履歴レコードが確実に格納されます。
P上で：
新しいインスタンス・ファイルを作成しないでください。既存のインスタンスファイルを使用して、P上ですでに発生した更新を保存して続けます。
-UPDOKを指定してソース・サーバーを起動して、P上でローカル更新が有効になっていることを示します。
-UPDATERESYNC=</path/to/bkup-orig-repl-inst-file>修飾子と-INITIALIZEを指定してレシーバー・サーバーを開始します。-INITIALIZE は、AとPが複製している最初の時刻を示します。
レシーバー・サーバーは、</path/to/bkup-orig-repl-inst-file> 内の現在のジャーナル・シーケンス番号を、Aがジャーナル・レコードの送信を開始する時点として使用します。GT.Mは、この値を反映するために、P上のインスタンス・ファイル内のストリーム・シーケンス番号（例えば、ストリーム #1）を更新します。今後、A上のジャーナル・シーケンス番号は、P上のストリーム・ジャーナル・シーケンス番号（たとえば、ストリーム #1）にマップされます。
レシーバー・サーバー、パッシブ・ソース・サーバーをシャットダウンし、レプリケーションをオフにして、データベースを停止します。
DSEを開き、DUMP -FILEHEADER -ALLを実行し、それぞれ複製された領域(Region)の領域シーケンス・フィールドを書き留めます。FIND -REGION="*" は、すべての領域(Region)を表示し、FIND -REGION=<領域名>は領域間を切り替えます。すべての領域Seqnoの中で最も高い 領域Seqno を特定します。もしA -> P構成を実行している場合は、すべてのストリームのストリームと領域Seqnoをメモしてください。
グローバル・ディレクトリを変更し、移動する必要のあるデータを再配置して、スキーマを変更します。
DSEを開き、CHANGE -FILEHEADER -REG_SEQNO=<領域seqnoの中で最も高い番号>を実行して、データベース・ファイル・ヘッダーの領域Seqnoフィールドを、手順2で識別された最も高い 領域Seqnoに設定します。もし A->P構成を実行している場合は、CHANGE -FILEHEADER -STRM_NUM=1 -STRM_REG_SEQNO=<hexa> コマンドを実行して、手順2で書き留めたストリームのストリームと領域Seqnoを設定します。
レプリケーションをONにし、パッシブ・ソース・サーバーを起動し、-UPDATERESYNCなしでレシーバー・サーバーを開始します。
GT.Mは中断したポイントからの複製の受信を再開します。
レプリケーションがオンの場合、GT.Mは領域上で発生するすべての更新について、データベース・ファイル・ヘッダーの領域Seqnoフィールドを増分します。レプリケーションがオフの場合、データベースの更新は領域Seqnoフィールドに影響はありません。ステップ4を除いて、他のステップは領域Seqnoフィールドに影響はありません。手順4で領域Seqnoを設定すると、手順1でオフにしたレプリケーションの地点からレプリケーションの受信を再開するようにGT.Mに指示します。
tlsrepl.tar.gz には、2つのデータベースを作成し、それらの間に安全な（TLS / SSL）レプリケーション接続を設定するスクリプトが含まれています。Download tlsrepl.tar.gz をクリック 
してtlsrepl.tar.gzをダウンロードし、以下の指示に従ってください。http://tinco.pair.com/bhaskar/gtm/doc/books/ao/UNIX_manual/tlsrepl.tar.gz から tlsrepl.tar.gz をダウンロードすることもできます。tlsrepl.tar.gz 内のスクリプトは、移動中のレプリケーション・データを暗号化するために必要な一般的な手順を説明するためのものです。プロダクション(本番)環境で暗号化を使用する前に、スクリプトを理解し、適切に調整する必要があります。次の手順では、2つのインスタンスと、それらのインスタンス間にTLSレプリケーション接続をセットアップするために必要な基本フレームワークを作成します。この例で作成されたすべての証明書は、TLSレプリケーション環境での役割を説明するためのものです。実際のアプリケーションでは、TLSの使用に一致する権限を持つCAによって署名された証明書を使用します。
Helenと呼ぶインスタンスの場合：
-
envスクリプトに$gtm_dist と$gtmroutines の値を指定し、次のコマンドを実行します：
$ source ./env Helen
これにより、複製インスタンス名 Helen 用のGT.M環境が作成されます。プロンプトが表示されたら、gtmtls_passwd_Helen のパスワードを入力します。
-
現在のディレクトリと自己署名付きルート証明機関に証明書ディレクトリのセットアップを作成します。
$ ./cert_setup
これにより、$PWD/certs/に 自己署名付きルート証明機関（ca.crt）が作成されます。ca.crt をソース・サーバーとレシーバー・サーバーの両方で使用できるようにする必要があります。プロダクション(本番)環境では、root レベルの証明書を0500のアクセス権を持つディレクトリに、0400のアクセス権を持つ個々のファイルに保存して、権限のないユーザーがアクセスできないようにしてください。
このスクリプトの出力は次のようになります
Generating RSA private key, 512 bit long modulus ...........++++++++++++ ...............++++++++++++ e is 65537 (0x10001) Enter pass phrase for /home/jdoe/certs/ca.key: Verifying - Enter pass phrase for /home/jdoe/certs/ca.key: Enter pass phrase for /home/jdoe/certs/ca.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [US]:US State or Province Name (full name) [Philadelphia]:Philadelphia City (e.g., Malvern) [Malvern]:Malvern Organization Name (eg, company) [FIS]:FIS Organizational Unit Name (eg, section) [GT.M]:GT.M Common Name (e.g. server FQDN or YOUR name) [localhost]:fis-gtm.com Email Address (e.g. helen@gt.m) []:root@gt.m
-
グローバル・ディレクトリとデータベース、たとえば Phil を作成します。
$ ./db_setup
これにより、Helen のリーフレベルの証明書も作成されます。この例を作成するために使用した openssl.conf は、参照用にダウンロードして入手できます。openssl.cnf ファイルが環境およびセキュリティの要件に従って構成されていることを確認します。
このスクリプトの出力は次のようになります：
Generating RSA private key, 512 bit long modulus .++++++++++++ .......++++++++++++ e is 65537 (0x10001) Enter pass phrase for /home/jdoe/certs/Helen.key: [Specify the password that you entered for gtmtls_passwd_Helen] Verifying - Enter pass phrase for /home/jdoe/certs/Helen.key: Enter pass phrase for /home/jdoe/certs/helen.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [US]: State or Province Name (full name) [Philadelphia]:Illinois City (e.g., Malvern) [Malvern]:Chicago Organization Name (eg, company) [FIS]:FIS Organizational Unit Name (eg, section) [GT.M]:GT.M Common Name (e.g. server FQDN or YOUR name) [localhost]:fisglobal.com Ename Address (e.g. helen@gt.m) []:helen@gt.m Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./certs/ca.key: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 14 (0xe) Validity Not Before: Jun 11 14:06:53 2014 GMT Not After : Jun 12 14:06:53 2014 GMT Subject: countryName = US stateOrProvinceName = Illinois organizationName = FIS organizationalUnitName = GT.M commonName = fisglobal.com emailAddress = helen@gt.m X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 96:FD:43:0D:0A:C1:AA:6A:BB:F3:F4:02:D6:1F:0A:49:48:F4:68:52 X509v3 Authority Key Identifier: keyid:DA:78:3F:28:8F:BC:51:78:0C:5F:27:30:6C:C5:FE:B3:65:65:85:C9 Certificate is to be certified until Jun 12 14:06:53 2014 GMT (1 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
-
$gtmcrypt_config ファイルを作成します。参加しているすべてのインスタンスの名前を指定します。
./gen_gc Helen Phil
-
レプリケーションをオンにし、レプリケーション・インスタンス・ファイルを作成します：
$ ./repl_setup
-
オリジナルのインスタンス Helen を開始します：
$ ./originating_start Helen Phil
インスタンス Phil 上で：
-
envスクリプトに$gtm_dist と$gtmroutines の値を指定し、次のコマンドを実行します：
$ source ./env Phil
これにより、複製インスタンス名 Phil のGT.M環境が作成されます。プロンプトが表示されたら、gtmtls_passwd_Phil のパスワードを入力します。
-
グローバル・ディレクトリとデータベース、たとえば Phil を作成します。
$ ./db_setup
これにより、Phil のリーフレベルの証明書も作成されます。この例を作成するために使用した openssl.conf は、参照用にダウンロードして入手できます。openssl.cnf ファイルが環境およびセキュリティの要件に従って構成されていることを確認します。
-
$gtmcrypt_config ファイルを作成します。参加しているすべてのインスタンスの名前を指定します。
./gen_gc Helen Phil
Helen インスタンスで生成された ca.key が インスタンスPhilで使用可能であることを確認します。
-
$gtmcrypt_config ファイルを作成します。参加しているすべてのインスタンスの名前を指定します。
$ ./gen_gc Helen Phil
-
レプリケーションをオンにし、レプリケーション・インスタンス・ファイルを作成します：
$ ./repl_setup
-
複製インスタンスPhilを開始します。
$ ./replicating_start
その後の環境設定では、次のコマンドを使用します：
source ./env Phil or source ./env Helen ./replicating_start or ./originating_start Helen Phil