1. レプリケーション・ガイド
  2. レプリケーション・スキームの属性とオプションの定義
  3. RETURNサービスの使用

RETURNサービスの使用

RETURNサービスを指定してレプリケーション・スキームを構成すると、レプリケーション・データが、レプリケーション・スキーム内のデータベース上で一貫していることをより高いレベルの信頼性を持って保証できます。

ノート:

この項では、RETURNサービスに精通していることを前提にしています。RETURNサービスの概要は、「データベース間の更新のコピー」を参照してください。

この項では、RETURN RECEIPTおよびRETURN TWOSAFEサービスの構成方法および管理方法について説明します。CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文を使用して、レプリケーション・スキームで定義された任意のスタンバイまたはサブスクライバの表要素およびデータベース要素に対してRETURNサービスを指定できます。デフォルトはNO RETURNサービス(非同期レプリケーション)で、最適なパフォーマンス・オプションです。

ノート:

ttRepXactStatusプロシージャを使用してRETURN RECEIPTトランザクションまたはRETURN TWOSAFEトランザクションのステータスを確認できます。「RETURNサービス・トランザクションのステータスの確認」を参照してください。

次の項では、レプリケーション・スキームで使用できるRETURNサービスを説明します。

RETURN RECEIPT

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

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

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

ノート:

また、タイムアウトが特定の回数発生した後、RETURN RECEIPTサービスを無効にするようにレプリケーション・エージェントを構成できます。「RETURNサービスのタイムアウト時間の設定」を参照してください。

構成可能なタイムアウト時間内にスタンバイまたはサブスクライバでトランザクションの受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。

次の例では、アクティブ・スタンバイ・ペアのRETURN RECEIPTを定義します。この例では、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN RECEIPTサービスが有効になります。 

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT;

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

ノート:

RETURN RECEIPTサービスを使用するクラシック・レプリケーション・スキームのその他の例は、「複数サブスクライバのクラシック・レプリケーション・スキーム」を参照してください。 

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

RETURN RECEIPT BY REQUEST

RETURN RECEIPTは、すべてのトランザクションに対して受信の通知を有効にします。

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

RETURN RECEIPT BY REQUESTを指定する場合は、ttRepSyncSet組込みプロシージャをアクティブ・データベースまたはマスター・データベースで使用して、トランザクションに対してRETURN RECEIPTサービスを有効にする必要があります。RETURN RECEIPTサービスを有効にするコールは、トランザクションの一部である必要があります(AutoCommitは無効である必要があります)。

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

次の例では、アクティブ・スタンバイ・ペアのRETURN RECEIPT BY REQUESTを定義します。この例では、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN RECEIPTサービスが有効になります。 

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT BY REQUEST;

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

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

ttRepSyncSetを使用して、RETURNサービスをリクエストできます。確認応答のRETURN RECEIPTを必要とするトランザクションをコミットする前に、ttRepSyncSetをコールします。次の例は、最初の列が0x01に、2つ目の列が45秒のタイムアウト値に設定されたRETURN RECEIPTに対する要求を設定します。 

Command> autocommit off;
Command> CALL ttRepSyncSet(0x01, 45, 1);

ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次の例は、前述の例でttRepSyncSet組込みプロシージャを使用して設定された値を示しています。 

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

Oracle TimesTen In-Memory DatabaseリファレンスのttRepSyncSetおよびttRepSyncGetを参照してください。

RETURN TWOSAFE

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

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

ノート:

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

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

  • アクティブ・スタンバイ・ペアを使用している場合、RETURN TWOSAFEを使用してレプリケートされた操作が含まれているトランザクションでは、PassThroughを0 (ゼロ)より大きい値に設定することはできません。PassThroughが0より大きい場合は、エラーが返され、トランザクションをロールバックする必要があります。

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

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

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

次の例では、アクティブ・スタンバイ・ペアのRETURN TWOSAFEサービスを定義します。この例では、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN TWOSAFEサービスが有効になります。 

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN TWOSAFE;

次の例では、クラシック・レプリケーション・スキームの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 BY REQUEST

RETURN TWOSAFEは、すべてのトランザクションに対してスタンバイ・データベースでのコミットの通知を有効にします。

RETURN TWOSAFE BY REQUEST句を使用すると、アプリケーションで識別される特定のトランザクションのみに関するスタンバイでのコミットの通知を有効にできます。

スタンバイ・データベースまたはサブスクライバ・データベースにRETURN TWOSAFE BY REQUESTを指定する場合は、アクティブ・データベースまたはマスター・データベースでttRepSyncSet組込みプロシージャを使用して、トランザクションに対してRETURN TWOSAFEサービスを有効にする必要があります。RETURN TWOSAFEサービスを有効にするコールは、トランザクションの一部である必要があります(autocommitは無効である必要があります)。

