レプリケーション
Related information
概要
TIBCO EBX® リポジトリに保存されたデータは専用のリレーショナルテーブルにミラーリングできるため、SQL 要求やビューによるデータへの直接アクセスが可能になります。
履歴と同様に、このデータレプリケーションはエンドユーザーとクライアントアプリケーションに対して透過的です。特定のアクションにより、データベース内のレプリカへの自動変更がトリガーされます。
-
モデルレベルでレプリケーションをアクティブ化すると、必要な DDL ステートメントが自動的に実行され、データベーススキーマが更新されます。
-
新しい列の作成など、複製されたテーブルに影響するデータモデルの進化も、DDL ステートメントを使用してデータベーススキーマを自動的に更新します。
-
「onCommit」更新モードを使用する場合：EBX® リポジトリ内のデータを更新すると、レプリカデータベーステーブルで関連する挿入、更新、および削除がトリガーされます。
以下も参照してください。:
注意:
複製テーブル：複製されたプライマリデータテーブルを指します。
レプリカテーブル (または レプリカ)：レプリケーションの対象となるデータベーステーブルを指します。
レプリケーションの構成
レプリケーションの有効化
データモデルで を定義するには、エレメント
annotation/appinfo の下のエレメント osd:replication を使用します。各レプリケーションユニットは、特定のデータスペース内の単一のデータセット内のテーブルを指定します。
ネストされたエレメントは次のとおりです。
|
エレメント
|
説明
|
必須
|
|---|---|---|
name
|
レプリケーションユニットの名前。この名前は、現在のデータモデルのレプリケーションユニットを識別します。一意にする必要があります。
|
はい
|
dataSpace
|
このレプリケーションユニットに関連するデータスペースを指定します。スナップショットにすることはできません。
|
はい
|
dataSet
|
このレプリケーションユニットに関連するデータセットを指定します。
|
はい
|
refresh
|
データ同期ポリシーを指定します。可能なポリシーは次のとおりです。
|
はい
|
table/path
|
データベースに複製される現在のデータモデル内のテーブルのパスを指定します。
|
はい
|
table/nameInDatabase
|
データがレプリケートされるデータベース内のテーブルの名前を指定します。この名前は、すべてのレプリケーションユニット間で一意にする必要があります。
|
はい
|
table/element/path
|
データベースに複製されるテーブル内の集計リストのパスを指定します。
|
はい
|
table/element/nameInDatabase
|
集計リストのデータが複製されるデータベース内のテーブルの名前を指定します。この名前は、すべてのレプリケーションユニット間で一意にする必要があります。
|
はい
|
例
<xs:schema>
<xs:annotation>
<xs:appinfo>
<osd:replication>
<name>ProductRef</name>
<dataSpace>ProductReference</dataSpace>
<dataSet>productCatalog</dataSet>
<refresh>onCommit</refresh>
<table>
<path>/root/domain1/tableA</path>
<nameInDatabase>PRODUCT_REF_A</nameInDatabase>
</table>
<table>
<path>/root/domain1/tableB</path>
<nameInDatabase>PRODUCT_REF_B</nameInDatabase>
<element>
<path>/retailers</path>
<nameInDatabase>PRODUCT_REF_B_RETAILERS</nameInDatabase>
</element>
</table>
</osd:replication>
</xs:appinfo>
</xs:annotation>
...
</xs:schema>
注意
-
複製されたテーブルのデータモデルの制限 を参照してください。
-
データモデルのコンパイル時に、指定されたデータセットやデータスペースが現在のリポジトリに存在しない場合は警告が報告されますが、レプリカ テーブルはデータベースに作成されます。指定されたデータスペースとデータセットが作成されると、レプリケーションがアクティブになります。
-
データモデルのコンパイル時に、テーブルレプリケーションが削除された場合、または上記のプロパティの一部が変更された場合、レプリカ テーブルはデータベースから削除され、必要に応じて新しい定義で再作成されます。
特定のフィールドまたはグループでのレプリケーションの無効化
複製されたテーブルの場合、デフォルトの動作では、サポートされているすべてのエレメントが複製されます (複製されたテーブルのデータモデルの制限 を参照)。
データモデルアシスタントを使用するか、基になるデータモデルを編集することで、特定のフィールドまたはグループのレプリケーションを無効にすることができます。
データモデルを編集してフィールドまたはグループのレプリケーションを無効にするには、属性
disable="true" を持つエレメント osd:replication を使用します。
<xs:element name="longDescription" type="xs:string">
<xs:annotation>
<xs:appinfo>
<osd:replication disable="true" />
</xs:appinfo>
</xs:annotation>
</xs:element>
データモデルアシスタントを使用してフィールドまたはグループのレプリケーションを無効にするには、エレメントの
[詳細プロパティ] にある [レプリケーション] プロパティを使用します。
このプロパティがグループに定義されている場合、その子孫すべてに対してレプリケーションが再帰的に無効になります。グループがレプリケーションを無効にすると、子孫に対してレプリケーションを明示的に再度有効にすることはできません。
注意:
フィールドまたはグループを含むテーブルが複製されていない場合、このプロパティは効果がありません。
主キーフィールドのレプリケーションを無効にすることはできません。
SQL を使用したレプリカテーブルへのアクセス
データベース内のレプリカテーブルの検索
複製された EBX® テーブルごとに、対応するテーブルが RDBMS に生成されます。EBX® ユーザーインターフェイスを使用して、テーブルのドキュメントペインをクリックすると、このデータベーステーブルの名前を見つけることができます。RDBMS のテーブルには、次の追加の技術列が含まれています。
-
T_CREATOR_ID：レコードを作成したユーザーの参照 -
T_LAST_USER_ID：レコードを最後に更新したユーザーの参照 -
T_CREATION_DATE：レコードの作成日 -
T_LAST_WRITE：レコードの最終変更時刻
T_CREATOR_ID 列と T_LAST_USER_ID 列の最大長は 320 文字です。したがって、EBX® ディレクトリで定義されているユーザーの識別子は、この制限よりも短い最大長である必要があります。
アクセス制限
レプリカデータベーステーブルには、読み取り専用モードでのみ直接アクセスする必要があります。EBX® が使用するユーザーを除くすべてのデータベースユーザーへの書き込みアクセスをブロックするのは、データベース管理者の責任です。
以下も参照してください。:
SQL 読み取り
適切に管理された、できれば短期間のトランザクションでは、直接 SQL 読み取りが可能です。ただし、このようなアクセスでは、EBX® 権限は考慮されません。そのため、読み取りを実行する権限が付与されたアプリケーションは、他の認証プロセスと権限を通じて信頼される必要があります。
「オンデマンド」レプリケーション更新のリクエスト
「onDemand」更新ポリシーでは、複製されたテーブルデータを更新するための明示的な要求が必要です。
レプリケーションの更新を要求する方法はいくつかあります。
-
ユーザーインターフェイス：データセットアクションメニューで、グループ「レプリケーション」の下にあるアクション「レプリカの更新」を使用して、レプリケーション更新ウィザードを起動します。
-
データ サービス：レプリケーション更新データサービス操作を使用します。詳細については、データサービスの レプリケーションの更新 を参照してください。
-
Java API: レプリケーションユニットの更新を開始するには、
ReplicationUnitAPI のReplicationUnit.performRefreshメソッドを呼び出します。
複製の影響と限界
レプリケーション機能には、以下に示すように、いくつかの既知の制限と副作用があります。レプリケーションを使用する場合は、このセクションを注意深く読み、質問があれば Cloud Software Group, Inc. のサポートに問い合わせることを強くお勧めします。
レプリケーションがサポートされているデータベースについては、サポートされるデータベース を参照してください。
検証
レプリケーションを有効にすると、一部の EBX® データモデル制約がブロック制約になります。詳細については、構造上の制約 を参照してください。
複製されたテーブルのデータモデルの制限
複製されたテーブルを含むデータモデルには、いくつかの制限が適用されます。
-
指定されたデータセットがルートデータセットではない場合、またはまだ作成されていない場合、データセットの継承は「onCommit」更新ポリシーではサポートされません。詳細については、データセットの継承 を参照してください。
-
フィールド継承も、「onDemand」更新ポリシーでのみサポートされます。つまり、データモデルのコンパイル時に、更新モードが「onCommit」で、レプリケートされるテーブルに継承されたフィールドがある場合、エラーが報告されます。詳細については、継承されたフィールド を参照してください。
-
計算された値は無視されます。
-
リンクされたフィールドは無視されます。
-
集約リストには、別の集約リストの下にある集約リストと、ターミナルグループの下にある集約リストの 2 種類があります。このような集約リストを含むデータモデルは使用できますが、これらのリストは無視されます (複製されません)。
-
ユーザー定義属性はサポートされていません。レプリケーションユニットにユーザー定義属性が含まれている場合、コンパイルエラーが発生します。データモデルの進化は、関係するテーブルにすでに含まれているデータに応じて、基盤となる RDBMS によって制約される場合もあります。
以下も参照してください。:
データベース構成
更新操作は、前回の更新以降に変更された (作成と削除に関して) ソーステーブルの行のみを送信するように最適化されています。ただし、交換されるデータの量によっては、集中的な操作となり、大規模なトランザクションが必要になる場合があります。特に、最初の更新操作では、多数の行が関係する可能性があります。このようなトランザクションが最適な状態で実行されるように、データベースを適切に構成する必要があります。
例：Oracle の場合
-
レプリケーション ユニット内のすべてのレプリカ テーブルの大部分が 'UNDO' テーブルスペースに収まるようにする必要があります。
-
最小限のディスク アクセスでトランザクションを実行できるように、バッファーキャッシュに十分なスペースを確保することをお勧めします。
-
これらのトランザクションが 'db\_writer' プロセスを待機することを回避するために、十分な大きさの 'REDO' ロググループをプロビジョニングすることをお勧めします。
分散データ配信 (D3)
レプリケーションは、D3 プライマリおよびレプリカ配信データスペースの両方で利用できます。プライマリデータスペースでは、レプリケーションの動作は標準のセマンティックデータスペースと同じですが、レプリカデータスペースでは、レプリケートされたコンテンツは最後のブロードキャストスナップショットのコンテンツになります。
レプリカ配信データスペースでは、いくつかの制限が発生します。
-
データモデルで定義された更新ポリシーは、上記の動作には影響しません。レプリケーションは常にスナップショットで実行されます。
-
アクション項目
レプリカの更新は使用できません。 -
ReplicationUnit.performRefreshメソッドを呼び出すことはできません。
以下も参照してください。:
レプリケーションのその他の制限
-
継承の場合、レプリカレコードフィールドは「継承値」フラグ (
AdaptationValue.INHERIT_VALUE) を保持できません。このような場合は、継承された値のみが保持されます。より一般的には、継承状態と上書き状態を区別することはできません。