ヘッダーをスキップ
Oracle TimesTen In-Memory Database推奨されたプログラミングの実行
リリース6.0
B25772-01
  目次へ
目次		 索引へ
索引
前へ
前へ 		次へ
次へ 		 

レプリケーションのトピック

この章では、TimesTenレプリケーションおよびXLAを使用するシステムを設計する際に、理解しておく必要があるいくつかの問題を中心に説明します。

レプリケーションの情報に関するその他のソースには、Oracle Technology Networkで入手可能なその他のドキュメントがあります。

ファイル名接頭辞としてのDSNの使用

これは必須ではありませんが、不要な混乱を回避します。

DSNは、データソース名です。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の「レッスン1: データソース名（DSN）の定義」を参照してください。

ファイル名の接頭辞は、次の項で定義します。

「ファイル名接頭辞」の定義

UNIXでは、myDSNと呼ばれるDSNは次のようになります。 

 [myDSN] 
 Driver=/opt/TimesTen/tt60/lib/libtten.so 
 Datastore=/directory/ds_file_prefix 
 

myDSNのファイル名接頭辞は、ds_file_prefixです。


 

Windowsでは、ODBCコントロール・パネルで同様に定義します。myDSNを次の場所に設定していた場合、「Data Store Path and Name」というラベルのフィールドに次のパスが表示されます。


C:\directory\ds_file_prefix 
 

myDSNのファイル名接頭辞は、ds_file_prefixです。

TimesTenのレプリケーション構成におけるファイル名接頭辞の使用

レプリケーションの構成コマンドは、データ・ストアのファイル名の接頭辞を参照しています。これは、次のSQLベースのレプリケーション構成コマンドで使用されます。 

CREATE REPLICATION rep.name ELEMENT e TABLE rep.t1 MASTER
<データ・ストアのファイル名接頭辞> ON <ホスト名> ... 
 

またttRepAdminコマンドライン・ユーティリティがデータ・ストアの名前を参照する際は、データストアのファイル名接頭辞が常に使用されます。


ttRepAdmin -duplicate -from <他のデータ・ストアのファイル名接頭辞
> -host <ホスト名> dsn=myDSN 
 

さらに、TimesTenレプリケーションでは、<file name prefix, hostname>のペアは一意である必要があります。したがって、2つのファイル名接頭辞が同じ場合、同一のコンピュータ上で2つのデータ・ストアのレプリケーションを設定できません。

結論: 常にDNSと同じファイル名接頭辞を設定する

次の理由から、常にDNS名と同じファイル名接頭辞をデータ・ストアに設定すると、非常に便利です。

複製操作の実行前に行う、2度のチェックポイントの実行

TimesTenでは、ttRepAdmin -duplicate操作を実行する前に、マスター・データ・ストアで明示的なチェックポイントを2回実行することをお薦めします。チェックポイントを強制実行するには、ttCkpt組込みプロシージャを使用します。

マスター・データ・ストアでチェックポイントを実行すると、不要なトランザクション・ログがパージされます。これによって、複製操作の一部として転送されるデータ量を削減でき、その結果、-duplicate操作が高速になります。

ポート番号を手動で指定する必要があるレプリケーション構成

TimesTen自体のバージョンをアップグレードする際に、TimesTenアプリケーションのアップグレードをオンラインで実行する場合、レプリケーションの構成コマンドおよびスクリプトに、レプリケーションのポート番号を手動で指定する必要があります。

ポート番号を手動で指定するのではなく、レプリケーションにポート番号を動的に割り当てる場合は、異なるバージョン間のTimesTenレプリケーションで正常に通信できないことがあります。

レプリケーションの監視

高可用性を保証するためには、TimesTenレプリケーションを監視することが重要です。アプリケーションでのレプリケーションの使用の監視が必要になる場合がいくつかあります。

レプリケーションおよびフェイルオーバーでのSEQUENCEの相互作用

SEQUENCEは各ノードで独立しており、レプリケートされません。db1では、1で始まり100000で終わる名前付きのシーケンスを定義し、db2では、100001で始まり200000で終わる名前付きのシーケンスを定義できます。したがって、たとえば、表の主キー列の移入には各ノードのシーケンスを使用できます。その結果、各ノードが他のノードと競合する危険性を考慮せずに、その表への挿入が可能になります。

リンク障害の後に、（たとえば、レプリケーションが追いつく、または保存したログ・ファイルの再実行によって）レプリケーションが通常どおりリカバリされると、特別な処理は必要ありません。ただし、障害の発生したノードが長時間停止した場合は、リカバリ処理にttRepAdmin -duplicateを使用して、存続するノードから障害の発生したノードにデータ・ストアを再移入します（トランザクションのキューが非常に長い場合は、この処理が必要です。）ttRepAdmin -duplicateコマンドによってシーケンス定義がノードから別のノードにコピーされ、この例では最終的に、両方のノードで100001から200000のシーケンス値が取得されます。これは、まさに回避しようとしたことです。

シーケンス番号の重複を避けるために、次のタスクをこの順序で完了してください。

  1. ttRepAdmin -duplicateを実行します。
  2. すべてのシーケンスを削除して再作成します。これによって、シーケンスの範囲が重複しなくなります。
  3. アプリケーションを再起動します。

    4. このような単純な方法により、SEQUENCEをレプリケートされた設定で使用して、キー値の一意性を保証することができます（ただし、キー値の密集度や一定の連続した増加は保証されていません）。

  前へ
前へ 		次へ
次へ
  目次へ
目次		 索引へ
索引