| Oracle® TimesTen In-Memory Databaseレプリケーション・ガイド リリース18.1 E98633-04 |
|
 前 |
 次 |
次の各項では、アクティブ・スタンバイ・ペアとクラシック・レプリケーション(マスターとサブスクライバが関与)の両方に対して構成可能なRETURNサービス・オプション、STORE属性、およびネットワーク操作について説明します。レプリケーション・スキーム間の相違については、各項で詳細に説明されます。
相互にレプリケーションを行うデータベースで、DatabaseCharacterSetデータ・ストア属性が同じである必要があります。TimesTen Classicでは、レプリケート・データベース間のキャラクタ・セット変換は実行されません。
データベース間でレプリケートを行う際は、レプリケートされる各列の基礎となるデータ型が各ノードで同じであることが必要です。
レプリケーション・ログ・ファイルの管理の推奨事項については、「レプリケート・データベースでのトランザクション・ログの管理」を参照してください。
パラレル・レプリケーションを構成する場合、ReplicationParallelismデータ・ストア属性およびReplicationApplyOrderingデータ・ストア属性の設定の詳細は、「パラレル・レプリケーションの構成」を参照してください。
この属性を2に設定したことによる効果を得るには、データベースが2つ以上のCPUを持つシステムでホストされている必要があります。
デフォルトでは、レプリケーションは、レプリケーション・スキーム内のノードにソース・データベース上の1つのログ・リーダー(トランスミッタ・スレッド)とターゲット・データベース上の1つの適用側スレッド(受信側スレッド)が含まれるシングル・スレッドで実行されます。ソース・データベースからターゲット・データベースに更新を送信し、その更新をターゲット・データベースで適用するための複数のスレッドを構成するパラレル・レプリケーションを構成することによって、パフォーマンスを向上させることができます。これらのスレッドは、レプリケーションと、レプリケーション・スキーム内のノードへのトランザクションの変更の適用を並行して行います。デフォルトでは、パラレル・レプリケーションは、トランザクションの依存性を強制し、コミット順に変更を適用しますが、コミット順の強制は無効化できます。
パラレル・レプリケーションのオプション:
自動パラレル・レプリケーション: トランザクションの依存性が自動的に強制され、すべての変更がコミット順に適用される、複数のスレッドにわたるパラレル・レプリケーション。これはデフォルトです。
コミット依存性を無効にした自動パラレル・レプリケーション: トランザクションの依存性を自動的に強制するが、サブスクライバ・データベース上でマスター・データベース上と同じ順序でコミットされるトランザクションは強制しない、複数スレッドでのパラレル・レプリケーション。
これらのオプションは、ReplicationApplyOrderingおよびReplicationParallelismのデータ・ストア作成属性で構成され、これはデータベースの作成時に設定する必要があります。
|
ノート: パラレル・レプリケーションを使用したレプリケーション・スキーム内のすべてのデータベースは、同じタイプのパラレル・レプリケーションおよび同じ数のスレッドまたはトラックを使用して同一に構成する必要があります。パラレル・レプリケーションの属性に異なる値を設定できるのは、アップグレード中のみです。 詳細は、Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのパラレル・レプリケーション使用時のアップグレードを参照してください。 |
次の項では、パラレル・レプリケーションのオプションについて説明します。
自動パラレル・レプリケーションを使用すると、レプリケーションと、クラシックまたはスタンバイ・ペアのレプリケーション・スキーム内のノードへのトランザクションの変更の適用を並行して行う複数のスレッドを構成できます。自動パラレル・レプリケーションでは、トランザクションの依存性が強制され、変更がコミット順に適用されます。
自動パラレル・レプリケーションを有効にするには、データベース作成時に、次のようにデータ・ストア属性を設定します。
ReplicationParallelismを2から32の数値に設定します。この数値は、LogBufParallelismの半分の値を超えることはできません。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。ただし、シングル・スレッド・レプリケーションを使用している場合、ReplicationParallelismを1 (デフォルト)に設定します。
レプリケーション・スキームがAWTキャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアである場合は、データ・ストア属性ReplicationApplyOrdering、ReplicationParallelismおよびCacheAWTParallelismの設定によって、TimesTenキャッシュ表の変更を対応するOracle Database表に適用するのに使用されるスレッド数が決定されます。詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Database表へのパラレル伝播の構成に関する説明を参照してください。
これらのデータ・ストア属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationParallelism、ReplicationApplyOrdering、およびLogBufParallelismを参照してください。
トランザクションの依存性を強制し、変更をコミット順に適用するために、自動パラレル・レプリケーションは通常、次のものを追跡します。
開始の依存性: 行を挿入してから同じ行を削除するなど、あるトランザクションを強制的に他のトランザクションより前に実行させる操作。
コミットの依存性: トランザクションをマスター・データベース上と同じ順序でサブスクライバ上でコミットするときの順序。
パラレル・レプリケーションでは、複数のスレッドを使用することによってパフォーマンスが向上しますが、トランザクションでコミットの依存性を強制する必要がない場合には、自動パラレル・レプリケーションを使用するとスループット・パフォーマンスがさらに向上します。つまり、アプリケーションでトランザクションの依存性が予測可能で、ターゲット・データベースでのコミット順序がソース・データベースでの順序と同じである必要がない場合には、コミットの依存性の強制をゆるめても、正しいトランザクションを維持できるということです。たとえば、別個のトランザクションを別個の表に対して実行する場合、コミットの依存性を強制する必要はありません。
コミットの依存性を追跡する必要性をゆるめると、自動パラレル・レプリケーションのパフォーマンスが向上します。コミットの依存性を強制しない場合、非DDLトランザクションがサブスクライバでコミットされる順序は、マスターで実行される元々の順序と異なることがあります。開始の依存性は、不正な順序が適用されないように、常に強制されます。
自動パラレル・レプリケーションのコミットの依存性を無効にできるのは、非同期レプリケーションを使用し、キャッシュ・グループを含まないアクティブなスタンバイ・ペアのみです。データベースの作成時には、次のデータ・ストア属性を設定できます。
TimesTenデータベースを作成する前に、ReplicationApplyOrdering=2を設定します。
ReplicationParallelismを2から32の数値に設定します。この数値は、LogBufParallelismの半分の値を超えることはできません。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。ただし、シングル・スレッド・レプリケーションを使用している場合、ReplicationParallelismを1 (デフォルト)に設定します。
ただし、パフォーマンスが向上する反面、このオプションでは一時領域に16MBの追加領域と、構成済の各レプリケーション・トラックに16MBの追加領域が必要になります(ReplicationParallelism接続属性の設定)。たとえば、ReplicationParallism接続属性を10に設定した場合、この機能には16MB + 160MB = 176MBの一時領域が追加で必要です。
自動パラレル・レプリケーションを使用し、コミット依存を無効化すると、一部の追跡は他の追跡より進んでいる可能性があります。これは、パラレル・レプリケーション・トラック間のドリフトとして知られています。レプリケーション・トラック間のドリフトの量は、ttDbConfig組込みプロシージャ内でParReplMaxDrift構成パラメータを設定して制限することができます。
Call ttDbConfig("ParReplMaxDrift", "30");
この例では、レプリケーション・トラック間で許容されるドリフトを30秒に設定しており、それを超えるとTimesTen Classicによりすべてのレプリケーション・トラックが互いに追い付くことになります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。
一般的に、マスターからサブスクライバに各トランザクションをレプリケートするときのスレッド(トラック)は自動パラレル・レプリケーションによって決まります。したがって、複数のトラック間における処理の分割方法を手動で決めることはできません。
ただし、依存トランザクションの場合は、手動で同じトラックにトランザクションを割り当ててパフォーマンスの向上を達成することができます。したがってアプリケーションには、ソース・データベースでトランザクションが開始されるとき、ReplicationTrack接続属性か、ALTER SESSION SET REPLICATION_TRACK文を使用して、トランザクションがどのトラックに属するかを指定するオプションがあります。その後、この接続のトランザクションはすべて、このトラックを使用します。このトラックのトランザクションは、ターゲット・データベースで受信された順に適用されますが、異なるトラック間のトランザクションではコミット順序は保持されません。トランザクションにトラックを指定する場合は、トラック間でワークロードが均等に分散するようにしてください。
受信側で順番に適用される必要のある更新は、同じトラックを使用する必要があります。1つの表に対する操作を、キー値に基づいて別個のトラック間に分散することができます。たとえば、通信費の請求処理アプリケーションがあるとすると、口座番号のハッシュを使用してトラックを設定し、各口座のすべてのトランザクションを別々のトラックで送信できます。
TimesTen Classicは引き続き依存性を計算して強制し、依存トランザクションが受信側で正しい順序で適用されるようにします。
アプリケーションは、次のいずれかの方法でトランザクションをトラックに割り当てます。
ReplicationTrack一般接続属性をゼロ以外の数値に設定します。接続によって発行されたすべてのトランザクションは、このトラックに割り当てられます。値は任意の数値です。TimesTenは、この接続のReplicationTrack数をパラレル・レプリケーションの使用可能なスレッドのいずれかにマップします。これにより、アプリケーションで任意の数を使用して、順番に適用する必要のあるトランザクションをグループ化できます。『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationTrackに関する説明を参照してください。
ALTER SESSION SQL文を使用して、現在の接続のレプリケーション・トラック数を設定します。『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER SESSION」を参照してください。
SQLSetConnectOption ODBC関数のTT_REPLICATION_TRACK ODBC接続オプションを使用します。『Oracle TimesTen In-Memory Database C開発者ガイド』のレプリケーションで使用するための機能に関する説明を参照してください。
TimesTenConnection JDBCクラスのsetReplicationTrack()メソッドを使用します。『Oracle TimesTen In-Memory Database Java開発者ガイド』のレプリケーションで使用するための機能に関する説明を参照してください。
ttConfiguration組込みプロシージャを使用すると、現在の接続のレプリケーション・トラック数が返されます。SYS.GV$LOG_HOLDSまたはSYS.V$LOG_HOLDSシステム・ビューから選択するか、ttLogHolds組込みプロシージャをコールして、複数のトラックが使用されていることを確認します。
この項の内容は次のとおりです。
専用のサブデーモン・スレッドはログ・バッファの内容を定期的にファイル・システムに書き込みます。これらの書込み操作は、同期化またはバッファリングできます。サブデーモン・スレッドは、ログ・バッファに同期化することなく、システムI/OバッファがLogFileSize初期接続属性の値を超えるトランザクション・ログ・データで一杯にならないようにします。
データベースがLogFlushMethod=2で構成されている場合、ファイル・システムに対する書込み操作はすべて同期書込み操作になり、書込みコールが返される前にデータがファイル・システムに永続的に書き込まれます。データベースがLogFlushMethod=1で構成されている場合には、アプリケーションから同期書込み操作の特定のリクエストがないかぎり、書込み操作はバッファリングされます。
定期的な書込み操作に加えて、アプリケーションはサブデーモン・スレッドをトリガーして、バッファの内容をファイル・システムに書き込むこともできます。次に、アプリケーションがファイル・システムへの同期書込み操作をトリガーする場合を示します。
永続コミットをリクエストしたトランザクションがコミットされた場合。ttDurableCommit組込みプロシージャをコールするか、DurableCommits接続属性を1に設定することによって、トランザクションは永続コミットをリクエストできます。
レプリケーション・エージェントがサブスクライバにトランザクションのバッチを送信する際に、マスターがレプリケーションに対してTRANSMIT DURABLE属性(デフォルト)で構成されている場合。
マスター・データベースがTRANSMIT DURABLEで構成されているかどうかに関係なく、レプリケーション・エージェントが定期的に永続コミットを実行する場合。
また、永続コミットが戻りサービス失敗ポリシーの一部として構成されており、障害が発生した場合にも、トランザクションは永続的にファイル・システムに書き込まれます。
前述の場合、ログ・バッファのサイズは、TimesTenによるファイル・システムへのデータの書込みに影響しません。
レプリケーション、トランザクション・ログAPI(XLA)、キャッシュ・グループまたは増分バックアップを使用しないデータベースでは、自動バックグラウンド・チェックポイント・スレッドあるいはアプリケーションのttCkptまたはttCkptBlocking組込みプロシージャのコールのいずれかによってチェックポイントが開始されるたびに、ログ・バッファ内の不要なレコードおよび不要なトランザクション・ログ・ファイルがパージされます。レプリケート・データベースでは、トランザクションがサブスクライバで完全に処理されたことをマスター・レプリケーション・エージェントが確認するまで、トランザクションはログ・バッファおよびトランザクション・ログ・ファイルに保持されます。マスターは、これを確認した時点でのみ、ログ・バッファおよびトランザクション・ログ・ファイルからのパージが必要であると認識します。
サブスクライバの状態が変わると、マスター・データベースのトランザクション・ログが、レプリケートされていないデータベースのログより大幅に大きくなる可能性があります。サブスクライバがstart状態の場合、マスターはサブスクライバからの情報の受信確認を受信した後、ログされているデータをパージできます。ただし、サブスクライバが使用不能またはpause状態になると、マスター・データベースのログはフラッシュできず、ログに使用する領域が使い果たされる可能性があります。ログ領域を使い果たすと、マスター・データベースでの後続の更新が強制終了されます。SYS.GV$LOG_HOLDSまたはSYS.V$LOG_HOLDSシステム・ビューから選択するか、ttLogHolds組込みプロシージャをコールして、レプリケーション・ログの保持に関する情報を取得します。
|
ノート: トランザクション・ログの増大の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの蓄積の監視に関する説明を参照してください。ログの保持の詳細は、本書の「レプリケーション・ログの保持からのレプリケーションの監視」、『Oracle TimesTen In-Memory Database SQLリファレンス』のSYS.GV$LOG_HOLDSまたはSYS.V$LOG_HOLDSに関する項、『Oracle TimesTen In-Memory Databaseリファレンス』のttLogHoldsに関する項を参照してください。 |
LogBufMBでは、インメモリー・ログ・バッファの最大サイズを指定します(MB単位)。このバッファは、一杯になると、トランザクション・ログ・ファイルにフラッシュされます。LogBufMBの最小サイズは、LogBufParallelismの値の8倍です。
トランザクション・ログ・ファイルのために十分な領域を確保する必要があります。ログで使用される領域の量を管理する場合、次の2つの設定があります。
DSNのLogFileSize設定では、トランザクション・ログ・ファイルの最大サイズを指定します。ロギング要件がこの値を超えると、同じ最大サイズを持つ追加のトランザクション・ログ・ファイルが作成されます。最適なパフォーマンスを実現するには、LogBufMBおよびLogFileSizeを最大値に設定します。
ログの障害しきい値の設定では、マスターがサブスクライバで障害が発生したと想定するまでに累積できるトランザクション・ログ・ファイルの最大数を指定します。このしきい値は、最後に書き込まれたトランザクション・ログ・ファイルと、サブスクライバ用に最初に保存されたトランザクション・ログ・ファイルの間のトランザクション・ログ・ファイルの数です。たとえば、すべてのサブスクライバが受信に成功した最後のレコードがログ・ファイル1にあり、ファイル・システムに書き込まれた最後のログ・レコードがログ・ファイル4の先頭にある場合は、2つ以上のトランザクション・ログ・ファイル(ログ・ファイル2および3の内容)がレプリケートされていません。しきい値が2の場合、マスターは、しきい値を超えたことを検出した後にサブスクライバをfailed状態に設定します。これには10秒かかる場合があります。詳細は、「トランザクション・ログ障害しきい値の設定」を参照してください。
トランザクションはファイル・システムに記録されるため、ブックマークを使用して、サブスクライバにレプリケートされた更新レコードおよびファイル・システムに書き込まれた更新レコードのログ・レコード識別子を検出できます。masterDSNに関連付けられているサブスクライバのブックマークの位置を表示するには、ttBookmark組込みプロシージャを使用します(「レプリケート・ログ・レコードの表示」を参照)。
サブスクライバが停止して、しきい値に達する前に再起動した場合、ブックマークの後に続くトランザクション・ログ・ファイル内のコミット済トランザクションが自動的に送信されるため、レプリケーションは自動的にキャッチアップします。ただし、しきい値を超えると、マスターはサブスクライバをfailed状態に設定します。障害が発生したサブスクライバは、ttRepAdmin -duplicateを使用してマスター・データベースをコピーし、処理を最初から再実行します(第14章「データベースのフェイルオーバーおよびリカバリの管理」を参照)。
TimesTenの接続属性、組込みプロシージャおよびユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。
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 Classicでは、アプリケーションをレプリケーション・メカニズムと疎結合または同期するためにオプションの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 Classicでは、アプリケーションをレプリケーション・メカニズムと完全に同期するために、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は無効である必要があります)。
RETURN TWOSAFE BY REQUESTトランザクションの一部であるレプリケートされた表を変更するためにALTER TABLE文を使用すると、結果的にTWOSAFE BY REQUESTトランザクションの一部としては実行されません。そのかわり、ALTER TABLE操作の前にコミットが実行されるため、ALTER TABLE操作は成功します。その結果、ALTER TABLE操作はRETURN TWOSAFE BY REQUESTトランザクションの一部ではない新しいトランザクションで実行されることになります。
タイムアウト時間内にスタンバイまたはサブスクライバでトランザクションのコミットを確認できない場合、アプリケーションは、コミット・リクエストに対する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を参照してください。
|
ノート: ALTER ACTIVE STANDBY PAIRを使用してSTORE属性のいずれかを変更する場合、「アクティブ・スタンバイ・ペアへのその他の変更」で説明されているステップに従う必要があります。 |
次の各項では、いくつかの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組込みプロシージャをコールします。詳細は、「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サービスを継続して有効にするか無効にするかが決定されます。
アクティブ・スタンバイ・ペアでは、次のいずれかの場合、レプリケーションは停止したとみなされます。
クラシック・レプリケーション・スキームでは、次のいずれかの場合、レプリケーションは停止したとみなされます。
|
ノート: スタンバイまたはサブスクライバ・データベースは、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サービス使用時のデフォルト設定です。
例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;
例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 -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値を設定すると、データベースは、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ミリ秒に設定すると、アクティブ・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の8ミリ秒未満でその更新の確認応答が受け取られた場合にかぎり、アクティブが更新の確認応答をスタンバイから受け取るとすぐに、RETURN RECEIPTブロッキングが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ミリ秒に設定すると、マスター・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の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属性を設定して、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秒当たりのレプリケーション競合数を指定できます。完全な説明は、第12章「レプリケーション競合の解消」を参照してください。
次の各項ではネットワークを介してTimesTenデータをレプリケートする際に考慮すべきいくつかの問題について説明します。
TimesTen Classicレプリケーションに必要なネットワーク帯域幅は、レプリケートしているデータの量および頻度によって異なります。ここでは、データ範囲の上位と下位、およびTimesTenデータベース間でデータをレプリケートするために必要なネットワーク帯域幅を特徴付けるトランザクションのタイプについて説明します。
表4-1は、レプリケート・レコードのサイズを計算するためのガイドラインを示しています。
表4-1 レプリケート・レコードのサイズ
| レコード・タイプ | サイズ |
|---|---|
|
開始トランザクション |
48バイト |
|
更新 |
116バイト ＋18バイト(更新された列ごとに) ＋古い列値のサイズ ＋新しい列値のサイズ ＋主キーまたは一意キーのサイズ |
|
削除 |
104バイト ＋主キーまたは一意キーのサイズ |
|
挿入 |
104バイト ＋主キーまたは一意キーのサイズ ＋挿入された行のサイズ |
トランザクションはレプリケート対象のデータベース間をバッチで送信されます。マスター・データベースのトランザクション・ログ・バッファにデータがなくなった場合、または現在のバッチがほぼ256KBである場合にバッチが作成されます。詳細は、「データベース間の更新のコピー」を参照してください。
TimesTen Classicレプリケーションでは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 dsn1, 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.200を使用してトラフィックの送受信を行い、その接続に障害が発生したときはIPアドレス192.168.1.101または192.168.1.201を試行するようにレプリケーションを設定できます。
CREATE ACTIVE STANDBY PAIR dsn1, dsn2 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.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 Classicレプリケーションでは、gethostbynameコールによって返される順序と同じ順序でIPアドレスへの接続が試行されます。最初のアドレスを使用して接続が試行され、その接続を確立できなかった場合は、接続が確立されるまで順番に残りのアドレスが試行されます。TimesTen Classicレプリケーションでは、ホストへの新しい接続を確立するたびに、この同じ順序が使用されます。あるIPアドレスでホストへの接続が失敗すると、TimesTen Classicレプリケーションでは前述の方法と同じ方法でホストの別のIPアドレスへの再接続(フォールバック)が試行されます。
UNIXまたはLinuxプラットフォームで複数のIPアドレスを使用するようにホストを構成するには、2つの基本的な方法があります: DNSまたは/etc/hostsファイルです。
|
ノート: ネットワーク・インタフェース・カード(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またはLinuxプラットフォームにある/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のメイン・デーモン、すべてのサブデーモン、およびすべてのエージェントは、使用可能な任意のアドレスを使用してソケット上でリクエストをリスニングします。timesten.confファイルを変更してlisten_addrオプションを設定すると、エージェントとデーモン間の通信用アドレスを指定できます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモン属性の管理に関する説明を参照してください。
マシンに2つのNICがあり、NICのアドレスがそれぞれ10.10.10.100と10.10.11.200であるとします。ループバック・アドレスは127.0.0.1です。ループバック・アドレスをレプリケーション・エージェントに適用する場合は次のことに注意してください。
timesten.confファイルのlisten_addrオプションを設定しなかった場合、すべてのプロセスがデーモンおよびエージェントと対話できます。
listen_addrを10.10.10.100に設定した場合、ローカル・ホストまたは10.10.10ネットのすべてのプロセスが10.10.10.100のデーモンおよびエージェントと対話できます。10.10.11ネット上のプロセスでは、10.10.10.100のデーモンおよびエージェントと対話できません。
listen_addrを127.0.0.1に設定した場合、ローカル・ホストのプロセスのみがデーモンおよびエージェントと対話できます。他のホストのプロセスでは、デーモンおよびエージェントと対話できません。
通常、TimesTen Classicレプリケーションでは、レプリケーション構成に含まれるホストは、オペレーティング・システムの一般的なホスト名の解決方法で識別できます。ただし、ホスト名の構成が一般的でない場合、レプリケーション・スキームに指定されたホスト名とローカル・ホストが一致しているかどうかをTimesTenで判別できないことがまれにあります。このような状態でttRepStartまたはttAdmin -repStartを使用してレプリケーションを開始しようとすると、エラー8191「This store is not involved in a replication scheme」を受信することになります。この場合は、ttHostNameSet組込みプロシージャを使用して、現在のデータベースが、レプリケーション・スキームで指定されているデータベースであることをTimesTenに明示的に示すことができます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttHostNameSetに関する説明を参照してください。
