ヘッダーをスキップ
Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド
リリース11.2.1
B56053-02
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

9 レプリケーション・スキームの定義

この章では、アクティブ・スタンバイ・ペアではないレプリケーション・スキームの定義方法について説明します。アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義の詳細は、第3章「アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義」を参照してください。キャッシュ・グループがあるデータベースをレプリケートする場合は、第5章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

レプリケーションに必要な帯域幅の量を減らす方法については、「レプリケートの通信量の圧縮」を参照してください。

列が異なる位置にある表やパーティションの数が異なる表をレプリケートする方法については、「様々な定義を持つ表のレプリケート」を参照してください。

この章の内容は次のとおりです。

高可用性システムの設計

すべてのレプリケーション・スキームの主要な目的は、次のとおりです。

高可用性システムでは、マスター・データベースに影響を与える可能性がある障害が発生しても、サブスクライバ・データベースは影響を受けないようにする必要があります。最低限、マスターとサブスクライバは別々のマシンに配置する必要があります。一部のアプリケーションでは、個別の電源を供給できる環境にサブスクライバを配置する必要がある場合もあります。場合によっては、完全に別のサイトにサブスクライバを配置する必要もあります。

この章では、「レプリケーション・スキームのタイプ」で説明している次のレプリケーション・スキームについて検討します。

データベース全体をレプリケートするか、データベースの要素を選択してレプリケートするかについても検討してください。また、レプリケーション・スキームにおけるサブスクライバの数についても検討してください。単方向および伝播レプリケーション・スキームでは、サブスクライバの数を選択できます。

この項の後半では、次の内容について説明します。

レプリケーションを使用したオンラインによるアップグレードの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のレプリケーションを使用したオンラインによるアップグレードの実行に関する説明とアクティブ・スタンバイ・ペアのレプリケーションを使用したオンラインによるアップグレードの実行に関する説明を参照してください。

フェイルオーバーおよびリカバリの使用例の検討

レプリケーション・スキームを計画する場合は、すべてのフェイルオーバーおよびリカバリの使用例を検討してください。たとえば、通常、サブスクライバで発生した障害は、マスター・データベースに接続しているアプリケーションには影響が及ばないため、ユーザー・サービスを中断せずにリカバリできます。マスター・データベースで障害が発生した場合は、アプリケーションのロードをサブスクライバにリダイレクトし、中断なしに、または最小限の中断でサービスを続行するための方法が必要です。通常、この処理は、クラスタ・マネージャまたはカスタム・ソフトウェアによって行われます。このソフトウェアは、障害を検出し、障害が発生したデータベースからそのサブスクライバの1つにユーザーまたはアプリケーションをリダイレクトして、障害が発生したデータベースのリカバリを管理するように設計されています。第11章「データベースのフェイルオーバーおよびリカバリの管理」を参照してください。

フェイルオーバー方法を計画する場合は、マスターの役割を引き受けるサブスクライバおよび対象ユーザーまたはアプリケーションについて検討してください。リカバリの要件についても検討してください。たとえば、障害が発生したマスターがそのデータベースを最新のサブスクライバからリカバリできる必要があること、すべてのサブスクライバをそのマスターからリカバリできる必要があること、などです。データベース全体をレプリケートする双方向スキームでは、障害が発生したマスターの自動リストアを利用できます。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。

図9-1に示す、単方向にレプリケートされるデータベースの障害例について考えてみます。マスターで障害が発生した場合、アプリケーションは、サブスクライバからリカバリされるまでデータベースにアクセスできません。ALTER REPLICATION文を使用してサブスクライバ・データベースをマスターとして再定義しないかぎり、アプリケーションの接続またはユーザー・ロードをサブスクライバに切り替えることはできません。「マスター・データベースの交換」を参照してください。

図9-1 単方向スキームでのマスターのリカバリ

図9-1の説明が続きます。
「図9-1 単方向スキームでのマスターのリカバリ」の説明

図9-2に、データベース全体がレプリケートされる双方向の分散ワークロード・スキームを示します。このタイプのレプリケーション・スキームでフェイルオーバーが発生した場合、障害が発生したデータベース上のアプリケーションを使用していたユーザーは、影響を受けなかったデータベース上のアプリケーションに移動されます。リカバリが完了すると、リカバリしたデータベース上のアプリケーションにワークロードを再分散できます。

図9-2 分散ワークロード・スキームでのマスターのリカバリ

図9-2の説明が続きます。
「図9-2 分散ワークロード・スキームでのマスターのリカバリ」の説明

同様に、分割ワークロード・スキームのユーザーは、障害が発生したデータベースから影響を受けなかったデータベースに移動する必要があります。分割ワークロード・スキームではデータベース・レベルでレプリケーションが行われないため、ALTER REPLICATION文を使用して新しいマスター・データベースを設定する必要があります。「マスター・データベースの交換」を参照してください。リカバリが完了すると、リカバリしたマスター・データベースにユーザーを戻すことができます。

伝播レプリケーション・スキームでも、マスターまたはプロパゲータで障害が発生した場合は、ALTER REPLICATION文を使用して新しいマスターまたは新しいプロパゲータを設定する必要があります。レプリケーション・スキームで2つのプロパゲータが定義されていると、高可用性が実現されます。2つのプロパゲータが構成された伝播レプリケーション・スキームの例は、図1-11を参照してください。

パフォーマンスとリカバリのトレードオフについての判断

レプリケーション・スキームの設計時に、フェイルオーバーおよびリカバリの複雑さとパフォーマンスの効率を比較してください。フェイルオーバーおよびリカバリを複雑にする要因には、マスターをそのサブスクライバと接続するネットワーク・トポロジ、レプリケーション・スキームの複雑さなどがあります。たとえば、選択した要素が異なるサブスクライバにレプリケートされるマスターをリカバリするより、1つのサブスクライバに完全にレプリケートされるマスターをリカバリする方がより簡単です。

レプリケーションは、非同期（デフォルト）、RETURN RECEIPTサービスによる半同期、またはRETURN TWOSAFEサービスによる完全同期で動作するように構成できます。データがマスターおよびサブスクライバの両方のデータベースで一貫していることをより高いレベルの信頼性を持って保証するには、RETURNサービスを選択します。非同期モード（デフォルト）を使用するか、RETURN RECEIPTモードまたはRETURN TWOSAFEモードを構成するかは、必要とする信頼性の程度および許容できるパフォーマンスのトレードオフによって決まります。

表9-1に、非同期のレプリケーション、RETURN RECEIPTサービスおよびRETURN TWOSAFEサービスにおけるパフォーマンスおよびリカバリのトレードオフの概要を示します。

表9-1 パフォーマンスとリカバリのトレードオフ

動作のタイプ 非同期のレプリケーション（デフォルト） RETURN RECEIPT RETURN TWOSAFE

コミット順序

各トランザクションは最初にマスター・データベースでコミットされます。

各トランザクションは最初にマスター・データベースでコミットされます。

各トランザクションは最初にサブスクライバ・データベースでコミットされます。

マスターでのパフォーマンス

トランザクション間の待機時間またはマスターでコミットされるまでの待機時間がないため、レスポンス時間が最も短く、スループットも最適になります。

非同期と比較すると、レスポンス時間は長くなり、スループットは低くなります。

コミット後のネットワークのラウンドトリップ中にアプリケーションはブロックされます。レプリケート対象のトランザクションがシリアライズされる程度は、非同期レプリケーションでの場合より大きいため、結果としてスループットが低くなります。

レスポンス時間が最も長く、スループットも最も低くなります。

マスターでのコミットに先立って行われるネットワークのラウンドトリップおよびサブスクライバでのリモート・コミットの期間中に、アプリケーションがブロックされます。トランザクションは完全にシリアライズされ、結果としてスループットが最も低くなります。

実行時エラーの影響

トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。

トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。

トランザクションは最初にサブスクライバ・データベースでコミットされるため、マスターでのコミット時にエラーが発生した場合は、マスターを手動で修正するか、または破棄してからサブスクライバ・データベースからリカバリする必要があります。

マスターでの障害発生後のフェイルオーバー

マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。

マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。

マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバは少なくともマスターの最新の状態になります。また、サブスクライバにレプリケートされたトランザクションをマスターでコミットする前にマスターで障害が発生した場合は、サブスクライバをマスターより先行させることもできます。

2つのRETURNサービス間のパフォーマンスとリカバリのトレードオフに加えて、次のことも検討する必要があります。

  • RETURN RECEIPTは多くの構成で使用できますが、RETURN TWOSAFEは双方向構成またはアクティブ・スタンバイ・ペアでのみ使用できます。

  • RETURN TWOSAFEでは、サブスクライバ・データベースへのトランザクションのレプリケート時にタイムアウトなどのエラーが発生した場合にマスター・データベースで実行されるローカル・アクションを指定できます。

アプリケーションでRETURN RECEIPTまたはRETURN TWOSAFEのいずれかに構成された表を更新する場合、トランザクションはRETURN RECEIPTまたはRETURN TWOSAFEとして分類されます。RETURN RECEIPTまたはRETURN TWOSAFEとして分類されたトランザクションは、終了前にレプリケーション・スキームが変更された場合でも、そのままの状態が維持されます。

RETURNサービスの詳細は、「RETURNサービスの使用」を参照してください。

ワークロードの分散

アプリケーションのワークロードを分散し、限られた数のサーバー・マシンを最大限利用できるようにデータベースを構成することを検討してください。たとえば、各サーバーが個別にマスター・データベースおよびサブスクライバ・データベースとして機能するのではなく、マスターおよびサブスクライバの両方として機能するように双方向の分散ワークロード・レプリケーション・スキームでデータベースを構成する方が、より効率的で経済的です。ただし、分散ワークロード・スキームは、主にデータベースから読取りを行うアプリケーションで最も効率的に機能します。データベースの同じ要素に頻繁に書込みを行うアプリケーションに対して分散ワークロード・スキームを実装すると、パフォーマンスが低下し、更新競合を回避または管理するための解決方法を実装する必要がある可能性があります（第14章「レプリケーション競合の解消」を参照）。

レプリケーション・スキームの定義

レプリケーション・スキームを設計した後、SQL文CREATE REPLICATIONを使用してそのスキームをデータベースに適用できます。CREATE REPLICATION文を使用するには、ADMIN権限が必要です。

