| Oracle® TimesTen In-Memory Database開発者および管理者ガイド 11gリリース2 (11.2.2) B66443-07 |
|
 前 |
 次 |
次の項では、アクティブ・スタンバイ・ペアとクラシック・レプリケーション(マスターとサブスクライバが関与)の両方に対して構成可能なRETURNサービス・オプション、STORE属性、およびネットワーク操作について説明します。レプリケーション・スキーム間の相違については、各項で詳細に説明されます。
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サービスを説明します。
クラシック・レプリケーション・スキームでは、CREATE REPLICATION文またはALTER REPLICATION文の各SUBSCRIBER句でリストされるサブスクライバの表要素およびデータベース要素に対して、異なるRETURNサービスを指定できます。
例4-1に、SubDatabase1とSubDatabase2に異なるRETURNサービス属性を定義する個別のSUBSCRIBER句を示します。
例4-1 各サブスクライバで異なるRETURNサービス
CREATE REPLICATION Owner.SchemeName ELEMENT ElementNameElementType MASTER DatabaseName ON "HostName" SUBSCRIBER SubDatabase1 ON "HostName" ReturnServiceAttribute1 SUBSCRIBER SubDatabase2 ON "HostName" ReturnServiceAttribute2;
また、要素で定義されるすべてのサブスクライバに、同じRETURNサービス属性を指定することもできます。例4-2に、1つのSUBSCRIBER句を使用して、SubDatabase1とSubDatabase2の両方に同じRETURNサービス属性を定義する例を示します。
TimesTenでは、アプリケーションをレプリケーション・メカニズムと疎結合または同期するためにオプションのRETURN RECEIPTサービスが提供されています。
アクティブ・スタンバイ・ペアでは、RETURN RECEIPT句を指定して、スタンバイ・データベースのRETURN RECEIPTサービスを有効にできます。RETURN RECEIPTが有効になっている場合、アプリケーションがアクティブ・データベースの要素に対するトランザクションをコミットすると、スタンバイがトランザクション更新の受信を確認するまでブロックされたままになります。
クラシック・レプリケーション・スキームでは、RETURN RECEIPT句を指定して、サブスクライバ・データベースのRETURN RECEIPTサービスを有効にできます。RETURN RECEIPTが有効になっている場合、アプリケーションは、マスター・データベースの要素に対するトランザクションをコミットすると、サブスクライバがトランザクション更新の受信を確認するまでブロックされたままになります。マスターが複数のサブスクライバに要素をレプリケートしている場合、すべてのサブスクライバがトランザクション更新の受信を確認するまで、アプリケーションはブロックされたままになります。
|
注意: また、タイムアウトが特定の回数発生した後、RETURN RECEIPTサービスを無効にするようにレプリケーション・エージェントを構成できます。タイムアウトの詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。 |
構成可能なタイムアウト時間内にスタンバイまたはサブスクライバでトランザクションの受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。
例4-3 アクティブ・スタンバイ・ペアに対するRETURN RECEIPTの定義
次の例は、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN RECEIPTサービスが有効になります。
Command> CREATE ACTIVE STANDBY PAIR > master1, > master2 > RETURN RECEIPT;
例4-4 クラシック・レプリケーション・スキームに対するRETURN RECEIPTの定義
マスター・データベース(masterds)のtab表に対してコミットしたすべてのトランザクションがサブスクライバ(subscriberds)で受信されたことを確認する場合、要素記述(e)は次のようになります。
注意: RETURN RECEIPTサービスを使用するクラシック・レプリケーション・スキームのその他の例は、例9-5および例9-6を参照してください。
ELEMENT e TABLE tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT
RETURN RECEIPTは、すべてのトランザクションに対して受信の通知を有効にします。RETURN RECEIPT BY REQUEST句を使用すると、アプリケーションで識別される特定のトランザクションに対してのみ確認応答の受信通知を有効にできます。
RETURN RECEIPT BY REQUESTを指定する場合は、ttRepSyncSet組込みプロシージャをアクティブ・データベースまたはマスター・データベースで使用して、トランザクションに対してRETURN RECEIPTサービスを有効にする必要があります。RETURN RECEIPTサービスを有効にするコールは、トランザクションの一部である必要があります(AutoCommitは無効である必要があります)。
構成可能なタイムアウト時間内にスタンバイ・データベースまたはサブスクライバ・データベースでトランザクション更新の受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
例4-5 アクティブ・スタンバイ・ペアに対するRETURN RECEIPT BY REQUEST
次の例は、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN RECEIPTサービスが有効になります。
Command> CREATE ACTIVE STANDBY PAIR > master1, > master2 > RETURN RECEIPT BY REQUEST;
例4-6 クラシック・レプリケーション・スキームに対するRETURN RECEIPT BY REQUEST
マスター・データベース(masterds)のtab表に対してコミットした特定のトランザクションがサブスクライバ(subscriberds)で受信されたことの確認を有効にする場合、要素記述(e)は次のようになります。
ELEMENT e TABLE tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT BY REQUEST
例4-7 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に関する説明を参照してください。
TimesTenでは、アプリケーションをレプリケーション・メカニズムと完全に同期するために、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サービス・タイムアウト時間の設定」を参照してください。
例4-8 アクティブ・スタンバイ・ペアでのRETURN TWOSAFE
次の例は、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN TWOSAFEサービスが有効になります。
Command> CREATE ACTIVE STANDBY PAIR > master1, > master2 > RETURN TWOSAFE;
例4-9 クラシック・レプリケーション・スキームでの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は、すべてのトランザクションに対してスタンバイ・データベースでのコミットの通知を有効にします。RETURN TWOSAFE BY REQUEST句を使用すると、アプリケーションで識別される特定のトランザクションのみに関するスタンバイでのコミットの通知を有効にできます。
スタンバイ・データベースまたはサブスクライバ・データベースにRETURN TWOSAFE BY REQUESTを指定する場合は、アクティブ・データベースまたはマスター・データベースでttRepSyncSet組込みプロシージャを使用して、トランザクションに対してRETURN TWOSAFEサービスを有効にする必要があります。RETURN TWOSAFEサービスを有効にするコールは、トランザクションの一部である必要があります(autocommitは無効である必要があります)。
ALTER TABLE文を使用して、RETURN TWOSAFE BY REQUESTトランザクションの一部であるレプリケート表を変更することはできません。DDLCommitBehavior=0(デフォルト)の場合、ALTER TABLE操作の前にコミットが実行されるためこのALTER TABLE操作は成功し、ALTER TABLE操作はRETURN TWOSAFE BY REQUESTトランザクションの一部ではない新しいトランザクションで実行されることになります。DDLCommitBehavior=1の場合、ALTER TABLE操作の結果はエラー8051になります。
タイムアウト時間内にスタンバイまたはサブスクライバでトランザクションのコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。アプリケーションではタイムアウトの処理方法を選択できます。「RETURNサービス・タイムアウト時間の設定」を参照してください。
アクティブ・スタンバイ・ペアを使用している場合、RETURN TWOSAFEを使用してレプリケートされた操作が含まれているトランザクションでは、PassThroughを0 (ゼロ)より大きい値に設定することはできません。PassThroughが0より大きい場合は、エラーが返され、トランザクションをロールバックする必要があります。
例4-10 アクティブ・スタンバイ・ペアに対するRETURN TWOSAFE BY REQUST
次の例は、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.
例4-11 クラシック・レプリケーション・スキームに対する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句を使用して、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスのいずれか(有効にされているサービスに応じて)を明示的に無効にできます。デフォルト設定はNO RETURNです。この属性は、通常、以前にALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文で定義されたRETURNサービスを削除するためにレプリケーション・スキームを変更する場合のみ使用されます。例10-13を参照してください。
CREATE ACTIVE STANDBY PAIR、ALTER ACTIVE STANDBY PAIR、CREATE REPLICATIONおよびALTER REPLICATION文のSTORE属性句は、RETURNサービス、圧縮、タイムアウト、永続コミット動作および表定義チェックのオプション動作を設定するために使用されます。クラシック・レプリケーション・スキームでは、競合レポートを表レベルで定義することもできます。
|
注意: STORE属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の「CREATE ACTIVE STANDBY PAIR」および「CREATE REPLICATION」を参照してください。 |
クラシック・レプリケーション・スキームを使用している場合、FAILTHRESHOLDおよびTIMEOUT属性は、特定のクラシック・レプリケーション・スキーム定義に対して固有に設定できます。つまり、これらの属性は、レプリケート・データベースに異なるクラシック・レプリケーション・スキーム定義を適用している場合に、異なって設定できます。これは他の属性には適用されず、他の属性は、すべてのクラシック・レプリケーション・スキーム定義で同じである必要があります。たとえば、1つのクラシック・レプリケーション・スキームにPORT属性を設定すると、すべてのクラシック・レプリケーション・スキームにその設定が適用されます。STORE句を使用してFAILTHRESHOLD属性を設定するクラシック・レプリケーション・スキームの例は、例9-5を参照してください。
次の各項では、いくつかのSTORE属性について説明します。
次に、「RETURNサービスの使用」で説明されているRETURNサービスの1つを使用して構成されているレプリケーション・スキームでタイムアウトが発生する状況を説明します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、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サービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。 |
例4-12 双方向(クラシック)レプリケーション・スキームの両方のデータベースでのタイムアウト時間の設定
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;
例4-13 タイムアウト時間の再設定
タイムアウト時間を45秒に再設定するには、ttRepSyncSet組込みプロシージャを使用します。requestReturnおよびlocalAction値を再設定しないようにするには、NULLを指定します。
Command> CALL ttRepSyncSet(NULL, 45, NULL);
次の項では、RETURNサービス・トランザクションで発生したタイムアウトを検出および対応する方法について説明します。
|
注意: タイムアウトへの対応方法の1つは、RETURNサービスを無効にすることです。RETURNサービスが有効にされているか、または無効にされているかを確認するには、ttRepSyncSubscriberStatus組込みプロシージャをコールするか、またはttRepReturnTransitionTrap SNMPトラップを使用します。詳細は、「RETURNサービスが無効にされているかどうかの確認」を参照してください。 |
レプリケーションが停止した場合、またはレプリケート・システムのパフォーマンスにRETURNサービス・タイムアウト障害が悪影響を及ぼし始めた場合は、なんらかの方法で対処する必要があります。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 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 RECEIPTまたはRETURN TWOSAFEサービスを継続して有効にするか、無効にするかが決定されます。
アクティブ・スタンバイ・ペアでの「停止」とは、(ttAdmin -repStop activeなどによって)アクティブ・レプリケーション・エージェントが停止されたこと、または(ttRepAdmin -state stop standbyなどによって)スタンバイ・データベースのレプリケーション状態がアクティブ・データベースに対してstopまたはpauseに設定されることを意味しています。指定したFAILTHRESHOLD値を超えている障害が発生したスタンバイ・データベースは、failed状態に設定されますが、最終的にはアクティブ・データベースのレプリケーション・エージェントによってstop状態に設定されます。
クラシック・レプリケーション・スキームでの「停止」とは、(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サービス使用時のデフォルト設定です。
例4-14 アクティブ・スタンバイ・ペアに対するRETURN SERVICES ON WHEN REPLICATION STOPPED
次の例は、RETURN TWOSAFE RETURNサービスを使用するアクティブ・スタンバイ・ペアを作成し、レプリケーションが停止したときにRETURNサービスが無効になるよう(デフォルトとは逆)定義します。
Command> CREATE ACTIVE STANDBY PAIR > master1, > master2 > RETURN TWOSAFE > STORE master2 RETURN SERVICES OFF WHEN REPLICATION STOPPED;
アプリケーションでアクティブ・データベースmaster1への更新をコミットする場合は、ttRepAdminを使用してスタンバイ・データベースmaster2をstop状態に設定します。
ttRepAdmin -receiver -name master2 -state stop master1
アプリケーションは、レプリケーション状態がstartに再設定され、master2からRETURN RECEIPT確認応答を受信するまでこの確認応答を継続して待機します。
ttRepAdmin -receiver -name master2 -state start master1
例4-15 クラシック・レプリケーション・スキームに対する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 -receiver -name subscriber1 -state stop masterds
アプリケーションは、レプリケーション状態がstartに再設定され、subscriber1からRETURN RECEIPT確認応答を受信するまでこの確認応答を継続して待機します。
ttRepAdmin -receiver -name subscriber1 -state start masterds
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サービス・ブロッキングを無効にするポリシーを設定できます。
DISABLE RETURN障害ポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。RESUME RETURNなしでDISABLE RETURNが指定されている場合、データベースのレプリケーション・エージェントが再起動されるまでRETURNサービスはオフのままです。
アクティブ・スタンバイ・ペアの場合、この障害ポリシーは、レプリケーション・エージェントを停止し、DISABLE RETURNをNumFailuresの値を0 (ゼロ)にして指定すると取り消すことができます。
クラシック・レプリケーション・スキームの場合、この障害ポリシーは、レプリケーション・エージェントを停止し、DISABLE RETURN SUBSCRIBERまたはDISABLE RETURN ALLのいずれかをNumFailuresの値を0 (ゼロ)にして指定すると取り消すことができます。
DISABLE RETURNは、各サブスクライバのタイムアウトの累積カウントを保持します。複数のサブスクライバが存在する場合にDISABLE RETURN SUBSCRIBERを設定すると、レプリケーション・エージェントは、タイムアウトのしきい値に最初に達したサブスクライバのRETURNサービス・ブロッキングを無効にします。その後、他のいずれかのサブスクライバがタイムアウトのしきい値に達すると、レプリケーション・エージェントは、そのサブスクライバのRETURNサービス・ブロッキングも同様に無効にします。
障害ポリシーをトリガーするタイムアウトのカウントは、レプリケーション・エージェントを再起動したとき、DISABLE RETURN値を0に設定したとき、またはRETURNサービス・ブロッキングがRESUME RETURNによって再度有効にされたときにリセットされます。
例4-16 アクティブ・スタンバイ・ペアに対する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属性を設定するもう1つの例は、例4-18を参照してください。
例4-17 クラシック・レプリケーション・スキームに対する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確認応答を継続して待機します。
クラシック・レプリケーション・スキームにDISABLE RETURN属性を設定するもう1つの例は、例4-19を参照してください。
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 (ゼロ)に設定して取り消すことができます。
例4-18 アクティブ・スタンバイ・ペアに対するRESUME RETURN
RETURN RECEIPTブロッキングがmaster2に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、RETURN RECEIPTブロッキングは、アクティブ・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の8ミリ秒未満でその更新の確認応答が受け取られた場合にかぎり、アクティブが更新の確認応答をスタンバイから受け取るとすぐに、master2に対して再度有効にされます。
Command> CREATE ACTIVE STANDBY PAIR > master1, > master2 > RETURN RECEIPT > STORE master1 > DISABLE RETURN ALL 5 > RESUME RETURN 8;
例4-19 クラシック・レプリケーション・スキームに対するRESUME RETURN
RETURN RECEIPTブロッキングがsubscriber1に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、RETURN RECEIPTブロッキングは、マスター・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の8ミリ秒未満でその更新の確認応答が受け取られた場合にかぎり、マスターが更新の確認応答をサブスクライバから受け取るとすぐに、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属性を設定して、DISABLE RETURNでRETURNサービス・ブロッキングを無効にしたアプリケーションに永続コミット・ポリシーを指定できます。DURABLE COMMITをONに設定すると、アクティブ・データベースまたはマスター・データベースのDurableCommits一般接続属性が上書きされ、RETURNサービス・ブロッキングを無効にしたトランザクションに対して永続コミットが強制実行されます。
また、DURABLE COMMITをONに設定すると、レプリケーション・エージェントが実行中であるか停止中であるかに関係なく、RETURNサービス・ブロッキングが無効になっている場合、永続コミットが発行されます。また、ttRepStateSave組込みプロシージャでスタンバイ・データベースまたはサブスクライバ・データベースがfailedとしてマークされている場合も、永続コミットが発行されます。
クラシック・レプリケーション・スキームの場合、DURABLE COMMITは、サブスクライバが1つのみ存在する場合に役立ちます。ただし、2つのサブスクライバに同じデータをレプリケートし、一方のサブスクライバのRETURNサービス・ブロッキングを無効にした場合は、永続コミットを有効にするより、他方のサブスクライバを使用した方が、より高いパフォーマンスを得ることができます。
例4-20 アクティブ・スタンバイ・ペアでのDURABLE COMMIT ON
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;
例4-21 クラシック・レプリケーション・スキームでのDURABLE COMMIT ON
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;
RETURN TWOSAFEサービスを使用している場合、LOCAL COMMIT ACTIONを設定して、タイムアウト時のアクティブ・レプリケーション・エージェントまたはマスター・レプリケーション・エージェントの応答方法を指定できます。ttRepSyncSet組込みプロシージャのlocalActionパラメータを使用して、特定のトランザクションに対するこの設定を無効にすることができます。
TWOSAFEトランザクションのレプリケーション中にタイムアウトを受信した場合に、実行可能なアクションは次のとおりです。
COMMIT: タイムアウト時、コミット関数はcommitを実行して、トランザクションをローカルに終了しようとします。同じトランザクション上でこれ以上の処理を行うことはできません。
NO ACTION: タイムアウト発生時、コミット関数はアプリケーションに返され、トランザクションはコミット・コールを入力したときと同じ状態のままになりますが、アプリケーションはレプリケートされた表を更新できません。アプリケーションはコミットを再発行できます。これはデフォルトです。
コールしてエラーが返された場合は、「RETURNサービス・トランザクションのステータスの確認」で説明されているttRepXactStatusプロシージャを使用して、トランザクションのステータスを確認できます。エラーに応じて、アプリケーションで次のいずれかの処理を選択できます。
コミット・コールの再発行: この処理は、RETURN TWOSAFEレプリケーション・サイクル全体を繰り返すため、サブスクライバでのレプリケートされたコミットの成功または失敗が認識された場合、またはタイムアウト時間に達した場合にコミット・コールが返されます。
トランザクションのロールバック: コールしてスタンバイまたはサブスクライバでのトランザクションの適用に関するエラー(主キー検索障害など)が返された場合は、アクティブまたはマスターでトランザクションをロールバックできます。
レプリケーション・スキームに含まれるレプリケート表の列の定義は、必ずしも同一である必要はありません。
TABLE DEFINITION CHECKING値がEXACTに設定されている場合、列の定義は、アクティブ・データベースとスタンバイ・データベースの間で同一である必要があります。この属性は、物理構造が同一の表のレプリケーションを可能にします。
TABLE DEFINITION CHECKING値がRELAXED (デフォルト)に設定されている場合、レプリケート表の列の定義は、同一である必要はありません。RELAXED属性を使用する場合、レプリケート表に同じキー定義、列数、列名および列のデータ型が必要です。
表定義チェックが、スタンバイ・データベースで発生します。アクティブ・データベースとスタンバイ・データベースの両方に対してこの属性をRELAXEDに設定しても、スタンバイ・データベースのみにこの属性値を設定した場合と同じ効果となります。
|
注意: TABLE DEFINITION CHECKINGの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE ACTIVE STANDBY PAIRに関する説明またはCREATE REPLICATIONに関する説明を参照してください。 |
TABLE DEFINITION CHECKING RELAXED属性では、両方のマスター・データベースで表の物理的構造が同じである必要はありません。たとえば、表の列の順序が異なっていたり、表のパーティション数が異なる場合は、データをレプリケートできるのは、RELAXED属性を使用した場合です。このため、列を追加または削除して表を変更する場合、RELAXED属性を使用する必要があります。『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER TABLE」に示すとおり、表の変更時に列を追加すると、追加のパーティションが作成されます。列を削除しても、自動的に領域が解放されることはありません。表を変更するDML文は、マスターで実行された後、スタンバイ・データベースおよびサブスクライバにレプリケートされるようにすることをお薦めします。
異なる物理構造を補っている場合、RELAXED設定によってパフォーマンスがわずかに低下する可能性があります。表の物理構造が同じ場合は、パフォーマンスへの影響はありません。ttMigrate -r -relaxedUpgrade (表定義チェックがRELAXEDに設定されたデータベースでのみ有効)を使用して、表のすべての追加パーティションを1つのパーティションに結合し、削除された列によって発生した余分な領域をなくすことによって、パフォーマンスの問題(異なる物理構造、追加のパーティションまたは余分な領域によるもの)は排除できます。レプリケーション・スキームに含まれるすべてのデータベースでこれを行うと、結果として物理構造が同じになるため、パフォーマンスを最大にすることができます。
|
注意: 各表で使用する場合のパーティションの確認方法については、例4-18および『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』の表のパーティション数の確認に関する説明を参照してください。
|
表定義チェックがRELAXEDに設定されていることを確認するには、アクティブ・データベースまたはマスター・データベースでレプリケーション・エージェントを停止した後、ALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文を実行して、表定義チェックをRELAXEDに設定します。最後に、ttRepAdmin -duplicateコマンドを使用して、これらの変更をスタンバイ・データベースとサブスクライバにロールアウトします。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のALTER ACTIVE STANDBY PAIR文に関する説明およびALTER REPLICATION文に関する説明を参照してください。
次の項では、表定義チェックをRELAXEDに設定する例を示します。
次の例は、アクティブ・スタンバイ・ペアのレプリケーション・スキームでTABLE DEFINITION CHECKING属性をEXACTまたはRELAXEDのいずれかに設定した場合の影響を示します。
例4-22 アクティブ・スタンバイ・ペアで同一の表のレプリケーション
master1データベースに表t1を作成します。
CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c INT);
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。master2スタンバイ・データベースに対して、TABLE DEFINITION CHECKINGをEXACTに設定します。
Command> CREATE ACTIVE STANDBY PAIR master1, master2
> STORE master2 TABLE DEFINITION CHECKING EXACT;
残りの手順を実行してアクティブ・データベースをスタンバイ・データベースに複製し、レプリケーション・エージェントを両方のデータベースで起動して、アクティブ・データベースの状態を設定します(第2章「スタート・ガイド」参照)。
master1のt1に行を1つ挿入します。
Command> INSERT INTO t1 VALUES (4,5,6); 1 row inserted.
master2のt1の結果を確認します。
Command> SELECT * FROM t1; < 4, 5, 6> 1 row found.
例4-23 アクティブ・スタンバイ・ペアで表定義チェックをRELAXEDに変更
アクティブ・スタンバイ・ペアのレプリケーション・スキームの表定義チェックをrelaxedに変更できます。まず、アクティブ・データベースを変更する前に、アクティブ・データベースのレプリケーション・エージェントを停止します。次のようにすると、dsn1アクティブ・データベースが変更されるため、表定義チェックはRELAXEDに設定されます。
ALTER ACTIVE STANDBY PAIR ALTER STORE master1 SET TABLE DEFINITION CHECKING RELAXED;
実行が完了すると、複製によってスタンバイ・データベースに変更がロールアウトされます。最後に、複製によってサブスクライバに変更がロールアウトされます。
次の例は、クラシック・レプリケーション・スキームでTABLE DEFINITION CHECKING属性をEXACTまたはRELAXEDのいずれかに設定した場合の影響を示します。
例4-24 クラシック・レプリケーション・スキームで同一の表のレプリケーション
dsn1データベースに表t1を作成します。
CREATE TABLE ttuser.t1 (a INT PRIMARY KEY, b INT, c INT);
ttuser.t1表をdsn2データベースに、dsn1データベースの表と完全に同じに作成します。
レプリケーション・スキームttuser.rep1を作成します。サブスクライバdsn2で、TABLE DEFINITION CHECKINGをEXACTに設定します。
CREATE REPLICATION ttuser.rep1
ELEMENT e1 TABLE ttuser.t1
MASTER dsn1
SUBSCRIBER dsn2
STORE dsn2 TABLE DEFINITION CHECKING EXACT;
両方のデータベースのレプリケーション・エージェントを起動します。dsn1のttuser.t1に行を1つ挿入します。
Command> INSERT INTO ttuser.t1 VALUES (4,5,6); 1 row inserted.
dsn2のttuser.t1の結果を確認します。
Command> SELECT * FROM ttuser.t1; < 4, 5, 6> 1 row found.
例4-25 クラシック・レプリケーション・スキームで異なる位置にある列を持つ表のレプリケーション
dsn1データベースに表t1を作成します。
CREATE TABLE ttuser.t1 (a INT PRIMARY KEY, b INT, c INT);
dsn1データベースのttuser.t1の列とは異なる順番の列を持つ表ttuser.t1をdsn2データベースに作成します。両方の表で列名およびデータ型が同じであり、両方の表でaが主キーであることに注意します。
CREATE TABLE ttuser.t1 (c INT, a INT PRIMARY KEY, b INT);
レプリケーション・スキームttuser.rep1を作成します。サブスクライバdsn2で、TABLE DEFINITION CHECKINGをRELAXEDに設定します。
CREATE REPLICATION ttuser.rep1
ELEMENT e1 TABLE ttuser.t1
MASTER dsn1
SUBSCRIBER dsn2
STORE dsn2 TABLE DEFINITION CHECKING RELAXED;
両方のデータベースのレプリケーション・エージェントを起動します。dsn1のttuser.t1に行を1つ挿入します。
Command> INSERT INTO ttuser.t1 VALUES (4,5,6); 1 row inserted.
dsn2のttuser.t1の結果を確認します。
Command> SELECT * FROM ttuser.t1; < 5, 6, 4 > 1 row found.
例4-26 クラシック・レプリケーション・スキームで異なるパーティション数を持つ表のレプリケーション
表を変更して列を追加すると、その後その新しい列を削除しても、表のパーティション数は増加します。TABLE DEFINITION CHECKINGをRELAXEDに設定すると、パーティションの数が異なる表をレプリケートできます。
dsn1に、列が2つある表ttuser.t3を作成します。
CREATE TABLE ttuser.t3 (a INT PRIMARY KEY, b INT);
dsn2に、列が1つあり、その列が主キーである表ttuser.t3を作成します。
CREATE TABLE ttuser.t3 (a INT PRIMARY KEY);
dsn2の表に列を追加します。これにより、パーティションの数は2つになりますが、dsn1の表のパーティションは1つです。
ALTER TABLE ttuser.t3 ADD COLUMN b INT;
両方のデータベースでレプリケーション・スキームを作成します。
CREATE REPLICATION reppart
ELEMENT e2 TABLE ttuser.t3
MASTER dsn1
SUBSCRIBER dsn2
STORE dsn2 TABLE DEFINITION CHECKING RELAXED;
両方のデータベースのレプリケーション・エージェントを起動します。dsn1のttuser.t3に行を1つ挿入します。
Command> INSERT INTO ttuser.t3 VALUES (1,2); 1 row inserted.
dsn2のttuser.t3の結果を確認します。
Command> SELECT * FROM ttuser.t3; < 1, 2 > 1 row found.
例4-27 クラシック・レプリケーション・スキームで表定義チェックをRELAXEDに変更
クラシック・レプリケーション・スキームの表定義チェックをRELAXEDに変更できます。まず、マスター・データベースのレプリケーション・スキームを変更する前に、マスター・データベースのレプリケーション・エージェントを停止します。次のようにすると、dsn1マスター・データベースが変更されるため、表定義チェックはRELAXEDに設定されます。
ALTER REPLICATION reppart ALTER STORE dsn1 SET TABLE DEFINITION CHECKING RELAXED;
実行が完了すると、複製によってスタンバイ・マスターに変更がロールアウトされます。最後に、複製によってサブスクライバに変更がロールアウトされます。
低帯域幅のネットワークを介してレプリケーションを行う場合、または大量のデータのレプリケーションを行う場合は、レプリケーションに必要な帯域幅の量を減らすCOMPRESS TRAFFIC属性を設定できます。COMPRESS TRAFFIC属性を使用すると、CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文のSTOREパラメータで指定されたデータベースからレプリケートされたデータが圧縮されます。TimesTenでは、他のデータベースからの通信量は圧縮されません。
圧縮アルゴリズムは速度に関しては最適化されますが、COMPRESS TRAFFIC属性を有効にすると、レプリケーションのスループットおよび待機時間に影響を与えます。
例4-28 アクティブ・スタンバイ・ペアのアクティブ・データベースからの通信量の圧縮
たとえば、アクティブ・データベースdsn1からのレプリケートの通信量は圧縮し、スタンバイ・データベースdsn2からのレプリケートの通信量は圧縮しない場合、CREATE ACTIVE STANDBY PAIR文は次のようになります。
CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2" SUBSCRIBER dsn3 ON "host3" STORE dsn1 ON "host1" COMPRESS TRAFFIC ON;
例4-29 アクティブ・データベースとスタンバイ・データベースの両方からの通信量の圧縮
dsn1およびdsn2のデータベースからのレプリケートの通信量を圧縮するには、次のように入力します。
CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2" SUBSCRIBER dsn3 ON "host3" STORE dsn1 ON "host1" COMPRESS TRAFFIC ON STORE dsn2 ON "host2" COMPRESS TRAFFIC ON;
例4-30 クラシック・レプリケーション・スキームで1つのデータベースからの通信量の圧縮
データベースdsn1からのレプリケートの通信量は圧縮し、dsn2からのレプリケートの通信量は圧縮しない場合、CREATE REPLICATION文は次のようになります。
CREATE REPLICATION repscheme
ELEMENT d1 DATASTORE
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT d2 DATASTORE
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 COMPRESS TRAFFIC ON;
例4-31 クラシック・レプリケーション・スキームで両方のデータベース間の通信量の圧縮
dsn1とdsn2のデータベース間でのレプリケートの通信量を圧縮するには、次のように入力します。
CREATE REPLICATION scheme
ELEMENT d1 DATASTORE
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT d2 DATASTORE
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 COMPRESS TRAFFIC ON
STORE dsn2 ON host2 COMPRESS TRAFFIC ON;
CREATE ACTIVE STANDBY PAIR文およびCREATE REPLICATION文のSTORE属性に対するPORTパラメータは、別のデータベースから更新をリスニングするためにデータベースにより使用されるポート番号を設定します。
アクティブ・スタンバイ・ペアでは、スタンバイ・データベースは、アクティブ・データベースからの更新をリスニングします。読取り専用サブスクライバは、スタンバイ・データベースからの更新をリスニングします。
クラシック・レプリケーション・スキームでは、サブスクライバは、マスター・データベースからの更新をリスニングします。1つのクラシック・レプリケーション・スキームにPORT属性を設定すると、すべてのクラシック・レプリケーション・スキームにその設定が適用されます。
静的ポートの割当てをお薦めします。PORT属性を設定しない場合、TimesTenデーモンが動的にポートを選択します。ポートがレプリケーション・エージェントに動的に割り当てられる場合は、TimesTenデーモンのポートも一致させる必要があります。
|
注意: オンラインによるアップグレードを行う場合は、静的ポートを割り当てる必要があります。 |
ポートを静的に割り当てる場合は、STORE属性に完全なホスト名、DSNおよびポートを指定する必要があります。
TIMEOUT STORE属性は、レプリケーション・エージェントがリモート・レプリケーション・エージェントからの応答を待機する最大秒数を設定します。
大規模なトランザクションがある場合は、デフォルトのタイムアウト(120秒)を使用することをお薦めします。レプリケーション・エージェントは、リモート・レプリケーション・エージェントからの応答の遅延の原因となる可能性のある大規模なトランザクションに対応するために、トランザクションのサイズに基づいてタイムアウトをスケーリングします。ユーザーがTIMEOUTを60秒以下に設定している場合、レプリケーション・エージェントによる自動スケーリングは無効になっています。
|
注意: 何度もタイムアウトが発生し、エラー・ログに多数のトランスミッタおよびレシーバ・スレッドの再開始が記録されていた場合は、レプリケーション・エージェントが現在のタイムアウト値でスケーリングできるよりもトランザクションが大きい可能性があります。トランザクションに対してレプリケーションを進行できるようになるまで、タイムアウト値を増やしてください。 |
次の例では、マスター・データベースがrep1およびrep2であるアクティブ・スタンバイ・ペアを作成します。サブスクライバrep3が1つあります。レプリケーションのタイプはRETURN RECEIPTです。また、この文では、PORTおよびTIMEOUT属性をマスター・データベースに対して設定します。アクティブ・マスターとスタンバイ・マスターの両方で、TIMEOUT属性は80秒に設定されます。
CREATE ACTIVE STANDBY PAIR rep1, rep2 RETURN RECEIPT SUBSCRIBER rep3 STORE rep1 PORT 21000 TIMEOUT 80 STORE rep2 PORT 22000 TIMEOUT 80;
しきい値を設定することができ、この値を超えると、次に示すように、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なデータベースがfailed状態に設定されます。
アクティブ・スタンバイ・ペアでは、トランザクション・ログのしきい値を超えると、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なスタンバイ・データベースまたは読取り専用サブスクライバがfailed状態に設定されます。CREATE ACTIVE STANDBY PAIR文またはALTER ACTIVE STANDBY PAIR文のSTORE句にFAILTHRESHOLD値を指定して、トランザクション・ログのしきい値を設定します。
アクティブ・データベースは、スタンバイ・データベースまたは読取り専用サブスクライバ・データベースをfailed状態に設定すると、障害が発生したデータベースのすべてのデータをトランザクション・ログから削除し、障害が発生したデータベースにメッセージを送信します。アクティブ・レプリケーション・エージェントが障害の発生したデータベースのレプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。
クラシック・レプリケーション・スキームでは、トランザクション・ログのしきい値を超えると、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なサブスクライバがfailed状態に設定されます。CREATE REPLICATION文またはALTER REPLICATION文のSTORE句にFAILTHRESHOLD値を指定して、トランザクション・ログのしきい値を設定します。例は、例9-5を参照してください。
マスター・データベースは、サブスクライバ・データベースをfailed状態に設定すると、障害が発生したサブスクライバのすべてのデータをトランザクション・ログから削除し、障害が発生したサブスクライバ・データベースにメッセージを送信します。マスター・レプリケーション・エージェントでサブスクライバ・レプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。
ただし、サブスクライバは、双方向レプリケーションの場合または他のサブスクライバに更新を伝播するように構成されている場合、マスターからメッセージを受信すると、レプリケーションの状態が損なわれたために、それ以上更新を送信しません。
デフォルトのしきい値は0(ゼロ)で、「制限なし」を意味します。トランザクション・ログ障害のしきい値の詳細は、「ロギングの接続属性の設定」を参照してください。
障害が発生したデータベースに接続中のアプリケーションは、データベースがレプリケーション・ピアによってfailedとマークされたことを示すtt_ErrReplicationInvalid(8025)警告を受信します。データベースにその障害状態が通知されると、アクティブ・データベースまたはマスター・データベースでのその状態はfailedからstopに変更されます。
アプリケーションでは、ODBCのSQLGetInfo関数を使用して、アプリケーションが接続しているデータベースがfailed状態に設定されているかどうかを確認できます(「サブスクライバの障害」を参照)。
クラシック・レプリケーションでは、CONFLICT REPORTING SUSPEND属性を使用して、1秒当たりのレプリケーション競合数を表レベルで指定できます。競合数がこの数に到達すると、競合レポート処理が一時停止されます。また、CONFLICT REPORTING RESUME属性を使用して、競合レポート処理が再開する1秒当たりのレプリケーション競合数を指定できます。完全な説明は、第13章「レプリケーション競合の解消」を参照してください。
次の各項ではネットワークを介してTimesTenデータをレプリケートする際に考慮すべきいくつかの問題について説明します。
TimesTenレプリケーションに必要なネットワーク帯域幅は、レプリケートしているデータの量および頻度によって異なります。ここでは、データ範囲の上位と下位、およびTimesTenデータベース間でデータをレプリケートするために必要なネットワーク帯域幅を特徴付けるトランザクションのタイプについて説明します。
表4-1は、レプリケート・レコードのサイズを計算するためのガイドラインを示しています。
表4-1 レプリケート・レコードのサイズ
| レコード・タイプ | サイズ |
|---|---|
|
開始トランザクション |
48バイト |
|
更新 |
116バイト ＋18バイト(更新された列ごとに) ＋古い列値のサイズ ＋新しい列値のサイズ ＋主キーまたは一意キーのサイズ |
|
削除 |
104バイト ＋主キーまたは一意キーのサイズ |
|
挿入 |
104バイト ＋主キーまたは一意キーのサイズ ＋挿入された行のサイズ |
トランザクションはレプリケート対象のデータベース間をバッチで送信されます。マスター・データベースのトランザクション・ログ・バッファにデータがなくなった場合、または現在のバッチがほぼ256KBである場合にバッチが作成されます。詳細は、「データベース間の更新のコピー」を参照してください。
TimesTenレプリケーションでは、TCP/IPプロトコルを使用していますが、このプロトコルはWAN環境用には最適化されていません。WANでのレプリケーションのパフォーマンスは、サードパーティのTCPスタック製品を使用して向上できます。TCPスタックの交換を実行できない場合は、CREATE ACTIVE STANDBY PAIR文またはCREATE REPLICATION文にCOMPRESS TRAFFIC属性を設定して、TCP/IPプロトコルで処理する必要があるネットワーク通信量を削減します。詳細は、「レプリケートの通信量の圧縮」を参照してください。
パフォーマンスを向上させるためにTCP/IPカーネル・パラメータを変更する方法の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のAIXの前提条件に関する説明またはLinuxの前提条件に関する説明で、AIXプラットフォームまたはLinuxプラットフォームについてのインストール情報を参照してください。
レプリケーション・スキームでは、データベースが存在するホストの名前を指定する必要があります。そのホスト名は、オペレーティング・システムによって1つ以上のIPアドレスに変換されます。
レプリケーション要素でデータベースのホストを指定する場合は、hostnameコマンドによって返される名前を常に使用する必要があります(レプリケーションでは、それと同じホスト名を使用して、現在のホストがレプリケーション・スキームに含まれていることを確認するためです)。現在のホストが含まれないレプリケーション・スキームは作成できません。
データベース名を指定するときに、オペレーティング・システムのhostnameコマンドが返すホスト名を指定する必要はありますが、ROUTE句を使用することで、別のインタフェース(デフォルト以外)でトラフィックを送受信するようにレプリケーションを構成できます。
ホストに(IPアドレスが異なる)複数のネットワーク・インタフェースがある場合は、レプリケーションでデフォルトのインタフェースを使用しないかぎり、使用するインタフェースをROUTE句で指定する必要があります。また、各インタフェースに対して優先順位を指定する必要もあります。レプリケーションでは、まず優先順位が最も高いアドレスを使用して接続が試行され、その接続を確立できなかった場合は、接続が確立されるまで優先順に残りのアドレスが試されます。あるIPアドレスを使用しているときにホストへの接続が失敗すると、ROUTE句で複数のアドレスが指定されている場合は、別のIPアドレスへの再接続(フォールバック)が試行されます。
ROUTE句の構文は次のようになります。
ROUTE MASTER FullDatabaseName SUBSCRIBER FullDatabaseName {{MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost} PRIORITY Priority} [...]
|
注意: ROUTE句のアドレスは、ホスト名またはIPアドレスのいずれかとして指定できます。ただし、あるホスト名に対して複数のIPアドレスが構成されているホストの場合は、意図したIPアドレスのみをレプリケーションで確実に使用するために、IPアドレスを使用してROUTE句を構成する必要があります。 |
アクティブ・スタンバイ・ペアでROUTE句を使用する場合、各マスター・データベースは他のマスター・データベースのサブスクライバであり、各読取り専用サブスクライバは両方のマスター・データベースのサブスクライバです。これは、両方のディレクトリに1つのルートを指定するには、CREATE ACTIVE STANDBY PAIR文に2の倍数でROUTE句が含まれている必要があることを意味します。
二重のマスターを定義するクラシック・レプリケーション・スキームでROUTE句を使用する場合、各マスター・データベースはもう1つのマスター・データベースのサブスクライバになります。これは、両方のディレクトリに1つのルートを指定するには、CREATE REPLICATION文に2の倍数でROUTE句が含まれている必要があることを意味します。
例4-34 アクティブ・スタンバイ・ペアに対する複数ネットワーク・インタフェースの構成
ホストhost1にはホスト名host1fastでアクセス可能な2つ目のインタフェースが構成されており、host2にはIPアドレス192.168.1.100でアクセス可能な2つ目のインタフェースが構成されている場合、次のようにすると、2つ目のインタフェースをレプリケーション・スキームで使用するように指定できます。
CREATE ACTIVE STANDBY PAIR dns1, dsn2
ROUTE MASTER dsn1 ON "host1" SUBSCRIBER dsn2 ON "host2"
MASTERIP "host1fast" PRIORITY 1
SUBSCRIBERIP "192.168.1.100" PRIORITY 1
ROUTE MASTER dsn2 ON "host2" SUBSCRIBER dsn1 ON "host1"
MASTERIP "192.168.1.100" PRIORITY 1
SUBSCRIBERIP "host1fast" PRIORITY 1;
例4-35 クラシック・レプリケーション・スキームに対する複数ネットワーク・インタフェースの構成
ホストhost1にはホスト名host1fastでアクセス可能な2つ目のインタフェースが構成されており、host2にはIPアドレス192.168.1.100でアクセス可能な2つ目のインタフェースが構成されている場合、次のようにすると、2つ目のインタフェースをレプリケーション・スキームで使用するように指定できます。
CREATE REPLICATION repscheme
ELEMENT e1 TABLE ttuser.tab
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT e2 TABLE ttuser.tab
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
ROUTE MASTER dsn1 ON host1 SUBSCRIBER dsn2 ON host2
MASTERIP host1fast PRIORITY 1
SUBSCRIBERIP "192.168.1.100" PRIORITY 1
ROUTE MASTER dsn2 ON host2 SUBSCRIBER dsn1 ON host1
MASTERIP "192.168.1.100" PRIORITY 1
SUBSCRIBERIP host1fast PRIORITY 1;
また、インタフェースが複数あるレプリケーション・ホストでは、プライマリ・インタフェースに障害が発生したり、そのインタフェースと受信ホストとの間の接続が切断した場合に備えて、1つ以上のインタフェースをバックアップとして使用するようにレプリケーションを構成できます。ROUTE句を使用すると、それぞれのマスターおよびサブスクライバに対して複数のインタフェースを指定し、優先順位に従ってレプリケーションで使用することができます。
マスター・ホストのレプリケーションが、優先順位の最も高いMASTERIPにバインドできなかった場合は、次の優先順位のMASTERIPアドレスを使用して接続が試行されます。ただし、サブスクライバへの接続がなんらかの理由で失敗した場合は、次に優先順位の高いMASTERIPアドレスを試す前に、それぞれのSUBSCRIBERIPアドレスを優先順に使用して接続が試行されます。
例4-36 アクティブ・スタンバイ・ペアに対するネットワーク優先順位の構成
ホストhost1に2つのネットワーク・インタフェース(IPアドレスは192.168.1.100と192.168.1.101)が構成され、ホストhost2に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 ACTIVE STANDBY PAIR dns1, dns2 ROUTE MASTER dsn1 ON "host1" SUBSCRIBER dsn2 ON "host2" 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;
例4-37 クラシック・レプリケーション・スキームに対するネットワーク優先順位の構成
ホストhost1に2つのネットワーク・インタフェース(IPアドレスは192.168.1.100と192.168.1.101)が構成され、ホストhost2に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 ttuser.tab MASTER dsn1 ON host1 SUBSCRIBER dsn2 ON host2 ROUTE MASTER dsn1 ON host1 SUBSCRIBER dsn2 ON host2 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;
次の各項では、ROUTE句を使用しない場合に、各ホストについて正しいホスト名とIPアドレスを使用するようにレプリケーションを構成する方法について説明します。
データベース・ホストと、レプリケーションに使用するネットワーク・インタフェースを指定するには、可能な場合は、レプリケーション・スキームのROUTE句を使用する必要があります。ただし、この項では、ROUTE句を使用しないレプリケーション・スキームがある場合に、複数のネットワーク・インタフェースを持つレプリケーション・ホストのオペレーティング・システムおよびDNSファイルを構成する方法について説明します。
ホストに(IPアドレスが異なる)複数のネットワーク・インタフェースがあり、レプリケーションがROUTE句で構成されていない場合、TimesTenレプリケーションでは、gethostbynameコールによって返される順序と同じ順序でIPアドレスへの接続が試行されます。最初のアドレスを使用して接続が試行され、その接続を確立できなかった場合は、接続が確立されるまで順番に残りのアドレスが試行されます。TimesTenレプリケーションでは、ホストへの新しい接続を確立するたびに、この同じ順序が使用されます。あるIPアドレスでホストへの接続が失敗すると、前述の方法と同じ方法でホストの別のIPアドレスへの再接続(フォールバック)が試行されます。
UNIXプラットフォームで複数のIPアドレスを使用するようにホストを構成する方法には、DNSまたは/etc/hostsファイルの2つの基本的な方法があります。
|
注意: ネットワーク・インタフェース・カード(NIC)が複数ある場合は、/etc/host.confファイルでmulti onを指定してください。指定しないと、gethostbynameは複数のアドレスを返すことができません。 |
たとえば、マシンに2つのNICがある場合は、/etc/hostsファイルに次の構文を使用します。
127.0.0.1 localhost IP_address_for_NIC_1 official_hostname optional_alias IP_address_for_NIC_2 official_hostname optional_alias
ホスト名official_hostnameは、hostnameコマンドによって返される名前です。
/etc/hostsファイルを編集する場合は、次のことに注意してください。
/etc/hostsファイルを変更するには、rootとしてログインする必要があります。
1つのIPアドレスにつき使用できるのは1行のみです。
各行には複数の別名を含めることができます。
同じホスト名に対して複数のIPアドレスがある場合、IPアドレスは連続した行に入力する必要があります。
ホスト名は最大30文字です。
たとえば、UNIXプラットフォームにある/etc/hostsファイルの次のエントリは、2つのIPアドレスがあるHost1というサーバーを示します。
127.0.0.1 localhost 10.10.98.102 Host1 192.168.1.102 Host1
DNSに同じ構成を指定する場合、ドメイン・ゾーン・ファイルに次のように入力します。
Host1 IN A 10.10.98.102
IN A 192.168.1.102
いずれの場合も、レプリケーション・スキームでホスト名としてHost1を指定するだけで、レプリケーションでは接続の確立時に最初の使用可能なIPアドレスが使用されます。
複数のIPアドレスが使用される環境では、レプリケーション接続を特定のIPアドレスに制限するために、1つのIPアドレスに複数のホスト名を割り当てることもできます。たとえば、/etc/hostsファイルに次のように入力できます。
127.0.0.1 localhost 10.10.98.102 Host1 192.168.1.102 Host1 RepHost1
または、DNSゾーン・ファイルに次のように入力できます。
Host1 IN A 10.10.98.102
IN A 192.168.1.102
RepHost1 IN A 192.168.1.102
レプリケーション接続をこのホストのIPアドレス192.168.1.102に制限する場合は、レプリケーション・スキームにホスト名としてRepHost1を指定できます。別の方法として、レプリケーション・スキームの構成に使用するCREATE ACTIVE STANDBY PAIR文またはCREATE REPLICATION文で、ホスト名として単にIPアドレスを指定する方法をあげることができます。
レプリケーション構成がIPアドレスではなくホスト名で指定されている場合、レプリケーションではピアのホスト名をIPアドレスに変換できる必要があります。Windowsでこれを効率的に行うには、ネットワーク上のホストに関する正確な情報を持つ有効なWINSサーバーまたは有効なDNSサーバーのいずれかを問い合せるようにWindowsマシンを設定する必要があります。このようなサーバーがない場合、次のいずれかの方法で静的なhost-to-IPエントリを入力できます。
%windir%\system32\drivers\etc\hosts
または、
%windir%\system32\drivers\etc\lmhosts
これらのオプションを指定しなかった場合、Windowsマシンはブロードキャスト(非常に低速)を実行してピア・ノードを検出します。
また、Windowsマシンで定義済のWINSサーバーまたはDNSサーバーと通信できない場合、またはホスト名の解決がこれらのサーバーで正しく設定されていない場合は、ホスト名の解決に非常に時間がかかる場合があります。pingコマンドを使用して、ホストを効率的に検出できるかどうかをテストします。pingコマンドのレスポンスは、ホスト名の解決が適切に設定されている場合はすぐに返されます。
|
注意: レプリケーション・スキームでのデータベース・ホストの指定は一貫している必要があります。あるデータベースにIPアドレスを使用してホストを指定した後、同じデータベースまたは別のデータベースにそのホスト名は使用しないでください。 |
デフォルトでは、TimesTenのメイン・デーモン、すべてのサブデーモン、およびすべてのエージェントは、使用可能な任意のアドレスを使用してソケット上でリクエストをリスニングします。ttendaemon.optionsファイルを変更して-listenaddrオプションを設定すると、エージェントとデーモン間の通信用アドレスを指定できます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモン・オプションの管理に関する説明を参照してください。
マシンに2つのNICがあり、NICのアドレスがそれぞれ10.10.10.100と10.10.11.200であるとします。ループバック・アドレスは127.0.0.1です。ループバック・アドレスをレプリケーション・エージェントに適用する場合は次のことに注意してください。
ttendaemon.optionsファイルに-listenaddrオプションを設定しない場合は、すべてのプロセスでデーモンおよびエージェントと対話できます。
-listenaddrを10.10.10.100に設定した場合、ローカル・ホストのすべてのプロセスまたは10.10.10ネットで、10.10.10.100のデーモンおよびエージェントと対話できます。10.10.11ネット上のプロセスでは、10.10.10.100のデーモンおよびエージェントと対話できません。
-listenaddrを127.0.0.1に設定した場合、ローカル・ホストのプロセスのみでデーモンおよびエージェントと対話できます。他のホストのプロセスでは、デーモンおよびエージェントと対話できません。
通常、TimesTenレプリケーションでは、レプリケーション構成に含まれるホストは、オペレーティング・システムの一般的なホスト名の解決方法で識別できます。ただし、ホスト名の構成が一般的でない場合、レプリケーション・スキームに指定されたホスト名とローカル・ホストが一致しているかどうかをTimesTenで判別できないことがまれにあります。このような状態でttRepStartまたはttAdmin -repStartを使用してレプリケーションを開始しようとすると、エラー8191「This store is not involved in a replication scheme」を受信することになります。この場合は、ttHostNameSet組込みプロシージャを使用して、現在のデータベースが、レプリケーション・スキームで指定されているデータベースであることをTimesTenに明示的に示すことができます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttHostNameSetに関する説明を参照してください。
