| Oracle® TimesTen In-Memory Database開発者および管理者ガイド 11gリリース2 (11.2.2) B66443-07 |
|
 前 |
 次 |
この章では、レプリケーションの設定方法および開始方法について説明します。
次の各項ではレプリケーション環境を設定する方法について説明します。
既存のデータベースの1つ以上の表をレプリケーションできます。レプリケートする必要があるデータベースが存在しない場合は、まず『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明に従って、そのデータベースを作成する必要があります。
マスター・データベースを指定または作成した後、ターゲット・ホストでサブスクライバ・データベースのDSN定義を作成します。マスターおよびサブスクライバのデータベースの接続属性を設定します(「レプリケート・データベースの接続属性」を参照)。
サブスクライバのDSNを設定した後、次の2つの方法のいずれかの方法で、マスターからレプリケートする表をサブスクライバ・データベースに移入できます。
データベースに接続し、SQL文を使用して、マスターからレプリケートする表と一致する新しい表をサブスクライバ・データベースに作成します。
ttRepAdmin -duplicateユーティリティを使用して、マスター・データベースの内容全体をサブスクライバにコピーします。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。
相互にレプリケーションを行うデータベースで、DatabaseCharacterSetデータ・ストア属性が同じである必要があります。TimesTenでは、レプリケート・データベース間のキャラクタ・セット変換は実行されません。
パラレル・レプリケーションを構成する場合、ReplicationParallelismデータ・ストア属性およびReplicationApplyOrderingデータ・ストア属性の設定の詳細は、「パラレル・レプリケーションの構成」を参照してください。
レプリケーション・ログ・ファイルを管理するための推奨事項については、「ロギングの接続属性の設定」を参照してください。
TypeModeデータ・ストア属性の設定が異なるデータベース間でもレプリケーションは実行できます。ただし、各レプリケーション列の基礎となるデータ型は各ノードで同じにする必要があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTypeModeに関する説明を参照してください。
アクティブ・スタンバイ・ペアで、アクティブ・データベースからスタンバイ・データベースへ変更を適用するスレッドの数を1から2に増やすには、ReceiverThreads初期接続属性を使用します。フェイルオーバーが発生した場合にスループットの向上を維持するためには、スタンバイ・データベースでReceiverThreadsを2に設定した場合、アクティブ・データベースでも2に設定する必要があります。
アクティブ・スタンバイ・ペアの1つ以上の読取り専用サブスクライバでReceiverThreadsを2に設定して、スタンバイ・データベースからのレプリケーション・スループットを向上させることもできます。
この属性を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秒に設定しており、それが過ぎるとすべてのレプリケーション・トラックが相互に追いつきます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。
一般的に、マスターからサブスクライバに各トランザクションをレプリケートするときのスレッド(トラック)は自動パラレル・レプリケーションによって決まります。したがって、複数のトラック間における処理の分割方法を手動で決めることはできません。
ただし、依存トランザクションの場合は、手動で同じトラックにトランザクションを割り当ててパフォーマンスの向上を達成することができます。したがってアプリケーションには、ソース・データベースでトランザクションが開始されるとき、ReplicationTrack接続属性か、ALTER SESSION SET REPLICATION_TRACK文を使用して、トランザクションがどのトラックに属するかを指定するオプションがあります。その後、この接続のトランザクションはすべて、このトラックを使用します。このトラックのトランザクションは、ターゲット・データベースで受信された順に適用されますが、異なるトラック間のトランザクションではコミット順序は保持されません。トランザクションにトラックを指定する場合は、トラック間でワークロードが均等に分散するようにしてください。
受信側で順番に適用される必要のある更新は、同じトラックを使用する必要があります。1つの表に対する操作を、キー値に基づいて別個のトラック間に分散することができます。たとえば、通信会社の請求処理アプリケーションがあるとすると、口座番号のハッシュを使用してトラックを設定し、各講座のすべてのトランザクションを異なるトラックで送ることができます。
TimesTenは引き続き依存性を計算して強制し、依存トランザクションが受信側でも正しい順序で適用されるようにします。
アプリケーションは、次のいずれかの方法でトランザクションをトラックに割り当てます。
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組込みプロシージャを使用すると、現在の接続のレプリケーション・トラック数が返されます。ttLogHolds組込みプロシージャを使用すると、複数のトラックが使用されているかどうかを確認できます。
アプリケーションにクラシック・レプリケーション・スキームがあり、予測可能なトランザクションの依存性が存在し、ターゲット・データベースとソース・データベースでコミット順序が同じである必要がない場合、ユーザー定義のパラレル・レプリケーションを使用することで、ユーザーが異なるトラック間の処理を手動で割り当てることができ、レプリケーション・スループットを向上できます。
ユーザー定義のパラレル・レプリケーションでは、ソース・データベースからターゲット・データベースに更新を送信し、その更新をターゲット・データベースで適用するための複数のスレッドを構成します。トランザクションは常に、アプリケーションによってトラックに割り当てられます。また、トランザクションが属するトラックは、ソース・データベースでトランザクションが開始されたときにアプリケーションによって指定されます。各トラックのトランザクションは、ターゲット・データベースで受信された順に適用されますが、異なるトラック間のトランザクションではコミット順序は保持されません。
|
注意: 外部キーで関連付けられている表に影響を与えるトランザクションをトラックに割り当てる場合は、注意する必要があります。関連付けられている表に対するトランザクションが別々のトラックに割り当てられた場合、トランザクションのコミット順序が変更され、いずれかのトランザクションが失われてしまう可能性があります。 |
通常、同じ表を変更するトランザクションは、同じレプリケーション・トラックに割り当てる必要があります。また、受信側で順番に適用される必要のある更新は、同じトラックを使用する必要があります。ただし、すべてのトランザクションが同じ表への挿入処理である場合、トランザクションを異なるトラックに割り当ててレプリケーション・スループットを向上できます。行を同じトラックに関連付けるキーを使用して、複数のトラック間で表のワークロードを分割できます。
ユーザー定義パラレル・レプリケーションは、クラシック・レプリケーション・スキームでのみ使用できます。
ユーザー定義のパラレル・レプリケーションを有効にするには、データベース作成時に、次のようにデータ・ストア属性を設定します。
ReplicationApplyOrderingを1に設定します。
ReplicationParallelismを1から64の数値に設定します。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。シングル・スレッド・レプリケーションでは、1 (デフォルト)に設定します。パラレル・レプリケーションを使用するためには、2から64の数値に設定します。
また、アプリケーションは「自動パラレル・レプリケーション環境でのレプリケーション・トラックの指定」で説明されているのと同じ方法で、トランザクションをトラックに割り当てる必要があります。唯一の違いは、ユーザー定義のパラレル・レプリケーション・スキームでは常に、接続のトランザクションに使用されるトラックが指定されることです。
エージング・ポリシーが定義されている表に対して、ユーザー定義のパラレル・レプリケーションを構成しないでください。
ユーザー定義のパラレル・レプリケーションが構成されているデータベースには、キャッシュ・グループを含めることはできません。
ユーザー定義のパラレル・レプリケーションを構成している場合、データベースをプロパゲータとして定義できません。
ユーザー定義のパラレル・レプリケーションをアクティブ・スタンバイ・ペアのレプリケーション・スキーム内で使用することはサポートされていません。
ユーザー定義のパラレル・レプリケーションは、同期レプリケーション(RETURN RECEIPT属性およびRETURN TWOSAFE属性が構成されたデータベースを含む)ではサポートされていません。
ユーザー定義のパラレル・レプリケーションが有効でないデータベースからユーザー定義のパラレル・レプリケーションが有効なデータベースへの、リリース間のレプリケーションおよび移行は、リリース11.2.1.6.0から11.2.1.8.0まではサポートされません。11.2.1.6.0より前と、11.2.1.8.0以降のリリースではサポートされています。11.2.1.6.0から11.2.1.8.0のユーザーは、まず11.2.1.8.0のインプレース・パッチ・リリース・アップグレードを適用してから、アップグレードを実行できます。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のパラレル・レプリケーション使用時のアップグレードに関する説明を参照してください。
この項の内容は次のとおりです。
専用のサブデーモン・スレッドはログ・バッファの内容を定期的にディスクに書き込みます。これらの書込みは同期化またはバッファリングできます。サブデーモン・スレッドは、ログ・バッファに同期化することなく、システムI/OバッファがLogFileSize初期接続属性の値を超えるトランザクション・ログ・データで一杯にならないようにします。
データベースがLogFlushMethod=2で構成されている場合は、ディスクへの書込みはすべて同期書込みで、書込みコールが返される前にデータはディスクに永続的に書き込まれます。データベースがLogFlushMethod=1で構成されている場合には、アプリケーションから同期書込みの特定のリクエストがないかぎり、書込みはバッファリングされます。
定期的な書込みに加えて、アプリケーションはサブデーモン・スレッドをトリガーして、バッファの内容をディスクに書き込むこともできます。次に、アプリケーションがディスクへの同期書込みをトリガーする場合を示します。
永続コミットをリクエストしたトランザクションがコミットされた場合。ttDurableCommit組込みプロシージャをコールするか、DurableCommits接続属性を1に設定することによって、トランザクションは永続コミットをリクエストできます。
レプリケーション・エージェントがサブスクライバにトランザクションのバッチを送信する際に、マスターがレプリケーションに対してTRANSMIT DURABLE属性(デフォルト)で構成されている場合。
マスター・データベースがTRANSMIT DURABLEで構成されているかどうかに関係なく、レプリケーション・エージェントが定期的に永続コミットを実行する場合。
また、永続コミットが戻りサービス失敗ポリシーの一部として構成されており、障害が発生した場合にも、トランザクションは永続的にディスクに書き込まれます。
前述の場合、ログ・バッファのサイズは、TimesTenによるディスクへのデータの書込みに影響しません。
レプリケーション、トランザクション・ログAPI(XLA)、キャッシュ・グループまたは増分バックアップを使用しないデータベースでは、自動バックグラウンド・チェックポイント・スレッドあるいはアプリケーションのttCkptまたはttCkptBlocking組込みプロシージャのコールのいずれかによってチェックポイントが開始されるたびに、ログ・バッファ内の不要なレコードおよび不要なトランザクション・ログ・ファイルがパージされます。レプリケート・データベースでは、トランザクションがサブスクライバで完全に処理されたことをマスター・レプリケーション・エージェントが確認するまで、トランザクションはログ・バッファおよびトランザクション・ログ・ファイルに保持されます。マスターは、これを確認した時点でのみ、ログ・バッファおよびトランザクション・ログ・ファイルからのパージが必要であると認識します。
サブスクライバの状態が変わると、マスター・データベースのトランザクション・ログが、レプリケートされていないデータベースのログより大幅に大きくなる可能性があります。サブスクライバがstart状態の場合、マスターはサブスクライバからの情報の受信確認を受信した後、ログされているデータをパージできます。ただし、サブスクライバが使用不能またはpause状態になると、マスター・データベースのログはフラッシュできず、ログに使用する領域が使い果たされる可能性があります。ログ領域を使い果たすと、マスター・データベースでの後続の更新が強制終了されます。ttLogHolds組込みプロシージャを使用して、レプリケーション・ログに関する情報を取得します。
|
注意: トランザクション・ログの増大の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの蓄積の監視に関する説明を参照してください。ttLogHolds組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttLogHolds組込みプロシージャによるレプリケーションの監視に関する説明またはttLogHoldsに関する説明を参照してください。 |
LogBufMBでは、インメモリー・ログ・バッファの最大サイズを指定します(MB単位)。このバッファは、一杯になると、ディスク上のトランザクション・ログ・ファイルにフラッシュされます。LogBufMBの最小サイズは、LogBufParallelismの値の8倍です。
トランザクション・ログ・ファイルのために十分なディスク領域を確保する必要があります。ログで使用されるディスク領域の量を管理する場合、次の2つの設定があります。
DSNのLogFileSize設定では、トランザクション・ログ・ファイルの最大サイズを指定します。ロギング要件がこの値を超えると、同じ最大サイズを持つ追加のトランザクション・ログ・ファイルが作成されます。最適なパフォーマンスを実現するには、LogBufMBおよびLogFileSizeを最大値に設定します。
ログの障害しきい値の設定では、マスターがサブスクライバで障害が発生したと想定するまでに累積できるトランザクション・ログ・ファイルの最大数を指定します。このしきい値は、最後に書き込まれたトランザクション・ログ・ファイルと、サブスクライバ用に最初に保存されたトランザクション・ログ・ファイルの間のトランザクション・ログ・ファイルの数です。たとえば、すべてのサブスクライバが受信に成功した最後のレコードがログ・ファイル1にあり、ディスクに書き込まれた最後のログ・レコードがログ・ファイル4の先頭にある場合は、2つ以上のトランザクション・ログ・ファイル(ログ・ファイル2および3の内容)がレプリケートされていません。しきい値が2の場合、マスターは、しきい値を超えたことを検出した後にサブスクライバをfailed状態に設定します。これには10秒かかる場合があります。詳細は、「トランザクション・ログ障害しきい値の設定」を参照してください。
トランザクションはディスクにロギングされるため、ブックマークを使用して、サブスクライバにレプリケートされた更新レコードおよびディスクに書き込まれた更新レコードのログ・レコード識別子を検出できます。masterDSNに関連付けられているサブスクライバのブックマークの位置を表示するには、ttBookmark組込みプロシージャを使用します(「レプリケート・ログ・レコードの表示」を参照)。
サブスクライバが停止して、しきい値に達する前に再起動した場合、ブックマークの後に続くトランザクション・ログ・ファイル内のコミット済トランザクションが自動的に送信されるため、レプリケーションは自動的にキャッチアップします。ただし、しきい値を超えると、マスターはサブスクライバをfailed状態に設定します。障害が発生したサブスクライバは、ttRepAdmin -duplicateを使用してマスター・データベースをコピーし、処理を最初から再実行します(第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照)。
TimesTenの接続属性、組込みプロシージャおよびユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。
サブスクライバ・データベースに内容を移入する最も簡単な方法は、マスター・データベースの内容を複製する方法です。また、障害が発生したデータベースのリカバリ時にも、この方法でデータベースを複製する必要があります(第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照)。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。
データベースを複製する場合は、次の条件を満たす必要があります。
インスタンス管理者が複製操作を実行します。
インスタンス管理者のユーザー名は、複製に含まれる両方のインスタンスで同じである必要があります。
ソース・データベースで、ADMIN権限があるユーザーのユーザー名とパスワードを入力する必要があります。
ターゲットDSNにクライアント属性およびサーバー属性を含めることはできません。
マスター・データベースの内容をサブスクライバ・データベースに複製するには、次のタスクを実行します。
レプリケーション・スキームを作成または変更して、新しいサブスクライバ・データベースおよびそのホストを指定します。「クラシック・レプリケーション・スキームの定義」または「サブスクライバ・データベースの作成とクラシック・レプリケーション・スキームへの追加」を参照してください。
レプリケーション・スキームをマスター・データベースに適用します。「データベースへのクラシック・レプリケーション・スキームの適用」を参照してください。
マスター・データベースのレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
ソース(マスター)・データベースで、次のように入力してユーザーを作成し、そのユーザーにADMIN権限を付与します。
CREATE USER ttuser IDENTIFIED BY ttuser; User created. GRANT admin TO ttuser;
インスタンス管理者のユーザー名がtimestenであるとします。ターゲット・ホスト(サブスクライバ)でtimestenとしてログインし、次のようにhost1のデータベースmasterDSNをsubscriber1DSNに複製します。
ttRepAdmin -duplicate -from masterDSN -host host1 subscriber1DSN Enter internal UID at the remote datastore with ADMIN privileges: ttuser Enter password of the internal Uid at the remote datastore:
リモート・データベースの内部ユーザーのパスワードを入力するよう要求されたら、ttuserと入力します。
|
注意: ホスト・エントリは、リモート・ホストの名前またはTCP/IPアドレスのいずれかで指定できます。TCP/IPアドレスを使用してホストを指定する場合は、-localhostオプションを使用してローカル・ホスト(この例ではhost1)のアドレスを指定する必要があります。
ソース・ホストとターゲット・ホストのローカルおよびリモートのネットワーク・インタフェースを指定するには、 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepAdminに関する説明を参照してください。 |
サブスクライバ・データベースでレプリケーション・エージェントを起動します。
レプリケーション・スキームには最大128のサブスクライバを含めることができます。プロパゲータ・データベースを使用するレプリケーション・スキームには最大128のプロパゲータを含めることができ、各プロパゲータには最大128のサブスクライバを構成できます。アクティブ・スタンバイ・ペアのレプリケーション・スキームには、最大127の読取り専用サブスクライバを含めることができます。多数のサブスクライバが含まれるレプリケーション・スキームを計画する場合は、次のことを実行する必要があります。
ログ・バッファのサイズは、SYS.MONITOR表のLOG_FS_READSの値が0(ゼロ)または0(ゼロ)に近い値になるようにすること。これによって、レプリケーション・エージェントでディスクからログ・レコードを読み取る必要がなくなります。LOG_FS_READSの値が増大する場合は、ログ・バッファのサイズを大きくします。
CPUリソースが十分にあること。マスター・データベースのレプリケーション・エージェントは、各サブスクライバ・データベースに対してスレッドを生成します。各スレッドでログの読取りおよび処理が個別に行われるため、サブスクライバ・データベースに送信するには適切なCPUリソースが必要です。
異なるリリース間でのレプリケーションは、新しいバージョンのTimesTenのデータベースが古いバージョンのTimesTenのデータベースからttMigrateを使用してアップグレードされた場合にのみ機能します。最新のバージョンのTimesTenで作成したデータベースでは、それより古いバージョンでの正常なレプリケートは保証されていません。
たとえば、TimesTenリリース6.0で作成されたデータベースとTimesTenリリース11.2.1で作成されたデータベース間のレプリケーションはサポートされていません。ただし、一方のデータベースがTimesTenリリース6.0で作成され、そのピア・データベースがTimesTenリリース6.0で作成された後でTimesTenリリース11.2.1にアップグレードされた場合、これらの間のレプリケーションはサポートされます。
『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の「TimesTenのアップグレード」を参照してください。
レプリケーション・スキームを定義した後、レプリケーション・スキームに含まれている各データベースのレプリケーション・エージェントを起動できます。レプリケーション・エージェントを起動および停止するには、ADMIN権限が必要です。
レプリケーション・エージェントは、ttAdminユーティリティに-repStartまたは-repStopオプションを指定して、起動および停止できます。また、ttRepStartおよびttRepStop組込みプロシージャを使用して、ttIsqlコマンドラインからレプリケーション・エージェントを起動および停止することもできます。
例11-1 ttAdminによるレプリケーション・エージェントの起動および停止
masterDSNおよびsubscriberDSNというDSNのレプリケーション・エージェントを起動するには、次のように入力します。
ttAdmin -repStart masterDSN ttAdmin -repStart subscriberDSN
レプリケーション・エージェントを停止するには、次のように入力します。
ttAdmin -repStop masterDSN ttAdmin -repStop subscriberDSN
例11-2 ttIsqlからのレプリケーション・エージェントの起動および停止
masterDSNというDSNのレプリケーション・エージェントを起動および停止するには、次のように入力します。
> ttIsql masterDSN Command> call ttRepStart; Command> call ttRepStop;
また、ttAdminユーティリティを使用してレプリケーション再起動ポリシーを設定することもできます。デフォルトでは、このポリシーはmanualで、これによって、前述のようにレプリケーション・エージェントを起動および停止できます。データベースのレプリケーション再起動ポリシーは、alwaysまたはnorestartに設定することもできます。
| 再起動ポリシー | TimesTenデーモンの起動時にレプリケーション・エージェントを起動 | エラー発生時または無効化が行われた場合にレプリケーション・エージェントを再起動 |
|---|---|---|
always |
する | する |
manual |
しない | する |
norestart |
しない | しない |
|
注意: レプリケーション・エージェントはTimesTenデーモンによって管理されます。レプリケーション・エージェントを起動または停止するには、これが実行されている必要があります。 |
再起動ポリシーがalwaysの場合、データベースがメモリーにロードされるとレプリケーション・エージェントが自動的に起動されます。データベースがメモリーにロードされるタイミングを指定する方法については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。
例11-3 ttAdminを使用した再起動ポリシーの設定
ttAdminを使用して、レプリケーション再起動ポリシーをalwaysに設定するには、次のように入力します。
ttAdmin -repPolicy always DSN
ポリシーをmanualに再設定するには、次のように入力します。
ttAdmin -repPolicy manual DSN
データベースの無効化の後、manualおよびalwaysの両方のポリシーによってレプリケーション・エージェントが自動的に再起動されます。レプリケーション・エージェントが自動的に再起動されると、多くの場合、データベースへの初期接続になります。たとえば、これは、すべてのアプリケーションの接続を切断する必要がある致命的なエラーが発生した後に行われます。通常、データベースへの初期接続では、最新のチェックポイント・ファイルをロードする必要があり、また、多くの場合リカバリを実行する必要があります。非常に大容量のデータベースの場合、このプロセスに数分かかる場合があります。この間、新しい接続が行われず、古い接続の切断が終了されないように、データベースでのすべてのアクティビティがブロックされます。また、この結果、すべてのアプリケーションの接続が切断されるまで古いデータベースが存続するため、データベースの2つのコピーが同時に存在する場合もあります。初期接続時が重要な非常に大容量のデータベースの場合、新しいデータベースを起動する前にまず古いデータベースが非アクティブになるまで待機する必要がある場合があります。これは、再起動ポリシーnorestartに設定してレプリケーション・エージェントが自動的に再起動されないように指定することで実現できます。データベースがメモリーにロードされるタイミングを判断するために、データベースがリロードされないようにする設定ポリシーについて、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。
サブスクライバ・レプリケーション・エージェントの状態は、そのマスター・データベースによって記述されます。障害が発生したサブスクライバ・データベースをリカバリする場合は、レプリケーション・スキームで通信するマスター・データベースに対するサブスクライバ・データベースのレプリケーション状態を再設定する必要があります。サブスクライバ・データベースの状態は、コマンドラインまたはプログラムから再設定できます。
コマンドラインから、ttRepAdmin -stateを使用して、いずれかのサブスクライバ・データベースのレプリケーション状態を再設定するようにマスター・データベースに指示します。
ttIsqlから、ttRepSubscriberStateSet組込みプロシージャをコールして、いずれかまたはすべてのサブスクライバ・データベースのレプリケーション状態を再設定するようにマスター・データベースに指示します。
データベースの状態の問合せについては、第12章「レプリケーションの監視」を参照してください。
マスター・データベースは、サブスクライバ・データベースをstart、pauseまたはstopのいずれかの状態に設定できます。データベースの状態は、表11-1に示すとおり、TTREP.REPPEERS表のSTATE列に整数値として示されます。
表11-1 データベースの状態
| 状態 | 説明 |
|---|---|
|
|
レプリケーション更新が収集され、できるかぎり早くサブスクライバ・データベースに送信されます。サブスクライバ・データベースのレプリケーションが動作していない場合、更新は、送信可能になるまでトランザクション・ログ・ファイルに保存されます。 |
|
|
レプリケーション更新は、送信を試行されずにログに保存されます。状態が |
|
|
レプリケーション更新は、サブスクライバ・データベースに送信されずに破棄されます。サブスクライバ・データベースを 警告: このサブスクライバの再起動を計画している場合、停止と再起動の間、更新は格納されません。このため、サブスクライバを再起動すると、サブスクライバには、マスターからの更新はすべて含まれません。再起動を計画している場合、サブスクライバを停止するかわりに、一時停止します。 |
|
|
しきい値(ログ・データ)を超えているため、サブスクライバへのレプリケーションは失敗したとみなされます。この状態は、システムによって設定され、システムが状態を |
マスター・データベースがそのサブスクライバの1つをstart状態に設定すると、そのサブスクライバに対する更新がマスターのログに保存されます。サブスクライバがstop状態の場合、サブスクライバに対する更新は破棄されます。
サブスクライバがpause状態の場合、サブスクライバに対する更新はマスターのログに保存されますが、サブスクライバ・データベースには送信されません。マスターがサブスクライバをpauseからstartに変更すると、マスターのログに保存された更新のバックログがサブスクライバに送信されます。(これには例外があります。第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照してください。)マスター・データベースは、状態が示されたサブスクライバに接続を確立できない場合、成功するまで接続の確立を定期的に試行します。
例11-4 ttRepAdminを使用したサブスクライバの状態の設定
コマンドラインからttRepAdminを使用して、subscriberdsサブスクライバ・データベースの状態をstopに設定するようにmasterdsマスター・データベースに指示するには、次のように入力します。
ttRepAdmin -dsn masterds -receiver -name subscriberds -state stop
|
注意: 異なるホストに同じ名前のサブスクライバが複数ある場合は、ttRepAdminユーティリティの-hostオプションで変更対象のサブスクライバのホストを識別します。 |
例11-5 ttRepSubscriberStateSetを使用したサブスクライバの状態の設定
マスター・データベースで、ttRepSubscriberStateSet組込みプロシージャをコールして、repschemeレプリケーション・スキームのサブスクライバ・データベース(subscriberds ON system1)の状態をstopに設定します。
Command> CALL ttRepSubscriberStateSet('repscheme', 'repl',
'subscriberds', 'system1', 2);
マスターのすべてのサブスクライバを特定の状態に設定する場合は、ttRepSubscriberStateSetのみを使用できます。ttRepAdminユーティリティに同等の機能はありません。