表9-2に、レプリケーション・スキームのコンポーネントおよびこの章の内容に関連する句を示します。CREATE REPLICATION文の完全な構文は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。

表9-2 レプリケーション・スキームのコンポーネント

コンポーネント 参照先

CREATE REPLICATION Owner.SchemeName

「レプリケーション・スキームおよび表の所有者」

ELEMENT ElementName ElementType

「レプリケーション要素の定義」

[CheckConflicts]

「表要素に対するレプリケーション競合の確認」

{MASTER|PROPAGATOR} DatabaseName ON "HostName"

「データベース名」

[TRANSMIT {NONDURABLE|DURABLE}]

「データ・ストア要素に対する送信永続性の設定」

SUBSCRIBER DatabaseName ON "HostName"

「データベース名」

[ReturnServiceAttribute]

「RETURNサービスの使用」

INCLUDE|EXCLUDE

「データ・ストア要素の定義」

STORE DatabaseName DataStoreAttributes

「STORE属性の設定」

[NetworkOperation]

「ネットワーク操作の構成」


注意:

CREATE REPLICATION文でのネーミング・エラーは、多くの場合、解決が困難であるため、要素名、データベース名、ホスト名に間違いがないよう時間をかけて十分に確認してください。

データベースで使用されるレプリケーション・スキームは、TTREPシステム表に示され、システムを再起動しても有効です。TTREPシステム表の内容は直接変更できません。レプリケーション・スキームを変更するには、ALTER REPLICATION文を使用します。TTREP表の詳細は、Oracle TimesTen In-Memory Databaseのシステム表および制限に関するマニュアルを参照してください。

レプリケーション・スキームおよび表の所有者

レプリケーション・スキームとレプリケーション表の所有者および名前は、マスターおよびサブスクライバの両方のデータベースで同じである必要があります。すべてのデータベースで所有者を共通にするには、CREATE REPLICATION文にレプリケーション・スキーム名とともに所有者名を明示的に指定します。

たとえば、repschemeという名前のレプリケーション・スキームにreplという名前の所有者を割り当てる場合、CREATE REPLICATION文の先頭行は次のようになります。

CREATE REPLICATION rep1.repscheme

レプリケーション・スキームおよびレプリケート表の名前から所有者を省略した場合、デフォルトの所有者名（リクエスト・ユーザーのログイン名またはDSNのUID一般接続属性で設定されている名前）がかわりに使用されます。所有者名がデータベース間で異なっている場合、レプリケーション・スキームは機能しません。

データベース名

レプリケーション・スキームにおけるデータベースの役割は、次のとおりです。

  • マスター: アプリケーションは、マスター・データベースを更新します。マスターは、更新をプロパゲータに送信するか、またはサブスクライバに直接送信します。

  • プロパゲータ: プロパゲータ・データベースは、マスター・データベースから更新を受信し、受信した更新をサブスクライバ・データベースに送信します。

  • サブスクライバ: サブスクライバは、プロパゲータまたはマスターから更新を受信します。

レプリケーション・スキームを定義する前に、そのレプリケーション・スキームのデータベースのデータ・ソース名（DSN）を定義する必要があります。LinuxまたはUNIXの場合は、odbc.iniファイルを作成します。Windowsの場合は、ODBCアドミニストレータを使用し、データベースを指定して接続属性を設定します。例については、「手順1: マスターおよびサブスクライバのDSNの作成」を参照してください。

レプリケーション・スキームで指定された各データベースの名前は、DSN定義内のDataStoreデータ・ストア属性で指定された、パスを除くデータベース・ファイル名の接頭辞と一致する必要があります。Data Source Nameデータ・ストア属性で指定された名前を使用しているレプリケーション・スキームは機能しません。混乱を避けるには、各DSN定義内のDataStoreデータ・ストア属性とData Source Nameデータ・ストア属性に同じ名前を使用します。たとえば、データベースのパスがdirectory/subdirectory/foo.ds0の場合、使用するデータベース名はfooになります。

レプリケーション要素の定義

レプリケーション・スキームは、1つ以上のELEMENT記述で構成されます。ELEMENT記述には、要素の名前、そのタイプ（DATASTORE、TABLEまたはSEQUENCE）、更新が行われるマスター・データベース、更新がレプリケートされるサブスクライバ・データベースが含まれます。

キャッシュ・グループがあるデータベースをレプリケートする場合は、第5章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

要素の制限は、次のとおりです。

複数のサブスクライバ・スキームに要素を定義する正しい方法については、「RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・スキーム」を参照してください。要素を伝播する正しい方法については、「伝播スキーム」を参照してください。

後でALTER REPLICATION文を使用して要素の削除または変更を行う場合は、スキーム内の各要素の名前を使用して要素を識別できます。

既存のレプリケーション・スキームに表、順序およびデータベースを追加できます。「レプリケーション・スキームの変更」を参照してください。既存のレプリケーション・スキームの一部であるデータベースから表または順序を削除できます。「レプリケーション・スキームからの表または順序の削除」を参照してください。

この項の後半では、次の内容について説明します。

データ・ストア要素の定義

マスター・データベース（masterds）のすべての内容をサブスクライバ・データベース（subscriberds）にレプリケートする場合、ELEMENT記述（ds1）は次のようになります。

ELEMENT ds1 DATASTORE
  MASTER masterds ON "system1"
  SUBSCRIBER subscriberds ON "system2"

データベース・ホストは、hostnameオペレーティング・システム・コマンドから返されるホスト名で識別してください。特殊文字が含まれているホスト名は、二重引用符（"）で囲む必要があります。

CREATE REPLICATION文のEXCLUDE TABLE句およびEXCLUDE SEQUENCE句を使用すると、データ・ストア要素からの特定の表および順序の除外を選択できます。EXCLUDE句を使用すると、EXCLUDE句で指定されたオブジェクトを除くデータベース全体が、要素内のすべてのサブスクライバにレプリケートされます。1つの要素記述で使用できるEXCLUDE TABLE句およびEXCLUDE SEQUENCE句はそれぞれ1つのみです。たとえば、この要素記述では2つの表および1つの順序が除外されます。

ELEMENT ds1 DATASTORE
  MASTER masterds ON "system1"
  SUBSCRIBER subscriberds ON "system2"
  EXCLUDE TABLE tab1, tab2
  EXCLUDE SEQUENCE seq1

CREATE REPLICATION文のINCLUDE TABLE句およびINCLUDE SEQUENCE句を使用すると、データベースへの特定の表および順序のみの挿入を選択できます。INCLUDE句を使用すると、INCLUDE句で指定されたオブジェクトのみが、要素内の各サブスクライバにレプリケートされます。1つの要素記述で使用できるINCLUDE TABLE句およびINCLUDE SEQUENCEE句はそれぞれ1つのみです。たとえば、この要素記述では1つの表および2つの順序が挿入されます。

ELEMENT ds1 DATASTORE
  MASTER masterds ON "system1"
  SUBSCRIBER subscriberds ON "system2"
  INCLUDE TABLE tab3
  INCLUDE SEQUENCE seq2, seq3

表要素の定義

表tab1およびtab2を（masterdsという名前でホストsystem1に配置されている）マスター・データベースから（subscriberdsという名前でホストsystem2に配置されている）サブスクライバ・データベースにレプリケートする場合、ELEMENT記述（aおよびb）は次のようになります。

ELEMENT a TABLE tab1
  MASTER masterds ON "system1"
 SUBSCRIBER subscriberds ON "system2"
ELEMENT b TABLE tab2
  MASTER masterds ON "system1"
  SUBSCRIBER subscriberds ON "system2"

外部キーで関連付けられている表のレプリケーション

外部キーで互いに関連付けられている表は、すべての表をレプリケートするか一部の表のみをレプリケートするかを選択できますが、外部キーの関連付けがON DELETE CASCADEで構成されている場合は、すべての表をレプリケートするようにレプリケーションを構成する必要があります。これを行うには、どの表も除外しないDATASTORE要素を使用してレプリケーション・スキームを構成するか、または関連付けられているすべての表に対してTABLE要素を使用してレプリケーション・スキームを構成します。

ALTER REPLICATIONを使用して、ON DELETE CASCADEで構成された外部キーで関連付けられている表を既存のレプリケーション・スキームに追加することはできません。かわりに、レプリケーション・スキームを削除し、外部キーで関連付けられている新しい表を作成してから、関連するすべての表をレプリケートする新しいレプリケーション・スキームを作成します。

マテリアライズド・ビューのレプリケート

マテリアライズド・ビューは、ディテール表と呼ばれる1つ以上のTimesTen表から選択されたデータのサマリーです。マテリアライズド・ビューは直接レプリケートできませんが、マテリアライズド・ビューの基礎となるディテール表は通常のTimesTen表の場合と同じ方法でレプリケートできます。

マスター・データベースおよびサブスクライバ・データベースのディテール表は、マテリアライズド・ビューで参照できます。ただし、TimesTenレプリケーションでは、レプリケート対象のディテール表の構造がマスターおよびサブスクライバで同じであることのみが検証されます。マテリアライズド・ビューが各データベースで同じである必要はありません。

マテリアライズド・ビューまたは非マテリアライズド・ビューがDATASTORE要素として含まれているデータベース全体をレプリケートする場合は、ビューに関連付けられているディテール表のみがレプリケートされます。ビュー自体はレプリケートされません。一致するビューは、サブスクライバ・データベースで定義できますが、必須ではありません。ディテール表がレプリケートされると、TimesTenはそれに対応するビューを自動的に更新します。

マテリアライズド・ビューが更新されたときに、オーバーフローまたはアンダーフロー状態が発生するように指定されている場合、レプリケート対象の表に定義されたマテリアライズド・ビューで、レプリケーション障害または非一貫性が発生する場合があります。

順序のレプリケート

レプリケーションを使用すると、サブスクライバ・データベースの順序の現在値が常にマスター・データベースの現在値より大きくなるようにすることができます。これによって、後で順序を使用してサブスクライバ・データベースに直接更新を行っても、競合は発生しなくなります。たとえば、順序を使用してレプリケート表の主キー値を決定するアプリケーション、およびマスター・データベースで障害が発生した場合にマスターの役割を果たす必要があるデータベースが含まれている双方向構成があるとします。順序をレプリケートすると、直接更新するデータベースがいずれのデータベースであるかに関係なく、同じ順序値が2回使用されないことを保証できます。

