GT.Mレプリケーションは、複数のデータベース間で論理的に等価性を提供します。継続的なアプリケーションの、可用性、リアルタイムの意思決定支援、ウェアハウス、分析、監査を容易にします。レプリケーションには2つのタイプがあります：
ビジネス継続性[Business Continuity]（BC）レプリケーション
補助インスタンス[Supplementary Instance]（SI）レプリケーション
BC レプリケーションは、記録システムにビジネス継続性を提供します。オリジナルのインスタンスで適用された更新は、ほぼリアルタイムでレプリケーション・インスタンスに複製されます。この一貫性を保証するため、BCレプリケーションでは、複製されたセカンダリインスタンスでローカルに生成されたデータベースの更新が禁止されています。たとえば、インスタンスAとインスタンスBがあり、インスタンスA上で処理されたビジネスロジックをインスタンスBにストリーミングすることができます。これにより、AがダウンするとすぐにBが引き継ぎ、連続性が得られます。BがAと一致する結果を確実に生成するために、BはAにも含まれる重要な状態情報のみを含むことができます。
オリジナルのインスタンスで適用された更新は、ほぼリアルタイムでレプリケーション・インスタンスを16個まで複製し、レプリケーション・インスタンスのそれぞれは、レプリケーション・インスタンスをさらに16個まで複製できます。それぞれのレプリケーション・インスタンスは、さらに16個のレプリケーション・インスタンスなどに複製できます。オリジナル・インスタンスが利用できなくなった場合、下流のインスタンスは、オリジナル・インスタンスに置き換わるインスタンスになり、アプリケーションの利用可能性を保つことができます。
次の図では、Aはオリジナル・プライマリインスタンス、BおよびCはレプリケート・インスタンスです。CはさらにDに複製するために、伝搬するプライマリ・インスタンスです。このBCレプリケーション構成は、B < - A - > C - > D構成と記述することもできます。
BCレプリケーションは、計画外のイベント（システムクラッシュなど）と予定されたイベント（システムやソフトウェアのアップグレードなど）の両方に直面して、1年中無休で24時間利用可能なミッションクリティカルなアプリケーションを対象としています。
BCレプリケーションを使用すると、ミッションクリティカルなアプリケーション用の論理マルチサイト（LMS）レプリケーション構成を作成し、計画外のイベント（システムやデータセンターの障害など）に直面するだけでなく、計画されたイベント（OSのアップグレード、GT.Mのアップグレード、さらにはアプリケーションのアップグレード）に直面するなど、常に対応する機能を備えています。BCレプリケーション構成を導入するには、利用可能なネットワーク容量、運用環境、リスクアセスメント、およびビジネス継続性の要件を考慮する必要があります。
SIレプリケーションは、インスタンスAから別のオリジナルのプライマリ・インスタンスPへのレプリケーションを可能にします。 P は、レプリケーション・ストリームを受信しながら、独自のビジネスロジックを実行し、そのデータベースに独自のその更新をコミットします。次に、Pは独自のレプリケーション・セカンダリ・インスタンスQを持ち、Aはそれ自身のレプリケーション・インスタンスBを持つことができます。 このようなSI レプリケーション構成では、オリジナルのプライマリ・インスタンスAとPだけがビジネスロジックを実行し、データベース更新を計算できます。セカンダリ・インスタンスBおよびQのレプリケートは、オリジナルのプライマリ・インスタンスからのレプリケーション・ストリームの受信および適用のみが許可されます。次の図は、この構成を示しています。
この図では、Aは、複製インスタンスとしてBおよびPを有する元のプライマリ・インスタンスです。Pは、その複製インスタンスとしてQを有する別のオリジナル・プライマリ・インスタンス（補足インスタンス(supplementary instance)）である。このSIレプリケーションは、B <- A -> P -> Q構成として記述することもできます。
SIレプリケーションは、リアルタイムな意思決定支援、ウェアハウス、分析、監査などのユーティリティ・アプリケーションを含む多用途なメカニズムを意図しています。
![[注意]](images/note.jpg) |
注意 |
|---|---|
本稿では、インスタンス{A、B、C ...}は、レコードのシステム（BCレプリケーション）を表し、インスタンス{P、Q、R ...}は、SIレプリケーションを受信するインスタンスを表します。 |
GT.Mのレプリケーションは非同期です。つまり、レプリケーション接続のソースとレシーバーの終端は、進行中のアクティビティがない場合に限り、同じ状態になります。一貫性を維持し、レプリケーション接続を再開するときに復元するために、インスタンスは、ジャーナルシーケンス番号と呼ばれる共通の相互に一貫性のあるインスタンス全体のシリアル番号を維持します。各ジャーナル・シーケンス番号には、更新のソースを示す2つのフィールド、つまり0〜15の値を取ることができるストリーム番号と、ストリーム・シーケンス番号（元のインスタンスの更新のジャーナル・シーケンス番号）のタグが付けられています。データベースファイルへのグローバル変数のマッピングに関係なく、レプリケーションはグローバル変数の名前空間全体を処理するため、異なるデータベースファイルを変更する場合でも、すべての更新がこの番号付けに参加します。
SIレプリケーション・ストリームの受信者ではないオリジナルのプライマリ・インスタンス上では、ジャーナルシーケンス番号とストリームシーケンス番号は同じです。
P のシーケンス番号が 100, 101, 102であると仮定します。もし第1および第3トランザクションがローカルで生成され、第2トランザクションが複製される場合、タグ付けされたジャーナルシーケンス番号は{100,0,10}, {101,1,18}, {102,0,11} のようになります。＊＊＊未訳＊＊＊ 100 と 102 の ストリーム番号 0 は、それらのトランザクションがP上でローカルに生成されることを示し、一方、ストリーム番号 1は、それらのトランザクションがAで生成されたことを示します。 Aによるレプリケーションの再開の一環として、Pはデータベースから {101,1,18}をロールオフする必要があり、データベース更新のシリアライゼーションでも、{102,0,11} をロールオフする必要があることに注意することが重要です。両方ともレプリケートされていないトランザクション・ログ（失われたトランザクションファイルとも呼ばれます）に表示されます。＊＊＊未訳＊＊＊
＊＊＊未訳＊＊＊ Pのシーケンス番号が101と同じトランザクションは、AとBに異なるシーケンス番号18を持ちます。 つまり、Aのジャーナル・シーケンス番号はPのストリーム・シーケンス番号になります。 Pのレプリケーション・インスタンス・ファイルには、GT.Mがこのマッピングを決定できる情報が含まれているため、Pがデータベースから {101,1,18} をロールオフすると、AはMalvernがA.sトランザクション18をロールオフしたことを認識します。 ＊＊＊未訳＊＊＊
もしPがBCレプリケーションを別のインスタンスQに実装すると、タグ付けはQに伝播され、AとPが両方ともダウンすると（たとえば、電気を失うデータセンターに配置されている場合）、BとCはAとPの機能をそれぞれ引き継ぎ、QはAから生成された更新の継続としてBからの複製ストリームの受け入れを開始するために必要なあらゆる同期を実行し、BはPの後継としてQを受け入れる。
LMSグループは、同じオリジナルのプライマリ・インスタンスから更新を受信し、同じ論理状態を表す1つ以上のインスタンスのセットです。GT.Mは、オリジナルのプライマリ・インスタンスの識別情報を各複製インスタンスの複製インスタンスファイルに格納することによって、暗黙的にLMSグループを形成します。LMSグループには2種類あります。
BCグループ：オリジナル・プライマリ・インスタンスがBCインスタンスであるLMSグループ。BCグループは、メンバーとしてBCとSIインスタンスを持つことができます。
SIグループ：オリジナルのプライマリ・インスタンスがSIインスタンスであるLMSグループ。SIグループはメンバーとしてSIインスタンスのみを持つことができ、BCグループのBCメンバーからのみ複製を受信できます。
BCグループのBCメンバーは、ダウンストリームを他のBCおよびSIグループに複製できますが、ところが、SIグループはダウンストリームを他のグループに複製できません。
![[重要]](images/important.jpg) |
重要 |
|---|---|
インスタンスはLMSグループ内で役割を変更できますが、グループ間を移動することはできません。1つのインスタンス/グループのデータを別のグループにロードできます。 |
次の例は、AのBCグループのインスタンスAがQのSIグループのインスタンスQを複製するレプリケーション構成を示しています。
+-----------------+
| + A + |
| | | | |
|B<----| | |---->P|
+--------|--------+
|
|
+--------V--------+
| + Q + |
| | | |
|R<----| |---->S|
+-----------------+
|
注意 |
|---|---|
このレプリケーション構成では、インスタンスBもインスタンスQにレプリケートできます。ただし、インスタンスPは、AのBCグループのSIメンバーであるため、Qのグループのインスタンスに複製できません。 |
GT.Mは、インスタンスの間には距離の制限を課しません。2万キロ離れて（地球の円周40,000キロ）いても同じデータセンター内のローカルローカルでも、インスタンスを配置することができます。
GT.Mは、TCP接続を使用して、ハードウェア、オペレーティングシステム、エンディアンアーキテクチャ[1]、さらにGT.Mリリースの異種スタックを持つインスタンス間で複製します。GT.Mインスタンスは、BCレプリケーション・ストリームを GT.M V5.1-000以降から送信するか、BCレプリケーションストリームを受信することができます。しかし、SIレプリケーションでは、ソースとレシーブの両方がGT.M V5.5-000である必要があります。SIレプリケーションは、GT.MのPOSIX版でのみサポートされています。つまり、OpenVMSのGT.Mではサポートされていません。GT.Mのレプリケーションは、アプリケーションソフトウェアのバージョンが異なるデータベーススキーマを持っている多くのケースを含んでいる異なったアプリケーションソフトウェアのバージョンでの構成でさえも使用することができます。これはまた、安価なシステムの数がいること、GNU/Linuxのような汎用サーバを、組織全体くまなく場所に配置することができることを意味します。インスタンスの複製は、意思決定支援、レポート作成、および分析に使用できます。GT.Mデータベースは暗号化できるため、これらのコモディティ・サーバは、オペレーティングシステムとソフトウェアが保護されている限り、安全なデータセンター以外の環境で使用することができます。
GT.M レプリケーションは、レプリケーションされる領域のために、ジャーナリングが有効でONになっている必要があります。レプリケートされない領域（例えば、グローバル変数が1つのインスタンス上だけに有意義な情報が含まれていて、単にインスタンスが動作しているだけの - プロセスID、一時作業ファイルなどのようなもの）は、レプリケートまたはジャーナルする必要はありません。
GT.Mのレプリケーションメカニズムは、インスタンス間のネットワーク障害が利用しているアプリケーションを停止しないような方法で設計されていることです - それには、高可用性クラスタリングのような技術の限界があります[2]。" in flight " トランザクションの処理のような極端なケースや、ネットワーク障害からのリカバリ後にアップデートのバックログを処理するような一般的なケースに対して適切なメカニズムがあります。それは、不完全な分野においてビジネスの絶対的な継続性を提供することは不可能ですが、LMSの設定は、組織のビジネスニーズに最も良く適合するリスクのレベルに対する投資に一致するアプリケーション構成の選択に柔軟性を与えます。
データベースファイルに適用されるすべてのトランザクションは、そのファイルのデータベース・トランザクション番号をインクリメントします。各ブロックには、更新されたデータベース・トランザクション番号が記録され、ファイルヘッダーの現在のトランザクション・フィールドには、使用する次のトランザクションまたはミニ・トランザクションの値が表示されます。次のデータベースファイルのヘッダーフィールドはすべて、データベースレコード番号を表示します： 最後のレコードバックアップ、最後のデータベースバックアップ、最後のバイトストリームバックアップ、最大TN、および最大TN警告。
データベース・トランザクション番号は現在、符号なし64ビット整数です。
データベース・アクティビティはデータベーストランザクション番号を順番に使用しますが、すべてのトランザクション番号がデータベースブロック内にあるわけではありません。Kill の場合は、データベース・トランザクション番号をインクリメントしますが、以前のデータベーストランザクション番号を持つブロックはデータベースから削除できます。
データベース・トランザクション番号はメモリ内で更新され、定期的に2次ストレージにフラッシュされるため、異常終了の場合、ファイルヘッダー内のディスク上のコピーは多少古くなっている可能性があります。
データベース・トランザクション番号はデータベースファイルに固有のものですが、レプリケーションはレプリケートされたすべての領域(Region)間でトランザクションのシリアル化を強制します。各トランザクションがジャーナル・プールに置かれると、次のジャーナル・シーケンス番号が割り当てられます。レプリケートされたインスタンスのデータベースファイルが更新されると、ファイルヘッダーのRegion Seqnoフィールドに、そのトランザクションのジャーナルシーケンス番号が記録されます。インスタンスのジャーナル・シーケンス番号は、そのインスタンス内のデータベースファイルの最大Region Seqnoです。GT.Mは、処理中にそれらを使用しますが、ジャーナル・ファイルにのみジャーナル・シーケンス番号を格納します。データベース・ファイル・ヘッダーでは、Zqgblmod Seqno と Zqgblmod Trans はジャーナルシーケンス番号です。
複製されていないトランザクション・ログのトランザクションを除き、トランザクションのジャーナル・シーケンス番号は、オリジナルのプライマリ・インスタンスと複製するすべてのセカンダリ・インスタンスのトランザクションを一意に識別します。SIレプリケーションを介して複製されると、ジャーナル・シーケンス番号はストリーム・シーケンス番号（下記参照）になり、下流に伝播され、各トランザクションの一意のIDを維持します。
ジャーナル・シーケンス番号には穴がないことがあります - ジャーナル・シーケンス番号が欠けていると、トランザクション履歴またはデータベース状態を手動で操作する可能性があるなど、異常なデータベース・アクティビティの証拠になります。
ジャーナル・シーケンス番号は、60ビットの符号なし整数です。
SI レプリケーション・ストリームのレシーバーは、レプリケーションを介して受信したトランザクションと、ビジネスロジックからローカルに計算するトランザクションの両方を持ちます。前述したように、ジャーナル・シーケンス番号は一連のデータベース更新を一意に識別できますが、更新のソースを特定することはできません。したがって、ストリーム・シーケンス番号という概念があります。
SIレプリケーション・ストリームの受信者ではないオリジナルのプライマリ・インスタンス上では、ジャーナルシーケンス番号とストリームシーケンス番号は同じです。
SIレプリケーションストリームの受信者であるプライマリ・インスタンスでは、ジャーナル・シーケンス番号は、レプリケーションから受信されたものであれ、ローカルで生成されたものであれ、すべての更新を一意に識別してシリアル化します。ただし、ローカルに生成されたトランザクションのジャーナル・シーケンス番号であるストリーム・シーケンス番号と、複製された更新の場合は、非ゼロの4ビットタグ（つまり値1〜15）とジャーナルシーケンスそれが複製されたシステム上のトランザクションの番号です。これらのストリーム・シーケンス番号は、ダウンストリームの複製セカンダリ・インスタンスに伝播されます。
ストリームシーケンス番号は、64ビットの符号なし整数です。
以下のシナリオを理解しやすくするために、各更新プログラムには、最初に生成されたシステムの接頭部と、そのシステムおよびBC複製セカンダリインスタンスのシーケンス番号が付加されています。
3つのシステムは、最初は役割 O（オリジナルのプライマリ・インスタンス）、R（BCレプリケーション・セカンダリ・インスタンス）および S（SI レプリケーション・ストリームの受信者）で動作します。
|
Ardmore |
BrynMawr |
Malvern |
コメント |
|---|---|---|---|
|
O: ... A95, A96, A97, A98, A99 |
R: ... A95, A96, A97, A98 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38 |
トランザクション番号 A99 のオリジナルのプライマリ・インスタンスとしてのArdmore は、トランザクション番号A98の BCレプリケーション・セカンダリ・インスタンスとして BrynMawr にレプリケートし、トランザクション番号A97を含むSIとしてMalvernに複製し、ローカルで生成された更新が散在します。更新は、before-image ジャーナリングを使用して各インスタンスのジャーナル・ファイルに記録されます。 |
|
Crashes(クラッシュが発生) |
O: ... A95, A96, A97, A98, B61 |
... M34, A95, M35, M36, A96, A97, M37, M38 |
イベントがArdmore を無効にすると、 BrynMawr は A98をデータベース内の最新のトランザクションとして新しいオリジナルのプライマリになり、アプリケーションの処理を開始してビジネスの継続性を維持します。Malvern が BrynMawrよりも先行していないこのケースでは、 Malvern レシーバ・サーバーはArdmore がクラッシュした後でも引き続き動作します。BrynMawr が接続すると、ソース・サーバーとMalvern のレシーバ・サーバーはArdmoreから受け取った更新に関して BrynMawr が Malvern の背後にないことを確認し、 BrynMawr のSIレプリケーション は Ardmore からの複製を中止します。 |
|
- |
O: ... A95, A96, A97, A98, B61, B62 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, B61, M40 |
BrynMawr の補助インスタンス(supplementary instance)として動作するMalvern は、 BrynMawr で処理されたトランザクションを複製し、ローカルで生成された独自の更新も適用します。A98 は Ardmoreで最初に生成されましたが、Malvern はBrynMawr とMalvernの共通点であるため、BrynMawr から A98を受け取りました。 |
|
... A95, A96, A97, A98, A99 |
O: ... A95, A96, A97, A98, B61, B62, B63, B64 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, B61, M40, B62, B63 |
Malvern はBrynMawrの補助インスタンスとして継続し、BrynMawr で処理されたトランザクションを複製し、ローカルで生成された独自のアップデートも適用します。一方、Ardmore は修復され、オンライン化されました。BrynMawr への複製セカンダリ・インスタンスとしての操作を開始するには、トランザクション A99をそのデータベースから非レプリケートトランザクションログにロールオフする必要があります。 |
|
R: ... A95, A96, A97, A98, B61, B62, B63, B64 |
O: ... A95, A96, A97, A98, B61, B62, B63, B64, B65 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, B61, M40, B62, B63, M41, B64 |
レプリケーションされないトランザクション・ログにトランザクションをロールオフさせることで、Ardmore はBrynMawrの複製セカンダリインスタンスとして動作できるようになりました。これは、通常のBC論理マルチサイトの操作です。BrynMawr とMalvernは、プライマリ・インスタンスと補足インスタンス(supplementary instance)を生成し続けています。 |
最後の例では、BrynMawrからSIレプリケーションを開始するときに Malvern が先に進まなかったのに対し、この例では、非同期処理によってレプリケーションストリームを受け取る前にデータベース状態をロールバックする必要があります。
|
Ardmore |
BrynMawr |
Malvern |
コメント |
|---|---|---|---|
|
O: ... A95, A96, A97, A98, A99 |
R: ... A95, A96, A97 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, M40 |
トランザクション番号A99 のオリジナルのプライマリ・インスタンスとしてのArdmoreは、BrynMawr にトランザクション番号 A97のBCレプリケーション・セカンダリ・インスタンスとしてレプリケートし、トランザクション番号A98を含むSIとしてMalvern に複製し、ローカルに生成された更新が散在します。更新は、before-image ジャーナリングを使用して各インスタンスのジャーナル・ファイルに記録されます。 |
|
Crashes(クラッシュが発生) |
O: ... A95, A96, A97 |
... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, M40 |
イベントが Ardmoreを無効にすると、BrynMawr は新しいオリジナルのプライマリになり、A97 はデータベース内の最新のトランザクションとなります。Malvern はデータベース状態が一貫しないため、BrynMawr からの複製をすぐに開始することはできません - BrynMawrは、データベースにA98を持たず、次回の更新は暗黙的にまたは明示的にその不在に依存している可能性があり、M39とM40 を計算するためにA98 に依存している可能性があります。 |
|
- |
O: ... A95, A96, A97, B61, B62 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, B61 |
Malvern が BrynMawr から複製を受け入れるには、BrynMawrがデータベースに持っていないArdmore（この場合はA98）によって生成されたトランザクションと、Ardmoreのトランザクション番号A98以降にローカルで生成および適用される追加のトランザクションをロールオフする必要があります。 [a] このロールバックはMalvern上のmupip journal -rollback -fetchresync操作で実行されます。[b] これらのロールオフされたトランザクション（A98, M39, M40）は、レプリケーションされていないトランザクション・ログに入り、後でアプリケーションコードによって再処理されます。[c] ロールバックが完了すると、MalvernはBrynMawrからの複製の受け入れを開始することができます。[d] BrynMawrがオリジナルのプライマリロールでトランザクションを処理し、ビジネス継続性を提供し、トランザクションB61 と B62をもたらします。 |
|
- |
O: ... A95, A96, A97, B61, B62, B63, B64 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, B61, B62, M39a, M40a, B63 |
BrynMawr の補助インスタンス(supplementary instance)として動作するMalvern は、 BrynMawr で処理されたトランザクションを複製し、ローカルで生成された独自の更新も適用します。M39a と M40a は、以前にデータベースからロールオフされたM39 と M40 と同じアップデートである場合とそうでない場合があることに、注意してください。 |
|
[a] このロールバックはより複雑なので、通常のLMSロールバックよりも多くのデータを必要とする可能性があり、ジャーナルレコードを順番に読み取る必要があります。それは時間がかかることがあります。 [b] オペレーションを自動化するスクリプティングでは、BrynMawrがMalvernの背後にあるかどうかを明示的にテストする必要はありません - それが後ろにある場合、ソースサーバーは接続に失敗し、エラーを報告します。自動シェルスクリプトは、Malvern でロールバックを検出し、BrynMawrによる再接続を試みます。一方、Malvernでは、BrynMawrを接続する前にロールバックを定期的に実行しても問題ありません - それが先行していなければ、ロールバックはノーオペレーションになります。このレプリケーションの特性は、V5.5-000より前のリリースから変更されていません。 [c] GT.Mの責任は、それらをレプリケーションされていないトランザクション・ログに入れると終了します。 [d] 最終的に、ビジネス・ロジックは、ロールオフ・トランザクションを単純に再適用できるかどうか、または他の再処理が必要かどうかを判断する必要があります。GT.M の $ZQGBLMOD()関数は、競合する更新が発生したかどうかを判断する際にアプリケーションコードを支援します。 | |||
上記の例では、Malvern が BrynMawr からのSIレプリケーションの受け入れを一貫性で開始するためには、 BrynMawr よりも先にデータベースがロールバックされている必要があります。アプリケーションの設計が、このロールバックが必要でもなくても望ましくないようなアプリケーションがあるかもしれません。GT.Mは、SIレプリケーションがこのような状況で、トランザクションを未複製トランザクションファイルにロールオフすることなく開始する方法を提供します。
|
Ardmore |
BrynMawr |
Malvern |
コメント |
|---|---|---|---|
|
O: ... A95, A96, A97, A98, A99 |
R: ... A95, A96, A97 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, M40 |
トランザクション番号A99 のオリジナルのプライマリ・インスタンスとしてのArdmoreは、BrynMawr にトランザクション番号 A97のBCレプリケーション・セカンダリ・インスタンスとしてレプリケートし、トランザクション番号A98を含むSIとしてMalvern に複製し、ローカルに生成された更新が散在します。更新は、before-image ジャーナリングを使用して各インスタンスのジャーナル・ファイルに記録されます。 |
|
Crashes(クラッシュが発生) |
O: ... A95, A96, A97, B61, B62 |
... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, M40 |
イベントがArdmoreを無効にすると、BrynMawr は新しい元のプライマリになり、データベース内の最新のトランザクションA97 がアプリケーションロジックの処理を開始します。前の例とは異なり、この場合、アプリケーション設計は、BrynMawrがデータベースにA98を持たず、かつ、MalvernがM39 と M40を計算するためにA98に依存していたとしても、MalvernがBrynMawrからの複製を開始できるように許可します（または必要とします）。 |
|
- |
O: ... A95, A96, A97, B61, B62 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, M40, B61, B62 |
レシーバー・サーバーを-noresyncオプションで起動すると、 MalvernはBrynMawrからSIレプリケーション・ストリームを受信でき、BrynMawr と Malvernが共有する最後の共通トランザクションからレプリケーションが開始されます。BrynMawrでは、A98がB61に先行するのではなく、Malvernで実行されていない、すなわちMalvernがArdmoreによって生成された更新に関してBrynMawrより先行していたことに注意してください。 |
次に、 Ardmore と Malvern が、1つのデータセンターに配置され、別のデータセンターに配置されたBrynMawr と Newtown にBCレプリケーションされた状況を考えてみましょう。最初のデータセンターに障害が発生すると、Ardmore から Malvern へのSIレプリケーションは、BrynMawrからNewtownへのSIレプリケーションに置き換えられます。
|
Ardmore |
BrynMawr |
Malvern |
Newtown |
コメント |
|---|---|---|---|---|
|
O: ... A95, A96, A97, A98, A99 |
R: ... A95, A96, A97, A98 |
S: ... M34, A95, M35, M36, A96, M37, A97, M38 |
R: ... M34, A95, M35, M36, A96, M37 |
トランザクション番号 A99 のオリジナルのプライマリ・インスタンスとしてのArdmore は、トランザクション番号A98の BCレプリケーション・セカンダリ・インスタンスとして BrynMawr にレプリケートし、トランザクション番号A97を含むSIとしてMalvernに複製し、ローカルで生成された更新が散在します。Malvern はNewtownに順番に複製します。 |
|
データセンターに移動 |
O: ... A95, A96, A97, A98, B61, B62 |
データセンターに移動 |
... M34, A95, M35, M36, A96, M37 |
データセンターの停止により ArdmoreとMalvernが無効になると、BrynMawrはA98 をデータベースの最新トランザクションとして新しい起点のプライマリになり、ビジネス継続性を維持するためのアプリケーションロジックの処理を開始します。Newtown は、 BrynMawrからSIレプリケーションストリームを受け取ることができます。これは、受信側がソースより先行していないため、ロールバックを必要としません。 |
|
- |
O: ... A95, A96, A97, A98, B61, B62 |
- |
S: ... M34, A95, M35, M36, A96, M37, A97, A98, N73, B61, N74, B62 |
Newtown はBrynMawrからSIレプリケーションを受信し、ローカルで生成された独自のアップデートも適用します。A97 と A98 は、Ardmoreで最初に生成されましたが、NewtownはBrynMawrから受信します。 Newtown はローカルで生成された更新を計算して適用します。 |
|
... A95, A96, A97, A98, A99 |
O: ... A95, A96, A97, B61, B62, B63, B64 |
... M34, A95, M35, M36, A96, M37, A97, M38 |
S: ... M34, A95, M35, M36, A96, M37, A97, A98, N73, B61, N74, B62, N75, B63, N76, B64 |
BrynMawr と Newtownが、オペレーションでエンタープライズを維持している間、最初のデータセンターが復旧します。ArdmoreはBrynMawrがオリジナルのプライマリ・インスタンスとして動作し始めたときにBrynMawrにレプリケートされなかったデータベース内のトランザクションを持っているため、かつ、MalvernはNewtownに引き継がれたときにNewtownに複製されなかったトランザクションを持っていたので、BrynMawr と NewtownからそれぞれBCレプリケーション・ストリームを受け取る前に、Ardmore と Malvernはデータベースをロールバックし、レプリケートされないトランザクション・ファイルを作成する必要があります。ArdmoreはA98 と A99をロール・オフし、MalvernはA97 と M38をロール・オフします。 |
|
R: ... A95, A96, A97, B61, B62, B63, B64 |
O: ... A95, A96, A97, B61, B62, B63, B64, B65 |
R: ... M34, A95, M35, M36, A96, M37, A97, A98, N73, B61, N74, B62, N75, B63, N76, B64 |
S: ... M34, A95, M35, M36, A96, M37, A97, A98, N73, B61, N74, B62, N75, B63, N76, B64, N77 |
レプリケーションされないトランザクション・ログにトランザクションをロールオフさせることで、Ardmore はBrynMawrの複製セカンダリインスタンスとして動作できるようになりました。これは、通常のBC論理マルチサイトの操作です。BrynMawr とMalvernは、プライマリ・インスタンスと補足インスタンス(supplementary instance)を生成し続けています。Malvernは、そのデータベースからA97をロールオフして、Newtownからそのトランザクションを受け取ります。 |
次の例では、アプリケーションが動作している間に、Ardmoreがデータベースを状態空間にロールバックしているとすると。 mupip journal -rollback-backward -online 機能を使用します。
|
Ardmore |
BrynMawr |
Malvern |
コメント |
|---|---|---|---|
|
O: ... A95, A96, A97, A98, A99 |
R: ... A95, A96, A97 |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, M40 |
トランザクション番号A99 のオリジナルのプライマリ・インスタンスとしてのArdmoreは、BrynMawr にトランザクション番号 A97のBCレプリケーション・セカンダリ・インスタンスとしてレプリケートし、トランザクション番号A98を含むSIとしてMalvern に複製し、ローカルに生成された更新が散在します。更新は、before-image ジャーナリングを使用して各インスタンスのジャーナル・ファイルに記録されます。 |
|
レプリケートされていないトランザクションログに A97 から A99を含む A96にロールバック |
自動的にA96 にロールバックします（レシーバー・サーバーは -autorollbackで開始されたと想定します - 詳細はV5.5-000リリース・ノートを参照してください）。 |
- |
Ardmoreからレプリケーション・ストリームを受け取ったインスタンスは、Ardmoreが -autorollbackでレシーバー・サーバーを起動してオンライン・ロールバックを実行すると、自動的にロールバックするように設定できます。もしMalvernのレシーバー・サーバーがこのように設定されている場合、A97 から M40 をレプリケートされないトランザクション・ログにロールバックします。このシナリオは簡単です。しかし、-noresync 修飾子を使用すると、レシーバー・サーバーをロールバックせずに複製を再開するように構成することができます。このシナリオはここで開発されています。 |
|
O: ... A95, A96, A97a, A98a, A99a |
R: ... A95, A96, A97a, A98a |
S: ... M34, A95, M35, M36, A96, A97, M37, M38, A98, M39, M40, A97a, M41, A98a, M42 |
トランザクション A97a から A99a までは、A97 から A99までの異なるトランザクション（ Ardmore上のレプリケートされていないトランザクションファイルにあり、再処理する必要があります）です。Malvern には、オリジナルの A97 と A98の両方と、A97a と A98a もあります。A99 は Malvernに複製されませんでした - Ardmoreは、複製される前にロールバックされ、 A99aは Malvern にまだ作成されていません（Ardmoreが再びロールバックしない限り間もなくなります）。 |
SIレプリケーションは、GT.MのPOSIX版でのみサポートされています。つまり、OpenVMSのGT.Mではサポートされていません。さらに、V5.5-000以降、GT.MはOpenVMSとPOSIXプラットフォーム間のレプリケーション、またはV5.1-000より前のリリースのGT.Mを使用するPOSIXプラットフォームでのレプリケーションをサポートしていません。GT.M V5.5-000にアップグレードする場合、または、OpenVMSのGT.MからPOSIXプラットフォームのGT.M V5.5-000にアップグレードする場合は、最初に中間段階としてPOSIXプラットフォーム上のGT.M V5.1-000以降にアップグレードしてください。
SIレプリケーションの受信側は、ダウンストリーム伝播のためにBCレプリケーション・ストリームを送信できますが、SIレプリケーションストリームを送信することはできません。したがって、上記の例では、Malvern はArdmore または BrynMawrからSIレプリケーションを受信できる間、BCレプリケーション・ストリームをNewtownに供給でき、BCレプリケーション・ストリームをOxfordに順に供給できます。したがって、Malvern, Newtown または Oxford のいずれも、SIレプリケーション・ストリームを供給することはできません。
また、インスタンスは単一のSIレプリケーション・ストリームしか受信できません。Malvernは Ardmore 以外のインスタンス（またはBrynMawrなどのように、ArdmoreからBCレプリケーションを受け取ったインスタンス）からSIレプリケーションを受け取ることはできません。Newtown またはOxfordは、セカンダリ・インスタンスを複製しており、Malvern.以外の更新プログラムを受け取ることはできません。
インスタンスが供給できるレプリケーション・ストリームの総数は、BCとSIの任意の組み合わせで 16個です。
次の図は、B < - A-> Cとして配備されたBCレプリケーション構成を示しています。背景色が白（上部）はオリジナルのインスタンスを処理するビジネスロジックです、背景色がバラ色（左側）と黄色（右側）はインスタンスを複製しています。点線は、TCP接続を表し、赤い点は、トランザクションの動きを示しています。もし白色(White)が想定外または計画されたイベントでダウンしても、バラ色や黄色のどちらかは、十秒以内にオリジナル インスタンスになることができ、そして他のインスタンスは、新しいオリジナルインスタンスにレプリケートするインスタンスになることができます。白色(White)が復旧すると、それは新しいオリジナルインスタンスにレプリケートするインスタンスとして再稼動します。いくつか最適な将来の時点で、それを希望するときに、白色(White)を再びオリジナルのインスタンスとして作ることができます。
プロセスが白色(White)でトランザクションをコミットする時、GT.Mは、ジャーナルファイルとそれに続くデータベースファイルへの更新レコードを書き込むことと" hardening 硬化" によって耐久性を提供します。同じプロセスはまた、トランザクションコミットの一環としてジャーナルプール(Journal Pool) と呼ばれる共有メモリのエリアへ更新レコードを書き込みますが、しかし、トランザクションをコミットするためにバラ色と黄色は待機しません ( これはインスタンス間のネットワークの障害が白色(White)上のアプリケーション動作を停止しないことを意味します)。2つのソースサーバのプロセス、バラ色と黄色のうち一つは、それらが提供するレプリケーションインスタンス上の受信サーバ(Receiver Server) のプロセスへTCP接続を介し、ジャーナルプール(Journal Pool)とストリームのアップデートから、ジャーナル更新レコードを読み込みます。
通常の条件下で、白色のソースサーバ ストリームは、ジャーナルプールからバラ色と黄色の受信サーバ(Receiver Server)へレコードを更新します。ジャーナルプールは、その最初の作成の後に、展開のない共有メモリセグメントです。もし、レプリケーションインスタンスが追いつく(catch up)必要があるためのデータベースステータスの更新が、もはやジャーナルプールにない場合、レプリケーションインスタンスが、ジャーナルプールから再び来ることが可能な残りの必要な更新のポイントに追いつくまで、ソースサーバーはジャーナルファイルの更新を検出します。図は、ジャーナルファイルからソースサーバプロセスへ曲線でこれを表します。
ソース・サーバ [3] は、アクティブモードまたはパッシブモード の2つのモードうちのいずれかになることができます。
アクティブモードでは、1つのソースサーバーは、そのレプリケーションインスタンスでレシーバサーバに接続し、そして、通信チャネルを介してジャーナルプールから更新レコードを転送します。もしアクティブなソースサーバがそのレシーバサーバに接続されていない場合、それが成功するまで接続が繰り返し試行されます。アクティブなソース・サーバーがれ視バー・サーバーに接続すると、レプリケーションを続行する前に2つのインスタンスが同期していることを確認します。図では、白色のソースサーバは、アクティブモードになっています。アクティブなソースサーバがパッシブモードに切り替えるコマンドを受信する時、そのレシーバサーバとの接続を切断し、それがアクティブになるためのコマンドを受信するまで、"スリープ状態 : goes to sleep" になります。
パッシブモードでは、ソースサーバはスタンバイ状態になります。図では、バラ色と黄色のソースサーバはパッシブモードです。パッシブ ソースサーバがアクティブモードに切り替えるためのコマンドを受信すると、そのレプリケーションインスタンス上で指定されたレシーバサーバとの接続を確立しようとします。
典型的な動作の条件下では、システムやネットワークのボトルネックがない状態で、GT.Mは、オリジナルインスタンスから離れ、そして、サブミリ秒の時間フレームでそのレプリケーションインスタンスに向かって移動するネットワークのケアへ、トランザクションを移動します。ネットワークの通過時間は、次にトランザクションのメッセージがレプリケーションインスタンスに到達するまでにかかる時間で決定されます。それが change-based またはデルタベース(delta-based)のプロトコルを使用しているので、GT.Mのレプリケーションは効率的にネットワーク帯域幅を使用します。さらに、ソースサーバはレシーバサーバが次に解凍(decompression) するバイトストリームを圧縮できます。代わりにネットワークルータは圧縮と解凍(compression and decompression)を実行できます。セキュアなレプリケーションのためにTCP接続を暗号化するスタックやルータで標準的な技術を使用ができます。
バラ色と黄色のインスタンスで、レシーバサーバは白色ソースサーバによって送信された更新レコードを受信し、そして、共有メモリセグメント内にある受信プールにそれらを置きます。ソースとレシーバのサーバプロセスは、受信プールがオーバーフローしないことを保証するためにフロー制御を実装します。更新プロセスは、これらの更新レコードをピックアップし、そして、ジャーナルファイル、データベースファイル、ジャーナルプールにそれらを書き込みます。レプリケーションインスタンス上でアップデートのプロセスは、オリジナルインスタンス上の "アプリケーションロジック(Application Logic) " に類似した操作を実行します。
ヘルパープロセスは、更新プロセスはレプリケーションインスタンス上のデータベースに入ってくるレプリケーションストリームを適用することができるその速度を加速します。
複数のプロセスが同時にデータベースにアクセスする時に、GT.Mデータベースエンジンは、それを管理するために互いに協力し、最高のパフォーマンスを発揮します。したがって、単一の更新プロセスだけでレプリケーションインスタンスより性能が優れる(outperform)オリジナルインスタンス上で、実行するアプリケーションプロセスの数十、数百、数千も可能です。ヘルパープロセスは、より高速なデータベースの更新を適用する更新プロセスを有効にし、それによって維持します。
ヘルパープロセスには2つのタイプがあります。
Reader：リーダー(Reader)・プロセスは、受信プール内の更新レコードを読み取り、データベース・ブロックをグローバル・バッファー・プールにプリフェッチしようとするため、更新プロセスのためにより迅速に使用できます。
Writer：書き込み(Writer)プロセスは、データベースおよびジャーナル・レコードを共有メモリー（グローバルおよびジャーナル・バッファー）からファイル・システムにフラッシュすることにより、更新プロセスを支援します。
ヘルパープロセスの各タイプの確定の数は、スループットを最大にします。実際問題として、レプリケーションインスタンス上のファイルシステムの帯域幅が、そのレプリケーションストリームを提供しているオリジナルインスタンスのそれより等しいかまたは大きい限り、あまりにも多くのヘルパープロセスを持っていることについて、少しも心配する必要はありません。
|
注意 |
|---|---|
|
レプリケーションの間、そのオリジナルインスタンスに遅れをとるレプリケーションインスタンスには他の理由があるかもしれません。ヘルパープロセスは、次のような状況を改善することはできません。
|
フィルタは、目的のスキーマにレプリケーションストリームを変換するコンバータプログラムです。これは、STDINから読み取りとSTDOUTへ書き込み、従来からあるUNIXフィルタとして動作します。Both input and output use the GT.M journal extract format. フィルタは、オリジナルインスタンスまたはレプリケーションインスタンス上で動作することができます。オリジナルインスタンスが、より古いバージョンのアプリケーションである時、フィルタは古いスキーマから新しいスキーマへ更新レコードを変更することができます。オリジナルインスタンスが、より新しいバージョンのアプリケーションである時、フィルタは新しいスキーマから古いスキーマへ更新レコードを変更することができます。古いスキーマのレコードを新しいスキーマに変換するロジックを取得すると、レコードごとのコードがスキャンロジックをロジックに置き換えて、抽出フォーマットを読み込んで更新を抽出し、フィルタを再アセンブルしてフィルタを完成させます。 GT.M抽出フォーマットにレコードを改訂しました。
ローリングアップグレード中に完全な冗長性を確保するために、新しいスキーマから古いスキーマに、トランザクションを変更するフィルタも持つ必要があります。GT.Mはインスタンスの論理的な等価性をチェックし復元するためにジャーナルのシーケンス番号を使用するので、スキーマを変更するフィルタの作成での主な制限は、フィルタがレプリケーションストリーム内のトランザクションの数を変更してはいけないことです。
これが意味すること：
もしレプリケーションストリームがトランザクションに含まれている場合、各入力のトランザクションのために、フィルタは1つと正確に1つの出力トランザクションを生成する必要があります。それは空になるトランザクションを許容します、つまり、データベースの更新をなさないためです。
もしレプリケーションストリームの更新がトランザクションの外部にある場合、それは、ジャーナルシーケンス番号が1つ増加するという点で、トランザクションと見なされます。
もしスキーマの変更が単一のデータベースの更新を必要とする場合、単純に出力ストリームに新しいアップデートを発します。
もしスキーマの変更が、新しいスキーマにデータベースの更新を必要としない場合、単一の空のトランザクションを発します。
もしスキーマの変更が、新しいスキーマに複数のデータベース更新を必要とする場合、トランザクションを作成し、そのトランザクションの内部のすべてのアップデートをパッケージします。
レプリケーション・インスタンス・ファイルは、インスタンスの現在の状態を維持します。また、ローカルで生成されたり、他のインスタンスから受信されたジャーナル・シーケンス番号の履歴のリポジトリとしてもサービスします。
ファイルヘッダー、ソースサーバースロット、および、履歴レコードの3つのセクションが含まれています。
「ファイルヘッダー」セクションには、現在のインスタンスに関する情報（ジャーナルおよびレシーバー・プールのセマフォおよび共有メモリーID、現行インスタンスのジャーナル・シーケンス番号など）が記録されます。
ソースサーバースロットは、ソース・サーバーが開始される各レプリケーションのインスタンスの情報を格納します。スロットには、ソース・サーバーがオリジナルのインスタンス（接続シーケンス番号）に最後に接続されたときの複製インスタンスの名前、最後に送信されたシーケンス番号、およびシーケンス番号が格納されます。
レプリケーション・インスタンス・ファイルには16スロットあります。最初は、すべては使用されていません。複製インスタンスに初めてレプリケートするソースサーバーは、未使用のスロットを使用して情報を格納し、同じレプリケーション・インスタンスにレプリケートするすべての今後のソースサーバープロセスがこの情報を更新します。
もし使用されていないスロットが使用できない場合は、ソースサーバーがインスタンスに複製を開始したときに、インスタンスの複製が最も遅く開始されたスロットが再利用され、以前にそのスロットに格納されていた情報が上書きされます。先取りされた複製インスタンスの後続のmupip replic-sourceは、REPLINSTSECNONEメッセージを生成します。
もしインスタンスが存続期間中に16以上の異なる複製インスタンスに接続しない場合、スロットの先取りは発生しません。
履歴レコードセクションでは、インスタンスの履歴は一連のレコードとして保持されます。インスタンスがオリジナルのインスタンスから複製インスタンスに変わるたびに、または、その逆になるたびに、インスタンスファイルの末尾に新しい履歴レコードが追加されます。例外は、インスタンスファイルの末尾から更新があるときに履歴レコードが削除されるmupip journal -rollbackの一部としてデータベースからロールバックされます。各レコードは、ジャーナル・シーケンス番号の範囲と、それらのジャーナル・レコードを生成したオリジナルのインスタンスの名前を識別します。最初の履歴レコードは、インスタンスの現在のジャーナルシーケンス番号で開始します。
オリジナルのインスタンスがシーケンス番号を複製インスタンスに送信すると、オリジナルのインスタンス名は、両方のインスタンスの複製インスタンスファイル履歴に「ルートプライマリインスタンス名」として記録されます。複製するインスタンスが、別の複製インスタンスの下流のオリジナルのインスタンスとして機能している場合は、同じ規則が適用されます。
この履歴は、2つのインスタンスが接続しようとしたときに両方のインスタンスが同期されるジャーナル・シーケンス番号を決定するために重要です。このジャーナル・シーケンス番号は、インスタンス・ファイルの両方の履歴に戻り、同じオリジナルのインスタンスによって生成された最も早い共有ジャーナル・シーケンス番号を見つけることによって決定されます。もし共有ジャーナルのシーケンス番号が複製インスタンスの現在のジャーナルシーケンス番号と一致する場合、複製インスタンス上のレシーバー。サーバーは通常の複製を続行します。それ以外の場合は、複製インスタンスで mupip journal -rollback -fetchresync を実行して、オリジナルのインスタンスが更新を送信して追いつくことができる共通の同期ポイントにロールバックする必要があります。
|
注意 |
|---|---|
バックアップ内のデータベースファイルのスナップショットと一致するレプリケーション・インスタンス・ファイルのバックアップを取る必要があります。mupip backup -replinstance は、レプリケーション・インスタンス・ファイルのバックアップを作成します。もしレプリケーション・インスタンス・ファイルが破損または削除されている場合は、新しいインスタンス・ファイルを作成し、レプリケート中のインスタンスをバックアップから再作成する必要があります。 |
[1] OpenVMS上のGT.MからBCへのBCの複製は、OpenVMSおよびリトルエンディアンのUNIX / Linuxプラットフォームのインスタンスに対してのみサポートされます。
[2] GT.Mデータベースの複製はクラスタリングと互換性があります。各インスタンスは、1つのノードに障害が発生した場合に別のノードがデータベースを復旧して操作を続ける「ホットウォーム」クラスタになります。GT.M LMSアプリケーションの構成が、クラスタに比べて不測の事態も大きい範囲に直面しても、より良いビジネスの継続性を提供するので、もしクラスタを使用したい場合は、それらと一緒に使用するのではなく、むしろGT.M LMSの構成を考慮してください。
[3] インスタンスで開始された最初のソース・サーバー・プロセスがジャーナル・プールを作成します。