ジオデータベース レプリケーションはトラディショナル バージョニングに基づいて構築されています。レプリカの作成時に、複製元のエンタープライズ ジオデータベースと複製先のエンタープライズ ジオデータベースのバージョンがレプリカ バージョンとして設定されます。これらのレプリカ バージョンに対する変更は、レプリカの同期の過程で交換されます。複製元と複製先のレプリカ バージョンはリンクされているため、ジオデータベース レプリケーションはバージョン ツリーを複数のジオデータベースに拡張するための手段と考えることができます。
DEFAULT バージョンまたは名前付きバージョンは、親レプリカまたは子レプリカのレプリカ バージョンとして使用することができます。複数のレプリカが同じレプリカ バージョンを共有することも可能です。
一方向レプリカおよび双方向レプリカ
次の図は、一方向レプリカと双方向レプリカのレプリカ バージョンを示しています。双方向レプリケーションの場合、親レプリカはレプリカ バージョンとして名前付きバージョン RV1 を使用します。一方向レプリケーションの例における親レプリカは、レプリカ バージョンとして名前付きバージョン RV2 を使用します。
以下の例の図では、エンタープライズ ジオデータベースにホストされている 2 つの子レプリカのレプリカ バージョンには、DEFAULT バージョンが使用されています。レプリカ バージョンは、レプリケーションに使用される点を除いて、他のバージョンと同じです。ファイル ジオデータベースはバージョニングに対応していないため、一方向レプリカの子ジオデータベースでレプリカ バージョンが作成されません。
メモ:
下の図に示されたいずれかのエンタープライズ ジオデータベースで名前付きバージョンをレプリカ バージョンとして使用することもできます。
チェックアウト レプリカ
チェックアウト/チェックイン レプリケーションでは、バージョン対応データとバージョン非対応データの両方を複製することができます。バージョン対応データを使用したチェックアウト レプリカでは、子がエンタープライズ ジオデータベースの場合に、新しい名前付きバージョンが子のレプリカ バージョンとして作成されます。
また、チェックアウト/チェックイン レプリケーションの場合は、ファイル ジオデータベースで子レプリカをホストすることもできます。これらのジオデータベース タイプではバージョニングがサポートされないため、子レプリカのレプリカ バージョンは作成されません。これは、バージョン非対応データのチェックアウトの場合も同じです。これらのシナリオでは、同期の際に送信する変更を判断するために、別のロジックが使用されます。
チェックアウト/チェックイン レプリケーションでは、レプリカの名前で新しいバージョンが作成されます。ユーザー名とレプリカ名の組み合わせは、ジオデータベースにおいて一意でなければなりません。たとえば、ユーザー 1 とユーザー 2 はそれぞれ MyReplica という名前のレプリカを作成できますが、これはレプリカのフルネームが user1.MyReplica と user2.MyReplica と設定されるためです。しかし、ユーザー 1 が MyReplica という名前で複数のレプリカを作成するとレプリカ名が一意にならないため、同じユーザーが同じ名前で複数のレプリカを作成することはできません。
下の図は、チェックアウト/チェックイン レプリカとそのレプリカ バージョンの 2 つの例を示しています。一方の親レプリカがレプリカ バージョンとしてバージョン RV1 を使用し、もう一方の親レプリカがレプリカ バージョンとしてバージョン RV2 を使用しています。一方の子レプリカがファイル ジオデータベースでホストされており、もう一方の子レプリカがエンタープライズ ジオデータベースでホストされています。子レプリカをホストしているエンタープライズ ジオデータベースでは、RV2 が自動的に作成され、作成中にレプリカ バージョンとして設定されています。このレプリカ バージョンの名前 RV2 は、該当するレプリカの名前から取得されています。このレプリカ バージョンでは、子に対する編集が行われ、後から親と同期されます。
詳細:
チェックアウト/チェックイン レプリカでは、作成時に同期バージョンが親レプリカのジオデータベースに追加されます。同期バージョンはレプリカ バージョンの子バージョンですが、同期処理実行時にのみ使用されるため、この図には示されていません。詳細については、「同期とバージョニング」をご参照ください。
履歴管理を使用してレプリカの変更を追跡
一方向レプリケーションの場合のみ、バージョニングの代わりに履歴管理を使用して、レプリカの変更内容を追跡することができます。このオプションを使用する場合、親ジオデータベースは、DEFAULT バージョンを参照しているエンタープライズ ジオデータベースでなければなりません。この方法でレプリケーションを管理する利点は、レプリカの同期プロセスと、リコンサイル、ポスト、圧縮などのプロセスをそれぞれ独立したプロセスとして運用できることです。
バージョニングを使用して変更を追跡する場合には、レプリカ バージョンなどのシステム バージョンが作成されます。このようなシステム バージョンでは、効果的な圧縮を実現するために、定期的に同期を行う必要があります。履歴管理を使用してレプリカの変更を追跡する場合、システム バージョンは作成されません。したがって、バージョニングの、リコンサイル、ポストなどのプロセスはレプリケーションの影響を受けず、バージョン管理とレプリケーション管理がそれぞれ独立したものになります。これによって、同期のスケジュールもより柔軟に設定できます。
下の図では、エンタープライズ ジオデータベース間の履歴管理を使用する親から子への一方向のレプリケーションが示されており、ここではエンタープライズ ジオデータベース内の親レプリカと子レプリカの両方のレプリカ バージョンにデフォルト バージョンが使用されています。ファイル ジオデータベースはバージョニングに対応していないため、子ファイル ジオデータベースでレプリカ バージョンが作成されません。
両方のジオデータベースがエンタープライズ ジオデータベースの場合は、子から親への一方向レプリケーションも使用できます。この場合、子レプリカのレプリカ バージョンは DEFAULT バージョンでなければなりません。