順序のレプリケーションは、新しい現在値をマスター・データベースからサブスクライバに送信すると実行されます。これは、順序のNEXTVALを初めて参照すると実行され、その後は、20参照ごとに実行されます。たとえば、MINVALUEが1で、INCREMENTが2の順序my.seqについて考えてみます。トランザクションでmy.seq.NEXTVALを初めて使用すると、マスター・データベースの順序の現在値は3に変更され、新しい現在値41がサブスクライバにレプリケートされます。マスター・データベースのmy.seq.NEXTVALへの次の19回の参照では、サブスクライバ・データベースの現在値41がマスターの現在値より大きいため、新しい現在値のレプリケートは行われません。my.seq.NEXTVALへの21回目の参照のみが、新しい現在値61をサブスクライバ・データベースに送信します。これは、前回レプリケートされたサブスクライバの現在値41が、この時点でマスターの現在値43より小さくなるためです。

順序のレプリケーションには、次の制限があります。

  • CYCLE属性が指定された順序はレプリケートできません。

  • レプリケートされる順序の定義は、各ピア・データベースで同じである必要があります。

  • 順序では、競合の検出は実行されません。RETURN TWOSAFEサービスを使用せずに、双方向レプリケーション構成で両方のデータベースの順序を更新すると、両方の順序によって同じNEXTVALが返される可能性があります。

いずれかのピアで更新が行われる双方向レプリケーション・スキームで順序を使用する必要がある場合は、各データベースで、異なるMINVALUEおよびMAXVALUE属性が指定された、レプリケートされない順序をかわりに使用できます。たとえば、MINVALUEが1で、MAXVALUEが100の順序my.seqをデータベースDS1に作成し、MINVALUEが101で、MAXVALUEが200の同じ順序をDS2に作成するとします。この場合、DS1およびDS2を双方向レプリケーション・スキームで構成すると、順序my.seqを使用して、いずれのデータベースに対しても順序値が競合しないことを保証して更新を行うことができます。この構成でttRepAdmin -duplicateを使用して障害からリカバリする場合は、複製を実行した後で順序を削除し、新しいMINVALUEおよびMAXVALUEを指定して順序を再作成する必要があることに注意してください。

レプリケートする順序は、レプリケート表と併用することが前提とされています。したがって、順序の更新のレプリケートは、順序の更新後にレプリケート表への更新が実行される場合、または順序の更新がレプリケート表で使用される場合にのみ実行されます。SELECT my.seq.NEXTVAL FROM sys.dualなどの順序に対する操作では、順序値は増加しますが、レプリケートされる表への更新をその後に行うまでレプリケートは実行されません。この動作には、レプリケートされる表への更新をその後に行うまでこれらの順序の更新がログからパージされないという副作用があります。このため、これらの順序の更新のみがログの末尾に存在する場合は、ttRepSubscriberWaitおよびttRepAdmin -waitで障害が発生します。

seq順序の現在の値に対する更新を（masterdsという名前でホストsystem1に配置されている）マスター・データベースから（subscriberdsという名前でホストsystem2に配置されている）サブスクライバ・データベースにレプリケートする場合、要素記述（a）は次のようになります。

ELEMENT a SEQUENCE seq
  MASTER masterds ON "system1"
  SUBSCRIBER subscriberds ON "system2"

表要素に対するレプリケーション競合の確認

データベースが双方向レプリケーションに構成されている場合、複数のデータベースの同一表行が個別に同時に更新されると、レプリケーション競合が発生する可能性があります。

このような競合は、レプリケート表にタイムスタンプを含め、各表の要素記述にオプションのCHECK CONFLICTS句を指定してレプリケーション・スキームを構成することによって、表単位で検出および解消できます。

レプリケーション競合、およびCREATE REPLICATION文のCHECK CONFLICTS句の構成方法の詳細は、第14章「レプリケーション競合の解消」を参照してください。

データ・ストア要素に対する送信永続性の設定

非同期またはRETURN RECEIPTのレプリケーションで構成されたマスター・データベースは、デフォルトでは永続的になります。そのため、トランザクションのコミットと同時にログ・レコードはディスクにコミットされます。要素記述にTRANSMIT NONDURABLE句を使用して、マスター・データベースを非永続的に設定することもできます。

デフォルトでは、マスター・データベースのログ・バッファ内のトランザクション・レコードは、サブスクライバに転送される前にディスクにフラッシュされます。マスター・データベース全体をレプリケートする（ELEMENTのタイプがDATASTOREである）場合、マスターのログをディスクにフラッシュする処理をレプリケーション・サイクルから除くことによって、レプリケーション・パフォーマンスを向上できます。これを実現するには、要素記述にTRANSMIT NONDURABLE句を含めます。TRANSMITを設定しても、サブスクライバに影響はありません。サブスクライバ・データベースのトランザクション・レコードは、常にディスクにフラッシュされます。

RETURN TWOSAFEレプリケーションで構成されたマスター・データベースはデフォルトでは非永続的になり、永続的にすることはできません。RETURN TWOSAFEレプリケーションで構成されたデータベースにTRANSMIT DURABLEを設定しても、RETURN TWOSAFEトランザクションに影響はありません。

例9-1 TRANSMIT NONDURABLEが設定されたマスター・データベース全体のレプリケーション

マスター・データベース（masterds）のすべての内容をサブスクライバ・データベース（subscriberds）にレプリケートする場合およびログをディスクにフラッシュする処理を除く場合、要素記述（a）は次のようになります。

ELEMENT a DATASTORE
  MASTER masterds ON "system1"
  TRANSMIT NONDURABLE
  SUBSCRIBER subscriberds ON "system2"

通常、マスター・データベースで障害が発生した場合は、ttRepAdmin -duplicate処理（「障害が発生したデータベースのリカバリ」を参照）を開始して、障害が発生したマスターをサブスクライバ・データベースからリカバリする必要があります。これは、マスター・データベースがTRANSMIT DURABLEで構成されている場合は常に適用されます。

TRANSMIT NONDURABLEとして構成されたデータベースは、特定のタイプの双方向スキームで構成されている場合、サブスクライバ・レプリケーション・エージェントによって自動的にリカバリされます（「障害が発生したマスター・データベースの自動キャッチアップ」を参照）。そうでない場合は、「非永続的データベースのリカバリ」の手順に従って、障害が発生した非永続的データベースをリカバリする必要があります。

RETURNサービスの使用

RETURNサービスを指定してレプリケーション・スキームを構成すると、レプリケーション・データが、マスターおよびサブスクライバ両方のデータベースで一貫していることをより高いレベルの信頼性を持って保証できます。この項では、RETURN RECEIPTおよびRETURN TWOSAFEサービスの構成方法および管理方法について説明します。

CREATE REPLICATIONまたはALTER REPLICATION文で定義されるいずれのサブスクライバの表要素およびデータベース要素に対してもRETURNサービスを指定できます。

例9-2に、SubDatabase1とSubDatabase2に異なるRETURNサービス属性を定義する個別のSUBSCRIBER句を示します。

例9-2 各サブスクライバで異なるRETURNサービス

CREATE REPLICATION Owner.SchemeName
  ELEMENT ElementNameElementType
    MASTER DatabaseName ON "HostName"
    SUBSCRIBER SubDatabase1 ON "HostName" ReturnServiceAttribute1
    SUBSCRIBER SubDatabase2 ON "HostName" ReturnServiceAttribute2;

また、要素で定義されるすべてのサブスクライバに、同じRETURNサービス属性を指定することもできます。例9-3に、1つのSUBSCRIBER句を使用して、SubDatabase1とSubDatabase2の両方に同じRETURNサービス属性を定義する例を示します。

例9-3 すべてのサブスクライバで同じRETURNサービス

CREATE REPLICATION Owner.SchemeName
  ELEMENT ElementNameElementType
    MASTER DatabaseName ON "HostName"
    SUBSCRIBER SubDatabase1 ON "HostName",
               SubDatabase2 ON "HostName"
               ReturnServiceAttribute;

次の各項では、次に示すRETURNサービス属性について説明します。

RETURN RECEIPT

TimesTenでは、アプリケーションをレプリケーション・メカニズムと疎結合または同期するためにオプションのRETURN RECEIPTサービスが提供されています。

RETURN RECEIPT属性を指定して、要素記述のSUBSCRIBER句に示されたサブスクライバに対してRETURN RECEIPTサービスを有効にします。RETURN RECEIPTが有効になっている場合、アプリケーションは、マスター・データベースの要素に対するトランザクションをコミットすると、サブスクライバがトランザクション更新の受信を確認するまでブロックされたままになります。マスターが複数のサブスクライバに要素をレプリケートしている場合、すべてのサブスクライバがトランザクション更新の受信を確認するまで、アプリケーションはブロックされたままになります。

RETURN RECEIPTサービスを使用するレプリケーション・スキームの例は、例9-24および例9-25を参照してください。

例9-4 RETURN RECEIPT

マスター・データベース（masterds）のtab表に対してコミットしたすべてのトランザクションがサブスクライバ（subscriberds）で受信されたことを確認する場合、要素記述（e）は次のようになります。

ELEMENT e TABLE tab
    MASTER masterds ON "system1"
    SUBSCRIBER subscriberds ON "system2"
      RETURN RECEIPT

構成可能なタイムアウト時間内にいずれかのサブスクライバでトランザクションの受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。ttRepXactStatusプロシージャを使用してRETURN RECEIPTトランザクションのステータスを確認できます。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・トランザクションのステータスの確認」を参照してください。

また、タイムアウトが特定の回数発生した後、RETURN RECEIPTサービスを無効にするようにレプリケーション・エージェントを構成できます。詳細は、「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。

レプリケーションが停止すると、RETURN RECEIPTサービスはデフォルトで無効になります。詳細は、「RETURN SERVICES { ON | OFF } WHEN REPLICATION STOPPED」を参照してください。

RETURN RECEIPT BY REQUEST

RETURN RECEIPTは、すべてのトランザクションに対して受信の通知を有効にします。BY REQUESTオプションを指定してRETURN RECEIPTを使用すると、アプリケーションで識別される特定のトランザクションに対してのみ受信通知を有効にできます。

サブスクライバにRETURN RECEIPT BY REQUESTを指定する場合は、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURN RECEIPTサービスを有効にする必要があります。RETURN RECEIPTサービスを有効にするコールは、トランザクションの一部である必要があります（AutoCommitは無効である必要があります）。