ALTER TABLE文を使用してRETURN TWOSAFE BY REQUESTトランザクションの一部であるレプリケートされた表を変更すると、その表は結果的にTWOSAFE BY REQUESTトランザクションの一部として実行されなくなります。そのかわり、ALTER TABLE操作の前にコミットが実行されるため、ALTER TABLE操作は成功し、その結果、ALTER TABLE操作はRETURN TWOSAFE BY REQUESTトランザクションの一部ではない新しいトランザクションで実行されることになります。

ノート:

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

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

アクティブ・スタンバイ・ペアを使用している場合、RETURN TWOSAFEを使用してレプリケートされた操作が含まれているトランザクションでは、PassThroughを0 (ゼロ)より大きい値に設定することはできません。PassThroughが0より大きい場合は、エラーが返され、トランザクションをロールバックする必要があります。

次の例では、アクティブ・スタンバイ・ペアのRETURN TWOSAFE BY REQUESTサービスを定義します。この例では、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN TWOSAFE BY REQUESTサービスが有効になります。 

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN TWOSAFE BY REQUEST;

サブスクライバでのコミットの確認が必要なトランザクションのコミットをコールする前に、ttRepSyncSet組込みプロシージャをコールしてRETURNサービスをリクエストし、タイムアウト時間を45秒に設定し、タイムアウト・エラー発生時の動作をNO ACTION(1)に指定します。 

Command> CALL ttRepSyncSet(0x01, 45, 1);

ttRepSyncGet組込みプロシージャを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。 

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

この例では、クラシック・レプリケーション・スキームのRETURN TWOSAFE BY REQUESTを定義します。マスター・データベース(databaseA)でコミットされた特定のトランザクションがサブスクライバ(databaseB)でもコミットされたことの確認を有効にする場合、要素記述(a)は次のようになります。 

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

サブスクライバでのコミットの確認が必要なトランザクションのコミットをコールする前に、ttRepSyncSet組込みプロシージャをコールしてRETURNサービスをリクエストし、タイムアウト時間を45秒に設定し、タイムアウト・エラー発生時の動作をNO ACTION(1)に指定します。 

Command> CALL ttRepSyncSet(0x01, 45, 1);

ttRepSyncGet組込みプロシージャを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。 

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

NO RETURN

NO RETURN句を使用して、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスのいずれか(有効にされているサービスに応じて)を明示的に無効にできます。

デフォルト設定はNO RETURNです。この属性は、通常、以前にALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文で定義されたRETURNサービスを削除するためにレプリケーション・スキームを変更する場合のみ使用されます。

クラシック・レプリケーション・スキームでの各サブスクライバに対する異なるRETURNサービスの指定

クラシック・レプリケーション・スキームでは、CREATE REPLICATION文またはALTER REPLICATION文の各SUBSCRIBER句でリストされるサブスクライバの表要素およびデータベース要素に対して、異なるRETURNサービスを指定できます。

次の例は、サブスクライバ(SubDatabase1とSubDatabase2)ごとに異なるRETURNサービス属性を定義する個別のSUBSCRIBER句を示しています。 

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

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

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

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

RETURNサービスのいずれかで構成されたレプリケーション・スキームでは、タイムアウトを発生させることができます。

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

  • アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、RETURN WAIT TIMEで指定した時間内にスタンバイ・データベースがアクティブ・データベースに確認応答を送信できない場合にタイムアウトが発生します。

    タイムアウト時間内にスタンバイ・データベースでアクティブ・データベースからのトランザクションの更新を確認できない場合、アプリケーションは、コミット・リクエストに対するerrRepReturnFailed警告を受信します。

  • クラシック・レプリケーション・スキームでは、RETURN WAIT TIMEで指定した時間内にいずれかのサブスクライバがマスターに確認応答を送信できない場合にタイムアウトが発生します。

    サブスクライバ障害が発生した場合、ユーザーまたはマスター・レプリケーション・エージェントによりレプリケーション状態がstopに設定される可能性があります。サブスクライバが、RETURNサービスを使用しているトランザクションを確認できず、マスターに対してタイムアウトする場合もあります。

    タイムアウト時間内にいずれかのサブスクライバがトランザクション更新を確認できない場合、アプリケーションは、コミット・リクエストに対するerrRepReturnFailed警告を受信します。

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

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

  • CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文にRETURN WAIT TIMEを指定します。

    RETURN WAIT TIME属性は、RETURNサービスの応答を待機する時間(秒)を指定します。値が0(ゼロ)の場合は、待機なしを意味します。

    次の例は、アクティブ・スタンバイ・ペアのアクティブ・データベース(master1)を変更して、RETURNサービスの待機時間を25秒に設定します。 

    Command> ALTER ACTIVE STANDBY PAIR
  ALTER STORE master1 SET RETURN WAIT TIME 25;

  • returnWaitパラメータの新しいタイムアウト値を指定し、アクティブ・データベース(アクティブ・スタンバイ・ペアの場合)またはマスター・データベース(クラシック・レプリケーション・スキームの場合)のいずれかでttRepSyncSet組込みプロシージャをコールすることにより、異なるRETURNサービスのタイムアウト時間をプログラムで指定します。

    次の例は、ttRepSyncSetを使用して、RETURNサービスの待機時間を25秒に設定する方法を示します。 

    Command> CALL ttRepSyncSet (0x01, 25, 1);

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