例9-5 RETURN RECEIPT BY REQUEST

マスター・データベース（masterds）のtab表に対してコミットした特定のトランザクションがサブスクライバ（subscriberds）で受信されたことの確認を有効にする場合、要素記述（e）は次のようになります。

ELEMENT e TABLE tab
    MASTER masterds ON "system1"
    SUBSCRIBER subscriberds ON "system2"
      RETURN RECEIPT BY REQUEST

受信通知が必要なトランザクションをコミットする前に、SQLExecDirect関数内でttRepSyncSetをコールしてRETURNサービスをリクエストし、タイムアウト時間を45秒に設定します。

rc = SQLExecDirect( hstmt, (SQLCHAR *)
    "CALL ttRepSyncSet(0x01, 45, NULL)", SQL_NTS )

構成可能なタイムアウト時間内にいずれかのサブスクライバでトランザクションの更新の受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。「RETURNサービス・タイムアウト時間の設定」を参照してください。

ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次に例を示します。

Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.

RETURN TWOSAFE BY REQUEST

RETURN TWOSAFEは、すべてのトランザクションに対してサブスクライバでのコミットの通知を有効にします。BY REQUESTオプションを指定してRETURN TWOSAFEを使用すると、アプリケーションで識別される特定のトランザクションについてのみサブスクライバ・コミットの通知を有効にできます。

サブスクライバにRETURN TWOSAFE BY REQUESTを指定する場合は、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURN TWOSAFEサービスを有効にする必要があります。RETURN TWOSAFEサービスを有効にするコールは、トランザクションの一部である必要があります（autocommitは無効である必要があります）。

ALTER TABLE文を使用して、RETURN TWOSAFE BY REQUESTトランザクションの一部であるレプリケート表を変更することはできません。DDLCommitBehavior=1の場合、この処理によってエラー8051が発生します。DDLCommitBehavior=0の場合、ALTER TABLE処理の前にコミットが実行されるため、この処理は成功します。これにより、ALTER TABLE処理は、RETURN TWOSAFE BY REQUESTトランザクションの一部ではない新規トランザクションとなりまます。

例9-6 RETURN TWOSAFE BY REQUEST

マスター・データベース（databaseA）でコミットされた特定のトランザクションがサブスクライバ（databaseB）でもコミットされたことの確認を有効にする場合、要素記述（a）は次のようになります。

ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE BY REQUEST;

サブスクライバでのコミットの確認が必要なトランザクションのコミットをコールする前に、SQLExecDirect関数内でttRepSyncSetコールしてRETURNサービスをリクエストします（タイムアウト時間を45秒、タイムアウト・エラー発生時の動作をNO ACTION（1）に指定）。

rc = SQLExecDirect( hstmt, (SQLCHAR *)
    "CALL ttRepSyncSet(0x01, 45, 1)", SQL_NTS )

この例では、タイムアウト時間内にサブスクライバでトランザクションのコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。アプリケーションではタイムアウトの処理方法を選択できます。「RETURNサービス・タイムアウト時間の設定」を参照してください。

ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次に例を示します。

Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.

RETURN TWOSAFE

RETURN TWOSAFEサービスの場合、各レプリケーション・トランザクションは、マスター・データベースでコミットされる前にサブスクライバ・データベースでコミットされます。サブスクライバでトランザクションがコミットされたかどうかをレプリケーションで確認できなかった場合は、エラー通知が返されます。エラー受信後、アプリケーションで、障害のタイプに応じて、固有のアクションまたは事前に構成されているアクションのいずれかを実行できます。

RETURN TWOSAFEは、2つのデータベースが常に同期されている必要があるレプリケーション・スキームでの使用を前提としています。一方のデータベースの役割はアクティブ状態です。もう一方のデータベースの役割はスタンバイ状態ですが、いつでもアクティブ状態になることができる準備ができている必要があります。RETURN TWOSAFEは、2つのみのデータベースによる双方向レプリケーション・スキームで使用します。

サブスクライバに対してRETURN TWOSAFEサービスを有効にするには、CREATE REPLICATIONまたはALTER REPLICATION文のSUBSCRIBER句にRETURN TWOSAFE属性を指定します。

例9-7 RETURN TWOSAFE

マスター・データベース（databaseA）でコミットされたすべてのトランザクションがサブスクライバ（databaseB）でもコミットされたことを確認する場合、要素記述（a）は次のようになります。

ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE

RETURN TWOSAFEが指定された双方向構成でdatabaseAおよびdatabaseBの両方を指定するCREATE REPLICATION文全体は、次のようになります。

CREATE REPLICATION bidirect
ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE
ELEMENT b DATASTORE
    MASTER databaseB ON "system2"
    SUBSCRIBER databaseA ON "system1"
      RETURN TWOSAFE;

レプリケーションがRETURN TWOSAFEで構成されている場合は、自動コミット・モードを無効にする必要があります。

アプリケーションは、マスター・データベースでトランザクションをコミットすると、トランザクションが正常にコミットされたことがサブスクライバで確認されるまでブロックされたままになります。両方のデータベースで同じ更新または削除を開始すると、コミットがデッドロックする可能性があります。これは、処理を停止することでのみ解決できます。

構成可能なタイムアウト時間内にサブスクライバでトランザクション更新のコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。「RETURNサービス・タイムアウト時間の設定」を参照してください。

NO RETURN

RETURN RECEIPTまたはRETURN TWOSAFEサービスを明示的に無効にするには、NO RETURN属性を使用します。デフォルト設定はNO RETURNです。通常、この属性はALTER REPLICATION文で設定します。詳細は、例13-13を参照してください。

STORE属性の設定

表9-3に、CREATE REPLICATION文およびALTER REPLICATION文のオプションのSTOREパラメータを示します。

表9-3 STORE属性の説明

STORE属性 説明

DISABLE RETURN {SUBSCRIBER|ALL} NumFailures

NumFailuresで指定したタイムアウト数の後でRETURNサービス・ブロッキングが無効化されるように、RETURNサービス・ポリシーを設定します。

「RETURNサービス障害/リカバリ・ポリシーの設定」を参照してください。

RETURN SERVICES {ON|OFF} WHEN REPLICATION STOPPED

レプリケーションが無効になっている場合のRETURNサービスのオンまたはオフを設定します。

「RETURNサービス障害/リカバリ・ポリシーの設定」を参照してください。

RESUME RETURN Milliseconds

RETURNサービス・ブロッキングがDISABLE RETURNによって無効になっている場合、この属性は、RETURNサービスの再有効化に関するポリシーを設定します。

「RETURNサービス障害/リカバリ・ポリシーの設定」を参照してください。

RETURN WAIT TIME Seconds

RETURNサービスの応答を待機する時間（秒）を指定します。値が0（ゼロ）の場合は、待機なしを意味します。デフォルト値は10秒です。

このタイムアウト設定は、アプリケーションからttRepSyncSet組込みプロシージャのreturnWaitパラメータを使用して上書きできます。

「RETURNサービス・タイムアウト時間の設定」を参照してください。

DURABLE COMMIT {ON|OFF}

DurableCommits一般接続属性設定を上書きします。DISABLE RETURNによってRETURNサービス・ブロッキングが無効になっている場合、永続コミットを有効にします。

「DURABLE COMMIT」を参照してください。

LOCAL COMMIT ACTION {NO ACTION|ACTON}

タイムアウト発生時にRETURNサービス・トランザクションで実行されるデフォルトのアクションを指定します。オプションは次のとおりです。

NO ACTION: タイムアウト発生時、コミット関数はアプリケーションに返され、トランザクションはコミット・コールを入力したときと同じ状態のままになります。ただし、アプリケーションはレプリケートされた表を更新できません。アプリケーションはコミットを再発行できます。これがデフォルトです。

COMMIT: タイムアウト発生時、コミット関数はCOMMITを実行してトランザクションのローカルでの終了を試行します。

ttRepSyncSetプロシージャでlocalActionパラメータを使用することによって、特定のトランザクションに対してこのデフォルト設定を無効にすることができます。

「LOCAL COMMIT ACTION」を参照してください。

COMPRESS TRAFFIC {ON|OFF}

レプリケートの通信量を圧縮して、ネットワーク帯域幅の使用量を減らします。

「レプリケートの通信量の圧縮」を参照してください。

PORT PortNumber

マスターからの更新をリスニングするためにサブスクライバ・データベースで使用されるポート番号を設定します。

PORT属性を設定しない場合、TimesTenデーモンが動的にポートを選択します。TimesTenでは、静的ポート割当ても行うことができますが、動的ポート割当てを行うことをお薦めします。

「ポート割当て」を参照してください。

TIMEOUT Seconds

メッセージを再送する前に、データベースが別のデータベースからの応答を待機する最大時間（秒）を設定します。

「RETURNサービス・タイムアウト時間の設定」を参照してください。

FAILTHRESHOLD

ログ障害しきい値を設定します。

「ログ障害しきい値の設定」を参照してください。

CONFLICT REPORTING {SUSPEND|RESUME} AT Value

競合のレポートを一時停止する1秒当たりのレプリケーション競合数と、それを再開する1秒当たりのレプリケーション競合数を指定します。

第14章「レプリケーション競合の解消」を参照してください。

TABLE DEFINITION CHECKING {EXACT|RELAXED}

表定義チェックのタイプを定義します。

  • EXACT: マスターおよびサブスクライバで表が一致している必要があります。これがデフォルトです。

  • RELAXED: 表には同じキー定義、列の数および列のデータ型が必要です。

「様々な定義を持つ表のレプリケート」を参照してください。

FAILTHRESHOLDおよびTIMEOUT属性は、特定のレプリケーション・スキーム定義に対して固有に設定できます。つまり、これらの属性は、レプリケート・データベースに異なるレプリケーション・スキーム定義を適用している場合、異なって設定できます。これは、他の属性には適用されません。他の属性は、すべてのレプリケーション・スキーム定義で同じである必要があります。たとえば、1つのスキームにPORT属性を設定すると、すべてのスキームにその設定が適用されます。

STORE句を使用してFAILTHRESHOLD属性を設定するレプリケーション・スキームの例は、例9-24を参照してください。

RETURNサービス・タイムアウト時間の設定

レプリケーション・スキームが「RETURNサービスの使用」で説明されているいずれかのRETURNサービスで構成されていると、TIMEOUTで指定した時間内にいずれかのサブスクライバでマスターに確認応答を送信できなかった場合にタイムアウトが発生します。

デフォルトのRETURNサービス・タイムアウト時間は10秒です。異なるRETURNサービス・タイムアウト時間は、次の方法で指定できます。

  • CREATE REPLICATION文またはALTER REPLICATION文で、RETURN WAIT TIMEを構成します。RETURN WAIT TIMEが0（ゼロ）の場合は、待機なしを示します。

  • 新しいreturnWaitパラメータを指定して、ttRepSyncSetプロシージャをコールします。

タイムアウト時間は、設定後、再設定するか、またはアプリケーション・セッションが終了するまで、後続のすべてのRETURNサービス・トランザクションに適用されます。タイムアウト設定は、すべてのサブスクライバのすべてのRETURNサービスに適用されます。

RETURNサービスは、レプリケーション障害が発生した場合、またはレプリケーションに時間がかかりすぎて、レプリケートされる前にRETURNサービス・トランザクションがタイムアウトした場合にタイムアウトします。ただし、レプリケーション障害が同時に発生しないかぎり、サブスクライバからRETURNサービスの確認を取得することに失敗しても、トランザクションがレプリケートされていないこと、または将来レプリケートされないことを意味しません。

他のSTORE属性を設定して、タイムアウトが過剰に発生する場合にRETURNサービス・ブロッキングを自動的に無効にし、状況が改善されるとRETURNサービス・ブロッキングを再度有効にするポリシーを設定できます。「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。

例9-8 双方向レプリケーション・スキームの両方のデータベースでのタイムアウト時間の設定

bidirectレプリケーション・スキームで、双方向にレプリケートされるデータベースdatabaseAおよびdatabaseBの両方のタイムアウト時間を30秒に設定する場合、CREATE REPLICATION文は次のようになります。

CREATE REPLICATION bidirect
ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE
ELEMENT b DATASTORE
    MASTER databaseB ON "system2"
    SUBSCRIBER databaseA ON "system1"
      RETURN TWOSAFE
STORE databaseA RETURN WAIT TIME 30
STORE databaseB RETURN WAIT TIME 30;

例9-9 タイムアウト時間の再設定

ttRepSyncSetプロシージャを使用してタイムアウト時間を45秒に再設定するには、SQLExecDirect ODBC関数内でttRepSyncSetをコールします。requestReturnおよびlocalAction値を再設定しないようにするには、NULLを指定します。

rc = SQLExecDirect( hstmt, (SQLCHAR *)
    "CALL ttRepSyncSet(NULL, 45, NULL)", SQL_NTS )

RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理

サブスクライバ障害が発生した場合、ユーザーまたはマスター・レプリケーション・エージェントはレプリケーション状態をStopに再設定できます。サブスクライバが、RETURNサービスを使用しているトランザクションを確認できず、マスターに対してタイムアウトする場合もあります。タイムアウト時間内にいずれかのサブスクライバがトランザクション更新を確認できない場合、アプリケーションは、コミット・リクエストに対するerrRepReturnFailed警告を受信します。

デフォルトのRETURNサービス・タイムアウト時間は10秒です。異なるRETURNサービス・タイムアウト時間は、次の方法で指定できます。

  • CREATE REPLICATION文またはALTER REPLICATION文のSTORE句で、RETURN WAIT TIME属性を構成します。

  • 新しいreturnWaitパラメータを指定して、ttRepSyncSetプロシージャをコールします。

RETURNサービスは、レプリケーション障害が発生した場合、またはレプリケーションに時間がかかりすぎて、レプリケートされる前にRETURNサービス・トランザクションがタイムアウトした場合にタイムアウトまたは失敗します。ただし、レプリケーション障害が同時に発生しないかぎり、サブスクライバからRETURNサービスの確認を取得することに失敗しても、トランザクションがレプリケートされていないこと、または将来レプリケートされないことを意味しない場合もあります。

この項では、RETURNサービス・トランザクションでのタイムアウトの検出方法および応答方法について説明します。主な内容は次のとおりです。

RETURNサービス・ブロッキングを手動で無効にする場合

レプリケーションが停止した場合、またはレプリケート・システムのパフォーマンスにRETURNサービス・タイムアウト障害が悪影響を及ぼし始めた場合は、なんらかの方法で対処する必要があります。RETURNサービス・タイムアウトの許容しきい値は、特定のアプリケーションのタイムアウトの履歴頻度およびパフォーマンス/可用性の関係によって異なります。問題に対処する場合、これらの両方の要素について考慮する必要があります。

RETURN RECEIPTサービスを使用している場合、次の方法で手動により対処できます。

  • ALTER REPLICATIONを使用し、レプリケーション・スキームを変更して特定のサブスクライバのRETURN RECEIPTブロッキングを無効にします。RETURN RECEIPTブロッキングを無効にすると決めた場合、これを再度有効にするという判断は、RETURN RECEIPTトランザクションがタイムアウトしないと確信できるレベルに基づいて行います。

  • ttDurableCommitプロシージャをコールし、サブスクライバで受信されたかどうかを確認できなくなったマスターのトランザクションを永続的にコミットします。

手動でRETURNサービス・タイムアウト障害に対処するかわりに、RETURNサービス障害およびリカバリ・ポリシーをレプリケーション・スキームに設定して対処することもできます。これらのポリシーは、レプリケーション状態の変化の検出およびRETURNサービス・タイムアウトの追跡を行い、事前に設定したなんらかの方法で自動的に対処するようにレプリケーション・エージェントに直接指示します。

RETURNサービス障害/リカバリ・ポリシーの設定

手動でRETURNサービス・タイムアウト障害に対処するかわりに、RETURNサービス障害およびリカバリ・ポリシーをレプリケーション・スキームに設定して対処することもできます。これらのポリシーは、レプリケーション状態の変化の検出およびRETURNサービス・タイムアウトの追跡を行い、事前に設定したなんらかの方法で自動的に対処するようにレプリケーション・エージェントに直接指示します。

RETURN RECEIPTまたはRETURN TWOSAFEサービスを使用する場合は、CREATE REPLICATIONまたはALTER REPLICATION文の次の属性によって障害/リカバリ・ポリシーを設定します。

これらの属性によって設定したポリシーは、データベースの存続期間中、または変更されるまで適用されます。ただし、これらのポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。

RETURN SERVICES { ON | OFF } WHEN REPLICATION STOPPED

レプリケーションが停止した場合は、RETURN SERVICES { ON | OFF } WHEN REPLICATION STOPPED属性によって、RETURN RECEIPTまたはRETURN TWOSAFEサービスを継続して有効にするか、無効にするかが決定されます。このコンテキストでの停止とは、（ttAdmin -repStop masterなどによって）マスター・レプリケーション・エージェントが停止されたこと、または（ttRepAdmin -state stop subscriberなどによって）サブスクライバ・データベースのレプリケーション状態がマスター・データベースに対してStopまたはPauseに設定されることを意味します。指定したFAILTHRESHOLD値を超えている障害が発生したサブスクライバは、Failed状態に設定されますが、最終的にはマスター・レプリケーション・エージェントによってStop状態に設定されます。


注意:

サブスクライバは、RETURN WAIT TIMEで指定されたタイムアウト時間を超えるとその期間中は使用できなくなりますが、マスター・レプリケーション・エージェントでは継続してStart状態であるとみなされます。タイムアウトに関連する障害ポリシーは、DISABLE RETURN属性によって設定されます。

RETURN SERVICES OFF WHEN REPLICATION STOPPEDは、レプリケーションが停止すると、RETURNサービスを無効にします。これは、RETURN RECEIPTサービス使用時のデフォルト設定です。RETURN SERVICES ON WHEN REPLICATION STOPPEDは、レプリケーションが停止した場合でもRETURNサービスを継続して有効にできます。これは、RETURN TWOSAFEサービス使用時のデフォルト設定です。

例9-10 RETURN SERVICES ON WHEN REPLICATION STOPPED

masterdsデータベースからsubscriber1データベースに更新をレプリケートするように、CREATE REPLICATION文を構成します。このCREATE REPLICATION文では、RETURN RECEIPTおよびRETURN SERVICES ON WHEN REPLICATION STOPPEDの使用が指定されています。

CREATE REPLICATION myscheme
ELEMENT e TABLE tab
  MASTER masterds ON "server1"
  SUBSCRIBER subscriber1 ON "server2"
  RETURN RECEIPT
  STORE masterds ON "server1"
    RETURN SERVICES ON WHEN REPLICATION STOPPED;

アプリケーションでマスターへの更新をコミットする場合は、ttRepAdminを使用してsubscriber1をStop状態に設定します。

ttRepAdmin -dsn masterds -receiver -name subscriber1 -state stop

アプリケーションは、レプリケーション状態がStartに再設定され、subscriber1からRETURN RECEIPT確認応答を受信するまでこの確認応答を継続して待機します。

ttRepAdmin -dsn masterds -receiver -name subscriber1 -state start
DISABLE RETURN

DISABLE RETURN値を設定すると、データベースは、RETURN WAIT TIMEで設定されたタイムアウト時間を超えているRETURN RECEIPTトランザクションおよびRETURN TWOSAFEトランザクションの数を追跡します。タイムアウト数がDISABLE RETURNで設定した最大値を超えると、アプリケーションは、デフォルトのレプリケーション・サイクルに戻り、レプリケート対象の更新に対するサブスクライバからの確認応答を待機しなくなります。

DISABLE RETURN SUBSCRIBERを設定して、タイムアウトしたサブスクライバに対してのみRETURNサービス・ブロッキングを無効にするポリシーを設定するか、またはDISABLE RETURN ALLを設定して、すべてのサブスクライバに対してRETURNサービス・ブロッキングを無効にするポリシーを設定できます。DISABLE RETURN障害ポリシーによって特定のサブスクライバが無効にされているかどうかを確認するには、ttRepSyncSubscriberStatus組込みプロシージャまたはSNMPトラップttRepReturnTransitionTrapを使用します。

DISABLE RETURN障害ポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。DISABLE RETURNが指定され、RESUME RETURNが指定されていない場合、データベースのレプリケーション・エージェントが再起動されるまでRETURNサービスはオフのままです。この障害ポリシーは、レプリケーション・エージェントを停止し、DISABLE RETURN SUBSCRIBERまたはDISABLE RETURN ALLのいずれかをNumFailuresの値を0にして指定すると取り消すことができます。障害ポリシーをトリガーするタイムアウトのカウントは、レプリケーション・エージェントを再起動したとき、DISABLE RETURN値を0に設定したとき、またはRETURNサービス・ブロッキングがRESUME RETURNによって再度有効にされたときにリセットされます。