ノート:

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

この例では、双方向クラシック・レプリケーション・スキームに含まれる両方のデータベースのタイムアウト期間を設定します。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;

この例は、タイムアウト時間を再設定する方法を示しています。タイムアウト時間を45秒に再設定するには、ttRepSyncSet組込みプロシージャを使用します。requestReturnおよびlocalAction値を再設定しないようにするには、NULLを指定します。 

Command> CALL ttRepSyncSet(NULL, 45, NULL);

RETURNサービス・ブロッキングの手動による無効化

レプリケーションが停止した場合、またはレプリケート・システムのパフォーマンスにRETURNサービス・タイムアウト障害が悪影響を及ぼし始めた場合は、なんらかの方法で対処する必要があります。

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

ノート:

タイムアウトへの対応方法の1つは、RETURNサービスを無効にすることです。RETURNサービスが有効にされているか無効にされているかを確認するには、ttRepSyncSubscriberStatus組込みプロシージャをコールします。「RETURNサービスが無効になっているかどうかの確認」を参照してください。

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

  • ALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文を使用して、RETURN RECEIPTブロッキングを無効にします。RETURN RECEIPTブロッキングを無効にすると決めた場合、これを再度有効にするという判断は、RETURN RECEIPTトランザクションがタイムアウトしないと確信できるレベルに基づいて行います。

    次の例は、ALTER ACTIVE STANDBY PAIR文を使用して、10回の失敗後にRETURN RECEIPTを無効にします。 

    Command> ALTER ACTIVE STANDBY PAIR
  ALTER STORE master1 SET DISABLE RETURN ALL 10;

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

RETURNサービスの障害およびリカバリのポリシーの設定

手動でRETURNサービス・タイムアウト障害に対処するかわりに、RETURNサービス障害およびリカバリ・ポリシーをレプリケーション・スキームに設定して対処することもできます。

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

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

これらの属性によって設定したポリシーは、変更されるまで適用されます。DURABLE COMMITを除いて、これらのポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。

RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED

レプリケーションが一時停止または停止した場合は、RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED属性によって、RETURN RECEIPTまたはRETURN TWOSAFEサービスを継続して有効にするか無効にするかが決定されます。

  • アクティブ・スタンバイ・ペアでは、次のいずれかの場合、レプリケーションは停止したとみなされます。

    • アクティブ・レプリケーション・エージェントが失敗したか、または、(たとえば、ttAdmin -repStop activeにより)明示的に停止されている場合。

    • 指定されたFAILTHRESHOLD値を超えて失敗したスタンバイ・マスターがレプリケーションを停止した場合。スタンバイ・マスターが失敗した際にレプリケーションが停止しても、TimesTenはスタンバイ・マスターをバイパスして、アクティブ・マスターからすべてのサブスクライバへ直接レプリケートすることに注意してください。スタンバイ・マスターがリカバリすると、欠落したすべての更新がスタンバイ・マスターに伝播されます。

  • クラシック・レプリケーション・スキームでは、次のいずれかの場合、レプリケーションは停止したとみなされます。

    • (たとえば、ttAdmin -repStop masterにより)マスター・レプリケーション・エージェントが明示的に停止されている場合。

    • (たとえば、ttRepAdmin -state pause subscriberにより)サブスクライバ・データベースのレプリケーションの状態がpauseまたはstopに設定されている場合。

    • 指定されたFAILTHRESHOLD値を超えて失敗したサブスクライバがレプリケーションを停止した場合。

ノート:

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