DISABLE RETURNは、各サブスクライバのタイムアウトの累積カウントを保持します。複数のサブスクライバが存在する場合にDISABLE RETURN SUBSCRIBERを設定すると、レプリケーション・エージェントは、タイムアウトのしきい値に最初に達したサブスクライバのRETURNサービス・ブロッキングを無効にします。その後、他のいずれかのサブスクライバがタイムアウトのしきい値に達すると、レプリケーション・エージェントは、そのサブスクライバのRETURNサービス・ブロッキングも同様に無効にします。

例9-11 DISABLE RETURN SUBSCRIBER

データベースmasterdsからデータベースsubscriber1およびsubscriber2に更新をレプリケートするように、CREATE REPLICATION文を構成します。CREATE REPLICATION文では、NumFailuresの値を5にしてRETURN RECEIPTおよびDISABLE RETURN SUBSCRIBERの使用が指定されています。RETURN WAIT TIMEは30秒に設定されています。

CREATE REPLICATION myscheme
ELEMENT e TABLE tab
  MASTER masterds ON "server1"
  SUBSCRIBER subscriber1 ON "server2",
             subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
  DISABLE RETURN SUBSCRIBER 5
  RETURN WAIT TIME 30;

アプリケーションでマスターへの更新をコミットすると、subscriber1で問題が発生し、レプリケート対象のトランザクション更新の確認に失敗します。アプリケーションは、マスターへの次の更新をコミットするまで30秒ブロックされます。アプリケーション・セッションの期間中、このコミット/タイムアウトのサイクルは、DISABLE RETURNによってsubscriber1のRETURN RECEIPTブロッキングが無効になるまでこの後4回繰り返されます。アプリケーションは、subscriber1からではなく、subscriber2からのRETURN RECEIPT確認応答を継続して待機します。

RETURN SERVICES OFF WHEN REPLICATION STOPPEDはRETURN RECEIPTサービスのデフォルトの設定です。このため、次のいずれかの場合にRETURN RECEIPTは無効になります。

DISABLE RETURNを設定するもう1つの例は、例9-12を参照してください。

RESUME RETURN

RETURNサービス・ブロッキングが無効であるとは、マスター・データベースのアプリケーションが、レプリケーション更新を受信またはコミットしたサブスクライバからの確認応答を待機している間、実行をブロックしないことを意味します。ただし、マスターは、レプリケート対象の更新の各バッチについてサブスクライバからの確認応答をリスニングしていることに注意してください。

RETURNサービス・リカバリ・ポリシーは、RESUME RETURN属性を設定し、再開待機時間の値を指定して設定できます。この属性が設定され、サブスクライバに対するRETURNサービス・ブロッキングが無効になっている場合に、トランザクションのコミット確認応答時間がRESUME RETURNで設定した値より小さくなると、RETURN RECEIPTまたはRETURN TWOSAFEサービスが再開されます。コミット確認応答時間とは、アプリケーションがコミットを実行してから、マスターがサブスクライバから更新の確認応答を受信するまでの待機時間のことです。

例9-12 RESUME RETURN

RETURN RECEIPTブロッキングがsubscriber1に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、RETURN RECEIPTブロッキングは、マスターのアプリケーションで更新がコミットされてから8ミリ秒未満でその更新の確認応答を受け取るとすぐにsubscriber1に対して再開されます。

CREATE REPLICATION myscheme
ELEMENT e TABLE tab
  MASTER masterds ON "server1"
  SUBSCRIBER subscriber1 ON "server2",
             subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
  DISABLE RETURN SUBSCRIBER 5
  RESUME RETURN 8;

RESUME RETURNポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。RETURN RECEIPT再開ポリシーは、レプリケーション・エージェントを停止した後、ALTER REPLICATIONを使用してRESUME RETURNを0（ゼロ）に設定して取り消すことができます。

DURABLE COMMIT

DURABLE COMMIT属性を設定して、DISABLE RETURNでRETURNサービス・ブロッキングを無効にしたアプリケーションに永続コミット・ポリシーを指定します。DURABLE COMMITをONに設定すると、マスター・データベースのDurableCommits一般接続属性が上書きされ、RETURNサービス・ブロッキングを無効にしたトランザクションに対して永続コミットが強制実行されます。

DURABLE COMMITは、サブスクライバが1つのみの場合に有効です。ただし、2つのサブスクライバに同じデータをレプリケートし、一方のサブスクライバのRETURNサービス・ブロッキングを無効にした場合は、永続コミットを有効にするより、他方のサブスクライバを使用した方が、より高いパフォーマンスを得ることができます。


注意:

RETURN SERVICES ON WHEN REPLICATION STOPPEDを指定してレプリケーション・スキームを構成した場合、DURABLE COMMITポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。

例9-13 DURABLE COMMIT

DISABLE RETURN ALLポリシーを設定してすべてのサブスクライバのRETURN RECEIPTブロッキングを無効にした場合、DURABLE COMMIT ONを設定します。RETURN RECEIPTブロッキングを無効にすると、コミットが永続的にディスクにコミットされ、冗長性が提供されます。

CREATE REPLICATION myscheme
ELEMENT e TABLE tab
  MASTER masterds ON "server1"
  SUBSCRIBER subscriber ON "server2",
             subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
  DISABLE RETURN ALL 5
  DURABLE COMMIT ON
  RESUME RETURN 8;
LOCAL COMMIT ACTION

RETURN TWOSAFEサービスを使用している場合、次のようにして、タイムアウト時のエラーに対するマスター・レプリケーション・エージェントの応答方法を指定できます。

  • CREATE REPLICATION文のSTORE句でのLOCAL COMMIT ACTION属性の設定

  • localActionパラメータを指定したttRepSyncSetプロシージャのコール

RETURN TWOSAFEトランザクションのレプリケーション中にタイムアウトを受信した場合に、実行可能なアクションは次のとおりです。

  • COMMIT: タイムアウト発生時に、アプリケーションがトランザクションをコミットし、トランザクションでそれ以上の処理ができなくなります。

  • NO ACTION: タイムアウト発生時に、アプリケーションはトランザクションをコミットしません。プロセス・リカバリがトランザクションをコミットします。これは、強制コミットに相当します。

コールしてエラーが返された場合は、「RETURNサービス・トランザクションのステータスの確認」で説明されているttRepXactStatusプロシージャを使用して、トランザクションのステータスを確認できます。エラーに応じて、アプリケーションで次のいずれかの処理を選択できます。

  • コミット・コールの再発行: この処理は、RETURN TWOSAFEレプリケーション・サイクル全体を繰り返すため、サブスクライバでのレプリケートされたコミットの成功または失敗が認識された場合、またはタイムアウト時間に達した場合にコミット・コールが返されます。

  • トランザクションのロールバック: コールしてサブスクライバでのトランザクションの適用に関するエラー（主キー検索障害など）が返された場合は、マスターでトランザクションをロールバックできます。

レプリケートの通信量の圧縮

低帯域幅のネットワークを介してレプリケーションを行う場合、または大量のデータのレプリケーションを行う場合は、レプリケーションに必要な帯域幅の量を減らすCOMPRESS TRAFFIC属性を設定できます。COMPRESS TRAFFIC属性を使用すると、CREATE REPLICATION文またはALTER REPLICATION文のSTOREパラメータで指定されたデータベースからレプリケートされたデータが圧縮されます。TimesTenでは、他のデータベースからの通信量は圧縮されません。

圧縮アルゴリズムは速度に関しては最適化されますが、COMPRESS TRAFFIC属性を有効にすると、レプリケーションのスループットおよび待機時間になんらかの影響があります。

例9-14 1つのデータベースからの通信量の圧縮

データベースdsn1からのレプリケートの通信量は圧縮し、dsn2からのレプリケートの通信量は圧縮しない場合、CREATE REPLICATION文は次のようになります。

CREATE REPLICATION repscheme
ELEMENT d1 DATASTORE
    MASTER dsn1 ON machine1
    SUBSCRIBER dsn2 ON machine2
ELEMENT d2 DATASTORE
    MASTER dsn2 ON machine2
    SUBSCRIBER dsn1 ON machine1
STORE dsn1 ON machine1 COMPRESS TRAFFIC ON;

例9-15 両方のデータベース間の通信量の圧縮

dsn1とdsn2のデータベース間でのレプリケートの通信量を圧縮するには、次のように入力します。

CREATE REPLICATION scheme
ELEMENT d1 DATASTORE
    MASTER dsn1 ON machine1
    SUBSCRIBER dsn2 ON machine2
ELEMENT d2 DATASTORE
    MASTER dsn2 ON machine2
    SUBSCRIBER dsn1 ON machine1
STORE dsn1 ON machine1 COMPRESS TRAFFIC ON
STORE dsn2 ON machine2 COMPRESS TRAFFIC ON;

ポート割当て

PORT属性を割り当てない場合、TimesTenデーモンが動的にポートを選択します。ポートがレプリケーション・エージェントに動的に割り当てられる場合は、TimesTenデーモンのポートも一致させる必要があります。1つのスキームにPORT属性を設定すると、すべてのスキームにその設定が適用されます。

オンラインによるアップグレードを行う場合は、静的ポートを割り当てる必要があります。

CREATE REPLICATIONを使用して、同じデータベースに対してPORT属性が異なる様々なスキームを作成すると、TimesTenでは前回のCREATE REPLICATION文の設定は無視されます。この場合は、ALTER REPLICATIONを使用して、PORT設定を変更する必要があります。

ポートを静的に割り当てる場合は、CREATE REPLICATION文のSTORE属性に完全なホスト名、DSNおよびポートを指定する必要があります。

例9-16 静的ポートの割当て

CREATE REPLICATION repscheme
ELEMENT el1 TABLE tab
    MASTER dsn1 ON machine1
    SUBSCRIBER dsn2 ON machine2
ELEMENT el2 TABLE tab
    MASTER dsn2 ON machine2
    SUBSCRIBER dsn1 ON machine1
STORE dsn1 ON machine1 PORT 16080
STORE dsn2 ON machine2 PORT 16083;