レプリケーションが次の句で停止されているときは、RETURNサービスを有効または無効にできます。

  • RETURN SERVICES OFF WHEN REPLICATION STOPPEDは、レプリケーションが停止するとRETURNサービスを無効にし、RETURN RECEIPTサービス使用時のデフォルト設定です。

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

次の例では、アクティブ・スタンバイ・ペアでレプリケーションが停止した場合のRETURNサービスを定義します。この例は、RETURN TWOSAFE RETURNサービスを使用するアクティブ・スタンバイ・ペアを作成し、レプリケーションが停止したときにRETURNサービスが無効になるよう定義します(デフォルトとは逆)。 

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN TWOSAFE 
  STORE master2 RETURN SERVICES OFF WHEN REPLICATION STOPPED;

この例では、クラシック・レプリケーション・スキームでレプリケーションが停止した場合のRETURNサービスを定義します。

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 -state pauseを使用してsubscriber1をpause状態に設定できます。 

ttRepAdmin -receiver -name subscriber1 -state pause masterds

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

ttRepAdmin -receiver -name subscriber1 -state start masterds

ノート:

「サブスクライバのレプリケーション状態の設定」を参照してください。サブスクライバの状態をstopに設定することはなるべく控える必要があります。このサブスクライバへのレプリケーションを停止するだけでなく、更新をすべて破棄することになるからです。サブスクライバをstop状態に設定した場合は、複製を実行してサブスクライバをリストアする必要があります。

DISABLE RETURN

DISABLE RETURN値を設定すると、データベースは、RETURN WAIT TIMEで設定されたタイムアウト時間を超えているRETURN RECEIPTトランザクションおよびRETURN TWOSAFEトランザクションの数を追跡します。

タイムアウト数がDISABLE RETURNで設定した最大値を超えると、アプリケーションは、デフォルトのレプリケーション・サイクルに戻り、レプリケート対象の更新に対するスタンバイまたはサブスクライバからの確認応答を待機しなくなります。

RETURNサービス・ブロッキングが無効の場合、アクティブ・データベースまたはマスター・データベースのアプリケーションは、レプリケーション更新を受信またはコミットしたスタンバイまたはサブスクライバからの確認応答を待機している間、処理をブロックしなくなります。RETURNサービスが有効であるか無効であるかに関係なく、トランザクションは引き続きスタンバイまたはサブスクライバにレプリケートされます。RETURNサービスが無効な場合、トランザクションは非同期モードで送信されます。アクティブ・データベースまたはマスター・データベースは、レプリケートされた更新の各バッチに関する、スタンバイ・データベースまたはサブスクライバ・データベースからの確認応答を引き続きリスニングします。

DISABLE RETURNを次のように構成します。

  • アクティブ・スタンバイ・ペアの場合、SUBSCRIBERを指定することは、ALLを指定することと同じです。どちらの設定でも、スタンバイ・データベースが参照されます。

  • クラシック・レプリケーション・スキームの場合、DISABLE RETURN SUBSCRIBERを設定して、タイムアウトしたサブスクライバに対してのみRETURNサービス・ブロッキングを無効にするポリシーを設定するか、またはDISABLE RETURN ALLを設定して、すべてのサブスクライバに対してRETURNサービス・ブロッキングを無効にするポリシーを設定できます。

ノート:

ttRepSyncSubscriberStatus組込みプロシージャを使用して、スタンバイ・データベースまたは特定のサブスクライバがDISABLE RETURN障害ポリシーによって無効にされているかどうかを確認できます。

DISABLE RETURN障害ポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。RESUME RETURNなしでDISABLE RETURNが指定されている場合、データベースのレプリケーション・エージェントが再起動されるまでRETURNサービスはオフのままです。

  • アクティブ・スタンバイ・ペアの場合、この障害ポリシーは、レプリケーション・エージェントを停止し、NumFailuresに0 (ゼロ値)を設定してDISABLE RETURNを指定することにより取り消すことができます。

  • クラシック・レプリケーション・スキームの場合、この障害ポリシーは、レプリケーション・エージェントを停止し、NumFailuresに0 (ゼロ値)を設定してDISABLE RETURN SUBSCRIBERまたはDISABLE RETURN ALLのいずれかを指定することにより取り消すことができます。

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

障害ポリシーをトリガーするタイムアウトのカウントは、レプリケーション・エージェントを再起動したとき、DISABLE RETURN値を0に設定したとき、またはRETURNサービス・ブロッキングがRESUME RETURNによって再度有効にされたときにリセットされます。

この例では、アクティブ・スタンバイ・ペアに対してDISABLE RETURNを設定する方法を示します。master1データベースからmaster2データベースに更新をレプリケートするように、CREATE ACTIVE STANDBY PAIR文を構成します。CREATE ACTIVE STANDBY PAIR文では、NumFailuresの値を5にしてRETURN RECEIPTおよびDISABLE RETURN ALLの使用が指定されています。RETURN WAIT TIMEは30秒に設定されています。 

CREATE ACTIVE STANDBY PAIR 
   master1, 
   master2 
   RETURN RECEIPT 
   STORE master1 
   DISABLE RETURN ALL 5
   RETURN WAIT TIME 30;

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

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

RESUME RETURN

RETURNサービス・ブロッキングがDISABLE RETURNによって無効になっている場合、RESUME RETURN属性は、RETURNサービスの再有効化に関するポリシーを設定します。RETURNサービス・リカバリ・ポリシーは、RESUME RETURN属性を設定し、再開待機時間の値を指定して設定できます。

RETURNサービス・ブロッキングがスタンバイ・データベースまたはサブスクライバ・データベースに関して無効になっており、待機時間がRESUME RETURNに定義されていると、次の事象が発生します。

  • アクティブ・データベースまたはマスター・データベースのアプリケーションは、スタンバイまたはサブスクライバからの確認応答を待機している間、処理をブロックしなくなります。トランザクションは引き続きスタンバイまたはサブスクライバに非同期モードでレプリケートされます。アクティブ・データベースまたはマスター・データベースは、レプリケートされた更新の各バッチに関する、スタンバイ・データベースまたはサブスクライバ・データベースからの確認応答を引き続きリスニングします。

  • RETURNサービス・ブロッキングが無効な場合、RESUME RETURNは最後のトランザクションのコミット確認応答時間を評価して、RESUME RETURNにより構成されている待機時間制限よりも待機時間が短いかどうかを確認します。コミット確認応答時間がRESUME RETURNにより設定されている待機時間制限よりも短い場合、TimesTenは、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスを再度有効にします。

    ノート:

    コミット確認応答時間とは、アプリケーションがコミットを実行してから、アクティブ・データベースまたはマスター・データベースがスタンバイまたはサブスクライバから更新の確認応答を受信するまでに経過した時間のことです。

    確認応答された最後のトランザクションの待機時間をTimesTenが評価した後に、現在のトランザクションはスタンバイまたはサブスクライバにレプリケートされます。最後のトランザクションからの待機時間が評価された後、RETURNサービスが再度有効にされ、その後、現在のトランザクションが送信されます。

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

次の例では、アクティブ・スタンバイ・ペアにRESUME RETURN を設定します。RETURN RECEIPTブロッキングがmaster2に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、アクティブ・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の8ミリ秒未満でその更新の確認応答が受け取られた場合にかぎり、アクティブが更新の確認応答をスタンバイから受け取るとすぐに、RETURN RECEIPTブロッキングがmaster2に対して再度有効にされます。 

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT
  STORE master1
  DISABLE RETURN ALL 5
  RESUME RETURN 8;

次の例では、クラシック・レプリケーション・スキームにRESUME RETURNを設定します。RETURN RECEIPTブロッキングがsubscriber1に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、マスター・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の8ミリ秒未満でその更新の確認応答が受け取られた場合にかぎり、マスターが更新の確認応答をサブスクライバから受け取るとすぐに、RETURN RECEIPTブロッキングがsubscriber1に対して再度有効にされます。 

CREATE REPLICATION myscheme
 ELEMENT e TABLE ttuser.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;

DURABLE COMMIT

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

また、DURABLE COMMITをONに設定すると、レプリケーション・エージェントが実行中であるか停止中であるかに関係なく、RETURNサービス・ブロッキングが無効になっている場合、永続コミットが発行されます。また、ttRepStateSave組込みプロシージャでスタンバイ・データベースまたはサブスクライバ・データベースがfailedとしてマークされている場合も、永続コミットが発行されます。

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

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

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT
  STORE master1
  DISABLE RETURN ALL 5
  DURABLE COMMIT ON
  RESUME RETURN 8;

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サービスを使用している場合、LOCAL COMMIT ACTIONを設定して、タイムアウト時のアクティブ・レプリケーション・エージェントまたはマスター・レプリケーション・エージェントの応答方法を指定できます。ttRepSyncSet組込みプロシージャのlocalActionパラメータを使用して、特定のトランザクションに対するこの設定を無効にすることができます。

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

  • COMMIT: タイムアウト時、コミット関数はcommitを実行して、トランザクションをローカルに終了しようとします。同じトランザクション上でこれ以上の処理を行うことはできません。

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

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

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

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