ログ障害しきい値の設定

しきい値を設定することができます。この値を超えると、使用可能なログ領域を使い果たす前に、使用不可能なサブスクライバをFailed状態に設定します。FAILTHRESHOLD属性を使用すると、ログ障害しきい値を設定できます。詳細は、例9-24を参照してください。

デフォルトのしきい値は0（ゼロ）で、「制限なし」を意味します。ログ障害しきい値の詳細は、「ロギングの接続属性の設定」を参照してください。

マスターは、サブスクライバ・データベースをFailed状態に設定すると、障害が発生したサブスクライバのすべてのデータをログから削除し、そのサブスクライバ・データベースにメッセージを送信します。マスター・レプリケーション・エージェントでサブスクライバ・レプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。サブスクライバは、双方向レプリケーションの場合または他のサブスクライバに更新を伝播するように構成されている場合、マスターからメッセージを受信すると、それ以上更新を送信しません。これは、レプリケーションの状態が損なわれたためです。

障害が発生したサブスクライバに接続中のアプリケーションは、データベースがレプリケーション・ピアによってFailedとマークされたことを示すtt_ErrReplicationInvalid (8025)警告を受信します。サブスクライバ・データベースにその障害状態が通知されると、マスター・データベースでのその状態はFailedからStopに変更されます。

アプリケーションでは、ODBCのSQLGetInfo関数を使用して、接続中のデータベースがFailed状態に設定されているかどうかを確認できます（「サブスクライバの障害」を参照）。

様々な定義を持つ表のレプリケート

TABLE DEFINITION CHECKING属性を使用して、同一ではない表のレプリケーションを有効にできます。たとえば、列が異なる位置にある表やパーティションの数が異なる表をレプリケートするには、この句を使用します。表のパーティション化は、表が最初に作成された後で列が追加されると発生します。詳細は、例9-18を参照してください。

TABLE DEFINITION CHECKING属性をRELAXEDに設定するには、レプリケートされた表に同じキー定義、列の数および列のデータ型が必要です。表定義チェックは、サブスクライバ側で実行されます。マスターおよびサブスクライバの両方でこの属性をRELAXEDに設定すると、サブスクライバのみで設定した場合と同じ結果になります。

RELAXEDに設定すると、通常はパフォーマンスがわずかに低下します。パフォーマンス上の変化は、ワークロードおよび表の列の数に応じて異なります。

複数のパーティションがある表を結合する間は表定義チェックを一時的にRELAXEDに設定し、その後、EXACTに再設定できます。構造が同じ表の場合、パフォーマンスは低下しません。

例9-17 異なる位置にある列を持つ表のレプリケート

dsn1データベースに表t1を作成します。

CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c INT);

dsn1データベースのt1の列とは異なる順番の列を持つ表t1をdsn2データベースに作成します。両方の表で列名およびデータ型が同じであり、両方の表でaが主キーであることに注意します。

CREATE TABLE t1 (c INT, a INT PRIMARY KEY, b INT);

レプリケーション・スキームrep1を作成します。サブスクライバdsn2で、TABLE DEFINITION CHECKINGをRELAXEDに設定します。

CREATE REPLICATION rep1
       ELEMENT e1 TABLE t1
       MASTER dsn1
       SUBSCRIBER dsn2
       STORE dsn2 TABLE DEFINITION CHECKING relaxed;

両方のデータベースのレプリケーション・エージェントを起動します。dsn1のt1に行を1つ挿入します。

Command> INSERT INTO t1 VALUES (4,5,6);
1 row inserted.

dsn2のt1の結果を確認します。

Command> SELECT * FROM t1;
< 5, 6, 4 >
1 row found.

例9-18 異なるパーティション数を持つ表のレプリケーション

表に列を追加すると、その後その新しい列を削除しても、表のパーティション数は増加します。TABLE DEFINITION CHECKINGをRELAXEDに設定すると、パーティションの数が異なる表をレプリケートできます。

dsn1に、列が2つある表t3を作成します。

CREATE TABLE t3 (a INT PRIMARY KEY, b INT);

dsn2に、列が1つあり、その列が主キーである表t3を作成します。

CREATE TABLE t3 (a INT PRIMARY KEY);

dsn2の表に列を追加します。これにより、パーティションの数は2つになりますが、dsn1の表のパーティションは1つです。

ALTER TABLE t3 ADD COLUMN b INT;

両方のデータベースでレプリケーション・スキームを作成します。

CREATE REPLICATION reppart
       ELEMENT e2 TABLE t3
       MASTER dsn1
       SUBSCRIBER dsn2
       STORE dsn2 TABLE DEFINITION CHECKING RELAXED;

両方のデータベースのレプリケーション・エージェントを起動します。dsn1のt3に行を1つ挿入します。

Command> INSERT INTO t3 VALUES (1,2);
1 row inserted.

dsn2のt3の結果を確認します。

Command> SELECT * FROM t3;
< 1, 2 >
1 row found.

ネットワーク操作の構成

レプリケーション・ホストにネットワーク・インタフェースが複数ある場合は、デフォルト以外のインタフェースを使用するようにレプリケーションを構成することもできます。レプリケーション要素を定義するときに、オペレーティング・システムのhostnameコマンドが返すホスト名を指定する必要はありますが、ROUTE句を使用することで、別のインタフェースでトラフィックを送受信するようにレプリケーションを構成できます。

ROUTE句の構文は次のようになります。

ROUTE MASTER FullDatabaseName SUBSCRIBER FullDatabaseName
  {{MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost}
    PRIORITY Priority} [...]

例9-19 複数のネットワーク・インタフェースの構成

ホストmachine1にはホスト名machine1fastでアクセス可能な2つ目のインタフェースが構成されており、machine2にはIPアドレス192.168.1.100でアクセス可能な2つ目のインタフェースが構成されている場合、次のようにすると、2つ目のインタフェースをレプリケーション・スキームで使用するように指定できます。

CREATE REPLICATION repscheme
ELEMENT e1 TABLE tab
    MASTER dsn1 ON machine1
    SUBSCRIBER dsn2 ON machine2
ELEMENT e2 TABLE tab
    MASTER dsn2 ON machine2
    SUBSCRIBER dsn1 ON machine1
ROUTE MASTER dsn1 ON machine1 SUBSCRIBER dsn2 ON machine2
    MASTERIP machine1fast PRIORITY 1
    SUBSCRIBERIP "192.168.1.100" PRIORITY 1
ROUTE MASTER dsn2 ON machine2 SUBSCRIBER dsn1 ON machine1
    MASTERIP "192.168.1.100" PRIORITY 1
    SUBSCRIBERIP machine1fast PRIORITY 1;

また、インタフェースが複数あるレプリケーション・ホストでは、プライマリ・インタフェースに障害が発生したり、そのインタフェースと受信ホストとの間の接続が切断した場合に備えて、1つ以上のインタフェースをバックアップとして使用するようにレプリケーションを構成できます。ROUTE句を使用すると、それぞれのマスターおよびサブスクライバに対して複数のインタフェースを指定し、優先順位に従ってレプリケーションで使用することができます。

例9-20 ネットワーク優先順位の構成

ホストmachine1に2つのネットワーク・インタフェース（IPアドレスは192.168.1.100と192.168.1.101）が構成され、ホストmachine2に2つのインタフェース（IPアドレスは192.168.1.200と192.168.1.201）が構成されている場合は、まずIPアドレス192.168.1.100と192.168.1.200を使用してトラフィックの送受信を行い、その接続に障害が発生したときにIPアドレス192.168.1.101または192.168.1.201を試行するようにレプリケーションを設定できます。

CREATE REPLICATION repscheme
ELEMENT e TABLE tab
  MASTER dsn1 ON machine1
  SUBSCRIBER dsn2 ON machine2
ROUTE MASTER dsn1 ON machine1 SUBSCRIBER dsn2 ON machine2
  MASTERIP "192.168.1.100" PRIORITY 1
  MASTERIP "192.168.1.101" PRIORITY 2
  SUBSCRIBERIP "192.168.1.200" PRIORITY 1
  SUBSCRIBERIP "192.168.1.201" PRIORITY 2;

マスター・ホストのレプリケーションが、優先順位の最も高いMASTERIPにバインドできなかった場合は、次の優先順位のMASTERIPアドレスを使用して接続が試行されます。ただし、サブスクライバへの接続がなんらかの理由で失敗した場合は、次に優先順位の高いMASTERIPアドレスを試す前に、それぞれのSUBSCRIBERIPアドレスを優先順に使用して接続が試行されます。

レプリケーション・スキームの構文の例

この項で説明する例では、様々なレプリケーション・スキームの構成方法を示します。次のレプリケーション・スキームについて説明します。

単一サブスクライバ・スキーム

例9-21のスキームは、単一のマスターおよびサブスクライバの単方向レプリケーション・スキームです。2つのデータベースが別々のホストsystem1およびsystem2に配置されています。RETURN RECEIPTサービスを使用して、マスター・データベースのtab表に対してコミットしたすべてのトランザクションがサブスクライバで受信されることを確認します。

例9-21 1つの表のレプリケーション

CREATE REPLICATION repscheme
ELEMENT e TABLE tab
    MASTER masterds ON "system1"
    SUBSCRIBER subscriberds ON "system2"
      RETURN RECEIPT;

例9-22のスキームは、単一のマスターおよびサブスクライバの単方向レプリケーション・スキームです。2つのデータベースが別々のホストserver1およびserver2に配置されています。マスター・データベースmasterdsは、そのすべての内容をサブスクライバ・データベースsubscriberdsにレプリケートします。

例9-22 データベース全体のレプリケーション

CREATE REPLICATION repscheme
ELEMENT e DATASTORE
    MASTER masterds ON "server1"
    SUBSCRIBER subscriberds ON "server2";

RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・スキーム

最大128のサブスクライバ・データベースを含むレプリケーション・スキームを作成できます。プロパゲータ・データベースを構成する場合は、最大128のプロパゲータを構成できます。各プロパゲータには最大128のサブスクライバ・データベースを構成できます。プロパゲータ・データベースを使用するレプリケーション・スキームの例は、「伝播スキーム」を参照してください。

例9-23 2つのサブスクライバへのレプリケーション

この例では、server2にあるsubscriber1dsおよびserver3にあるsubscriber2dsという2つのサブスクライバ・データベースにtab表をレプリケートするマスター・データベースmasterdsを設定します。レプリケーション・スキームの名前はtwosubscribersです。レプリケーション要素の名前はeです。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE tab
    MASTER masterds ON "server1"
    SUBSCRIBER subscriber1ds ON "server2",
               subscriber2ds ON "server3";

例9-24 RETURN RECEIPTを指定した2つのサブスクライバへのレプリケーション

この例では、例9-23の基本的な例を使用し、それにRETURN RECEIPT属性およびSTOREパラメータを追加します。RETURN RECEIPTで、両方のデータベースに対するRETURN RECEIPTサービスを有効にします。STOREパラメータで、FAILTHRESHOLD値を10に設定し、サブスクライバで障害が発生したとみなされるまでmasterdsに累積可能な、サブスクライバに対するトランザクション・ログ・ファイルの最大数を指定します。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE rel.tab
  MASTER masterds ON "server1"
  SUBSCRIBER subscriber1ds ON "server2",
             subscriber2ds ON "server3"
  RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;

例9-25 1つのみのサブスクライバに対するRETURN RECEIPTの有効化

この例では、subscriber2dsに対してのみRETURN RECEIPTを有効にする方法を示します。subscriber1ds定義の末尾のカンマは不要です。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE tab
    MASTER masterds ON "server1"
    SUBSCRIBER subscriber1ds ON "server2"
    SUBSCRIBER subscriber2ds ON "server3" RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;

例9-26 サブスクライバで異なるRETURNサービスの有効化

この例では、RETURN RECEIPT BY REQUESTをsubscriber1dsに、RETURN RECEIPTをsubscriber2dsに適用する方法を示します。このスキームでは、subscriber1dsにアクセスするアプリケーションでttRepSyncSetプロシージャを使用してトランザクションのRETURNサービスを有効にする必要があります。一方、subscriber2dsでは、すべてのトランザクションにRETURNサービスが無条件に提供されます。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE tab
    MASTER masterds ON "server1"
    SUBSCRIBER subscriberds1 ON "server2" RETURN RECEIPT BY REQUEST
    SUBSCRIBER subscriber2ds ON "server3" RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;

異なるサブスクライバへの表のレプリケーション

例9-27のレプリケーション・スキームでは、4つの表をレプリケートするマスター・データベースcentraldsを設定します。tab1およびtab2はサブスクライバbackup1dsにレプリケートされ、tab3およびtab4はbackup2dsにレプリケートされます。マスター・データベースはfinanceサーバーにあります。両方のサブスクライバがサーバーbackupsystemに配置されています。

例9-27 異なるサブスクライバへの表のレプリケーション

CREATE REPLICATION twobackups
ELEMENT a TABLE tab1
  MASTER centralds ON "finance"
  SUBSCRIBER backup1ds ON "backupsystem"
ELEMENT b TABLE tab2
  MASTER centralds ON "finance"
  SUBSCRIBER backup1ds ON "backupsystem"
ELEMENT d TABLE tab3
  MASTER centralds ON "finance"
  SUBSCRIBER backup2ds ON "backupsystem"
ELEMENT d TABLE tab4
  MASTER centralds ON "finance"
  SUBSCRIBER backup2ds ON "backupsystem";

伝播スキーム

例9-28では、マスター・データベースからプロパゲータに表の更新が送信されます。プロパゲータは、2つのサブスクライバに変更を転送します。マスター・データベースはホストfinanceのcentraldsです。プロパゲータはホストnethandlerのpropdsです。サブスクライバは、backupsystem1のbackup1dsおよびbackupsystem2のbackup2dsです。

レプリケーション・スキームには2つの要素があります。要素aでは、centraldsのtab表に対する変更がプロパゲータ・データベースpropdsにレプリケートされます。要素bでは、propdsで受信したtab表への変更が2つのサブスクライバbackup1dsおよびbackup2dsにレプリケートされます。

例9-28 伝播

CREATE REPLICATION propagator
ELEMENT a TABLE tab
  MASTER centralds ON "finance"
  SUBSCRIBER propds ON "nethandler"
ELEMENT b TABLE tab
  PROPAGATOR propds ON "nethandler"
  SUBSCRIBER backup1ds ON "backupsystem1",
             backup2ds ON "backupsystem2";

双方向の分割ワークロード・スキーム

例9-29では、ホストwestcoastのwestdsおよびホストeastcoastのeastdsという2つのデータベースがあります。顧客は2つの表で表されます。西地区の顧客のデータはwaccounts、東地区の顧客のデータはeaccountsに収められます。westdsデータベースは、waccounts表を更新してeastdsデータベースにレプリケートします。eaccounts表は、eastdsデータベースによって所有され、westdsデータベースにレプリケートされます。RETURN RECEIPT属性は、RETURN RECEIPTサービスを有効にして、いずれのマスター表のトランザクションもそれらのサブスクライバによって受信されることを保証します。

例9-29 双方向の分割ワークロード

CREATE REPLICATION r1
ELEMENT elem_waccounts TABLE waccounts
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast" RETURN RECEIPT
ELEMENT elem_eaccounts TABLE eaccounts
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast" RETURN RECEIPT;

双方向の分散ワークロード・スキーム

例9-30に、eastdsまたはwestdsのいずれかのデータベースでaccounts表を更新できる一般ワークロードの双方向レプリケーション・スキームを示します。各データベースは、accounts表に対してマスターおよびサブスクライバの両方になります。


注意:

RETURN TWOSAFE戻りサービスを構成して双方向の分散ワークロード・レプリケーション・スキームを使用しないでください。

例9-30 双方向の分散ワークロード・スキーム

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE accounts
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE accounts
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast";

要素をこの手法でレプリケートする場合、アプリケーションでは、各データベースへの書込みを調整して、同じデータに同時に更新が行われないようにする必要があります。更新競合を管理するには、BINARY(8)型のタイムスタンプ列をレプリケート表に含め、CREATE REPLICATION文にCHECK CONFLICTS句を含めてタイムスタンプ比較を有効にします。更新競合の管理方法の詳細は、第14章「レプリケーション競合の解消」を参照してください。

例9-31では、accounts表にtstampタイムスタンプ列が含まれています。CREATE REPLICATION文は、CHECK CONFLICTS句が含まれるように変更されています。

例9-31 更新競合の管理

CREATE TABLE accounts (custname VARCHAR2(30) NOT NULL,
                       address VARCHAR2(80),
                       curbalance DEC(15,2),
                       tstamp BINARY(8),
                       PRIMARY KEY (custname));

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE accounts
  CHECK CONFLICTS BY ROW TIMESTAMP
    COLUMN tstamp
    UPDATE BY SYSTEM
    ON EXCEPTION ROLLBACK WORK
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE accounts
  CHECK CONFLICTS BY ROW TIMESTAMP
    COLUMN tstamp
    UPDATE BY SYSTEM
    ON EXCEPTION ROLLBACK WORK
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast";

スクリプトによるレプリケーション・スキームの作成

レプリケーション・スキームをスクリプトで作成すると、時間の節約および誤りの回避に有効です。この項では、Perlを使用してレプリケーション・スキームの作成を自動化する場合の推奨事項をいくつか示します。

例9-32に示す一般的なワークロードの双方向スキームについて考えてみます。5つの表accounts、sales、orders、inventoryおよびcustomersへの要素記述への入力を手動で行うと、時間がかかり、エラーも発生しやすくなります。

例9-32 一般ワークロードの双方向レプリケーション・スキーム

CREATE REPLICATION bigscheme
ELEMENT elem_accounts_1 TABLE accounts
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE accounts
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast"
ELEMENT elem_sales_1 TABLE sales
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_sales_2 TABLE sales
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast"
ELEMENT elem_orders_1 TABLE orders
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_orders_2 TABLE orders
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast"
ELEMENT elem_inventory_1 TABLE inventory
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_inventory_2 TABLE inventory
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast"
ELEMENT elem_customers_1 TABLE customers
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_customers_2 TABLE customers
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast";

多くの場合、スクリプトを使用してレプリケーション・スキームの作成プロセスを自動化するとより効率的です。たとえば、例9-33に示すPerlスクリプトを使用して、例9-32に示したスキームを作成できます。

例9-33 レプリケーション・スキーム作成でのPerlスクリプトの使用

@tables = qw(
  accounts
  sales
  orders
  inventory
  customers
);

print "CREATE REPLICATION bigscheme";

foreach $table (@tables) {
  $element = $table;
  $element =~ s/repl\./elem\_/;

  print "\n";
  print " ELEMENT $element\_1 TABLE $table\n";
  print " MASTER westds ON \"westcoast\"\n";
  print " SUBSCRIBER eastds ON \"eastcoast\"\n";
  print " ELEMENT $element\_2 TABLE $table\n";
  print " MASTER eastds ON \"eastcoast\"\n";
  print " SUBSCRIBER westds ON \"westcoast\"";
 }
print ";\n";

例9-33の@tables配列は、データベースなどの他の一部のソースから取得できます。たとえば、Perl文でttIsqlおよびfを使用して、所有者名がreplのWestDSNデータベース内のすべての表に対して@tables配列を生成できます。

@tables = 'ttIsql -e "tables; quit" WestDSN
           | grep " REPL\."';

例9-34に、WestDSNデータベース内のすべてのrepl表に対してレプリケーション・スキームを作成する例9-33のスクリプトの変更バージョンを示します。grep出力から余分な空白および改行を削除するには、置換を行う必要があります。

例9-34 WestDSNにあるすべての表に対するレプリケーション・スキーム作成のためのPerlスクリプト

@tables = 'ttIsql -e "tables; quit" WestDSN
           | grep " REPL\."';

print "CREATE REPLICATION bigscheme";

foreach $table (@tables) {
  $table =~ s/^\s*//; # Remove extra spaces
  $table =~ s/\n//; # Remove line feeds
  $element = $table;
  $element =~ s/repl\./elem\_/;

  print "\n";
  print " ELEMENT $element\_1 TABLE $table\n";
  print " MASTER westds ON \"westcoast\"\n";
  print " SUBSCRIBER eastds ON \"eastcoast\"\n";
  print " ELEMENT $element\_2 TABLE $table\n";
  print " MASTER eastds ON \"eastcoast\"\n";
  print " SUBSCRIBER westds ON \"westcoast\"";
 }
print ";\n";
  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引