| Oracle® TimesTen In-Memory Database開発者および管理者ガイド 11gリリース2 (11.2.2) B66443-07 |
|
 前 |
 次 |
この章では、クラシック・レプリケーション・スキームを構成する方法について説明します。
|
注意: アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義の詳細は、第3章「アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義」を参照してください。キャッシュ・グループがあるデータベースをレプリケートする場合は、第6章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。 |
この章の内容は次のとおりです。
|
注意: レプリケーションに必要な帯域幅の量を減らす方法については、「レプリケートの通信量の圧縮」を参照してください。列が異なる位置にある表やパーティションの数が異なる表をレプリケートする方法については、「レプリケート表の列定義オプション」を参照してください。 |
すべてのレプリケーション・スキームの主要な目的は、次のとおりです。
データをアプリケーションで常に使用できるように1つ以上のバックアップ・データベースを提供すること
障害が発生したデータベースをそれらのバックアップ・データベースからリカバリするための方法を提供すること
可能なかぎり最速でデータにアクセスできるアプリケーションを提供するために、ワークロードを効率的に分散すること
ユーザーへのサービスを中断せずに、ソフトウェアのアップグレードおよびメンテナンスを実行できるようにすること
高可用性システムでは、マスター・データベースに影響を与える可能性がある障害が発生しても、サブスクライバ・データベースは影響を受けないようにする必要があります。少なくとも、マスターとサブスクライバは別々のホストに配置する必要があります。一部のアプリケーションでは、個別の電源を供給できる環境にサブスクライバを配置する必要がある場合もあります。場合によっては、完全に別のサイトにサブスクライバを配置する必要もあります。
次のクラシック・レプリケーション・スキームを構成できます(「レプリケーション・スキームのタイプ」を参照)。
単方向
双方向の分割ワークロード
双方向の分散ワークロード
伝播
データベース全体をレプリケートするか、データベースの要素を選択してレプリケートするかについても検討してください。また、レプリケーション・スキームにおけるサブスクライバの数についても検討してください。単方向および伝播レプリケーション・スキームでは、サブスクライバの数を選択できます。
この項の後半では、次の内容について説明します。
クラシック・レプリケーションを使用したオンラインによるアップグレードの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のレプリケーションを使用したオンラインによるアップグレードの実行に関する説明を参照してください。
レプリケーション・スキームを計画する場合は、すべてのフェイルオーバーおよびリカバリの使用例を検討してください。たとえば、通常、サブスクライバで発生した障害は、マスター・データベースに接続しているアプリケーションには影響ありません。そのため、ユーザー・サービスを中断せずにリカバリできます。マスター・データベースで障害が発生した場合は、アプリケーションのロードをサブスクライバにリダイレクトし、中断なしに、または最小限の中断でサービスを続行するための方法が必要です。通常、この処理は、障害を検出し、障害が発生したデータベースからそのサブスクライバの1つにユーザーまたはアプリケーションをリダイレクトして、障害が発生したデータベースのリカバリを管理するように設計されている、クラスタ・マネージャまたはカスタム・ソフトウェアによって行われます。第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照してください。
フェイルオーバー方法を計画する場合は、マスターの役割を引き受けるサブスクライバおよび対象ユーザーまたはアプリケーションについて検討してください。リカバリの要件についても検討してください。たとえば、障害が発生したマスターがそのデータベースを最新のサブスクライバからリカバリできる必要があること、すべてのサブスクライバをそのマスターからリカバリできる必要があること、などです。データベース全体をレプリケートする双方向スキームでは、障害が発生したマスターの自動リストアを利用できます。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。
図9-1に示す、単方向にレプリケートされるデータベースの障害例について考えてみます。マスターで障害が発生した場合、アプリケーションは、サブスクライバからリカバリされるまでデータベースにアクセスできません。ALTER REPLICATION文を使用してサブスクライバ・データベースをマスターとして再定義しないかぎり、アプリケーションの接続またはユーザー・ロードをサブスクライバに切り替えることはできません。「クラシック・レプリケーション・スキームでのマスター・データベースの交換」を参照してください。
図9-2に、データベース全体がレプリケートされる双方向の分散ワークロード・スキームを示します。このタイプのレプリケーション・スキームでフェイルオーバーが発生した場合、障害が発生したデータベース上のアプリケーションを使用していたユーザーは、影響を受けなかったデータベース上のアプリケーションに移動されます。リカバリが完了すると、リカバリしたデータベース上のアプリケーションにワークロードを再分散できます。
同様に、分割ワークロード・スキームのユーザーは、障害が発生したデータベースから影響を受けなかったデータベースに移動する必要があります。分割ワークロード・スキームではデータベース・レベルでレプリケーションが行われないため、ALTER REPLICATION文を使用して新しいマスター・データベースを設定する必要があります。「クラシック・レプリケーション・スキームでのマスター・データベースの交換」を参照してください。リカバリが完了すると、リカバリしたマスター・データベースにユーザーを戻すことができます。
伝播レプリケーション・スキームでも、マスターまたはプロパゲータで障害が発生した場合は、ALTER REPLICATION文を使用して新しいマスターまたは新しいプロパゲータを設定する必要があります。レプリケーション・スキームで2つのプロパゲータが定義されていると、高可用性が実現されます。2つのプロパゲータが構成された伝播レプリケーション・スキームの例は、図1-11を参照してください。
レプリケーション・スキームの設計時に、フェイルオーバーおよびリカバリの複雑さとパフォーマンスの効率を比較してください。フェイルオーバーおよびリカバリを複雑にする要因には、マスターをそのサブスクライバと接続するネットワーク・トポロジ、レプリケーション・スキームの複雑さなどがあります。たとえば、選択した要素が異なるサブスクライバにレプリケートされるマスターをリカバリするより、1つのサブスクライバに完全にレプリケートされるマスターをリカバリする方がより簡単です。
レプリケーションは、非同期(デフォルト)、RETURN RECEIPTサービスによる半同期、またはRETURN TWOSAFEサービスによる完全同期で動作するように構成できます。データがマスターおよびサブスクライバの両方のデータベースで一貫していることをより高いレベルの信頼性を持って保証するには、RETURNサービスを選択します。非同期モード(デフォルト)を使用するか、RETURN RECEIPTモードまたはRETURN TWOSAFEモードを構成するかは、必要とする信頼性の程度および許容できるパフォーマンスのトレードオフによって決まります。
表9-1に、非同期のレプリケーション、RETURN RECEIPTサービスおよびRETURN TWOSAFEサービスにおけるパフォーマンスおよびリカバリのトレードオフの概要を示します。
表9-1 パフォーマンスとリカバリのトレードオフ
| 動作のタイプ | 非同期のレプリケーション(デフォルト) | RETURN RECEIPT | RETURN TWOSAFE |
|---|---|---|---|
|
コミット順序 |
各トランザクションは最初にマスター・データベースでコミットされます。 |
各トランザクションは最初にマスター・データベースでコミットされます。 |
各トランザクションは最初にサブスクライバ・データベースでコミットされます。 |
|
マスターでのパフォーマンス |
トランザクション間の待機時間またはマスターでコミットされるまでの待機時間がないため、レスポンス時間が最も短く、スループットも最適になります。 |
非同期と比較すると、レスポンス時間は長くなり、スループットは低くなります。 コミット後のネットワークのラウンドトリップ中にアプリケーションはブロックされます。レプリケート対象のトランザクションがシリアライズされる程度は、非同期レプリケーションでの場合より大きいため、結果としてスループットが低くなります。 |
レスポンス時間が最も長く、スループットも最も低くなります。 マスターでのコミットに先立って行われるネットワークのラウンドトリップおよびサブスクライバでのリモート・コミットの期間中に、アプリケーションがブロックされます。トランザクションは完全にシリアライズされ、結果としてスループットが最も低くなります。 |
|
実行時エラーの影響 |
トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。 |
トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。 |
トランザクションは最初にサブスクライバ・データベースでコミットされるため、マスターでのコミット時にエラーが発生した場合は、マスターを手動で修正するか、または破棄してからサブスクライバ・データベースからリカバリする必要があります。 |
|
マスターでの障害発生後のフェイルオーバー |
マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。 |
マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。 |
マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバは少なくともマスターの最新の状態になります。また、サブスクライバにレプリケートされたトランザクションをマスターでコミットする前にマスターで障害が発生した場合は、サブスクライバをマスターより先行させることもできます。 |
2つのRETURNサービス間のパフォーマンスとリカバリのトレードオフに加えて、次のことも検討する必要があります。
RETURN RECEIPTは多くの構成で使用できますが、RETURN TWOSAFEは双方向構成またはアクティブ・スタンバイ・ペアでのみ使用できます。
RETURN TWOSAFEでは、サブスクライバ・データベースへのトランザクションのレプリケート時にタイムアウトなどのエラーが発生した場合にマスター・データベースで実行されるローカル・アクションを指定できます。
アプリケーションでRETURN RECEIPTまたはRETURN TWOSAFEのいずれかに構成された表を更新する場合、トランザクションはRETURN RECEIPTまたはRETURN TWOSAFEとして分類されます。RETURN RECEIPTまたはRETURN TWOSAFEとして分類されたトランザクションは、終了前にレプリケーション・スキームが変更された場合でも、そのままの状態が維持されます。
RETURNサービスの詳細は、「クラシック・レプリケーション・スキームでのRETURNサービスの使用」を参照してください。
アプリケーションのワークロードを分散し、限られた数のサーバーを最大限利用できるようにデータベースを構成することを検討してください。たとえば、各サーバーが個別にマスター・データベースおよびサブスクライバ・データベースとして機能するのではなく、マスターおよびサブスクライバの両方として機能するように双方向の分散ワークロード・レプリケーション・スキームでデータベースを構成する方が、より効率的で経済的です。ただし、分散ワークロード・スキームは、主にデータベースから読取りを行うアプリケーションで最も効率的に機能します。データベースの同じ要素に頻繁に書込みを行うアプリケーションに対して分散ワークロード・スキームを実装すると、パフォーマンスが低下し、更新競合を回避または管理するための解決方法を実装する必要がある可能性があります(第13章「レプリケーション競合の解消」を参照)。
クラシック・レプリケーション・スキームを設計した後、SQL文CREATE REPLICATIONを使用してそのスキームをデータベースに適用できます。CREATE REPLICATION文を使用するには、ADMIN権限が必要です。
表9-2に、レプリケーション・スキームのコンポーネントおよびこの章の内容に関連する句を示します。CREATE REPLICATION文の完全な構文は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。
表9-2 レプリケーション・スキームのコンポーネント
| コンポーネント | 参照先 |
|---|---|
|
|
「レプリケーション・スキームおよびレプリケート・オブジェクトの所有者」 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
「クラシック・レプリケーション・スキームでのRETURNサービスの使用」 |
|
|
|
|
|
「クラシック・レプリケーション・スキームでのSTORE属性の設定」 |
|
|
「クラシック・レプリケーション・スキームに対するネットワーク操作の構成」 |
|
注意: CREATE REPLICATION文でのネーミング・エラーは、多くの場合、解決が困難であるため、要素名、データベース名、ホスト名に間違いがないよう時間をかけて十分に確認してください。 |
データベースで使用されるレプリケーション・スキームは、システムを再起動しても有効です。レプリケーション・スキームを変更するには、ALTER REPLICATION文を使用します。第10章「クラシック・レプリケーション・スキームの変更」を参照してください。
レプリケーション・スキームとレプリケート・オブジェクトは、レプリケーション・スキームのすべてのデータベースで、同じユーザーによって所有されている必要があります。すべてのデータベースで所有者を共通にするには、CREATE REPLICATION文にユーザーとレプリケーション・スキームを明示的に指定する必要があります。
たとえば、ユーザーreplによって所有されているrepschemeという名前のレプリケーション・スキームを作成します。repschemeのCREATE REPLICATION文の先頭行は次のようになります。
CREATE REPLICATION rep1.repscheme
レプリケーション・スキームにおけるデータベースの役割は、次のとおりです。
マスター: アプリケーションは、マスター・データベースを更新します。マスターは、更新をプロパゲータに送信するか、またはサブスクライバに直接送信します。
プロパゲータ: プロパゲータ・データベースは、マスター・データベースから更新を受信し、受信した更新をサブスクライバ・データベースに送信します。
レプリケーション・スキームを定義する前に、そのレプリケーション・スキームのデータベースのデータ・ソース名(DSN)を定義する必要があります。UNIXプラットフォームの場合は、odbc.iniファイルを作成します。Windowsの場合は、ODBCアドミニストレータを使用し、データベースを指定して接続属性を設定します。例については、「手順1: マスターおよびサブスクライバのDSNの作成」を参照してください。
レプリケーション・スキームで指定された各データベースの名前は、DSN定義内のDataStoreデータ・ストア属性で指定された、パスを除くデータベース・ファイル名の接頭辞と一致する必要があります。各DSN定義内のDataStoreデータ・ストア属性とData Source Nameデータ・ストア属性に同じ名前を使用します。データベースのパスがdirectory/subdirectory/foo.ds0の場合、使用するデータベース名はfooになります。たとえば、odbc.iniファイルのこのエントリはmasterdsのData Source Name(DSN)を示す一方で、DataStore値はmasterdsのパスを示します。
[masterds] DataStore=/tmp/masterds DatabaseCharacterSet=AL32UTF8 ConnectionCharacterSet=AL32UTF8
レプリケーション・スキームに含まれるレプリケート表の名前および所有者は、マスター・データベースとサブスクライバ・データベースで同一である必要があります。ただし、レプリケーション・スキームに含まれるレプリケート表の列の定義は、必ずしも同一である必要はありません。列定義オプションの詳細は、「レプリケート表の列定義オプション」を参照してください。
レプリケート表には、次のいずれかが必要です。
主キー
NOT NULL列に定義された一意索引
レプリケーションでは、主キーまたは一意索引を使用して、レプリケート表の各行を一意に識別します。レプリケーションでは、表の索引配列の順次確認で検出された最初の使用可能な索引を常に選択します。主キーがない場合、レプリケーションでは、NULL列が含まれていない最初の一意索引を選択します。また、マスター・データベース内のレプリケート表に対して選択された索引は、サブスクライバ内の対応する表にも存在している必要があります。
|
注意: レプリケート表のキーは、各更新レコードでサブスクライバに転送されます。キーが小さいほど、より効率的に転送されます。 |
レプリケート表には、次のようなデータ型の制限があります。
レプリケート表のVARCHAR2、NVARCHAR2、VARBINARYおよびTT_VARCHAR列のサイズは、4MBに制限されます。VARCHAR2列の場合、文字長セマンティクスを使用する際の最大長は、特定のデータベース・キャラクタ・セットを使用する際に1文字が占めるバイト数によって異なります。たとえば、1文字に4バイトが必要なキャラクタ・セットでは、最大長は100万文字になります。NVARCHAR2の列の場合、1文字に2バイトが必要なため、文字長セマンティクスを使用する際の最大長は、200万文字になります。
レプリケート表のBLOBデータ型を含む列のサイズは、16MBに制限されます。レプリケート表のCLOBデータ型またはNCLOBデータ型を含む列のサイズは、4MBに制限されます。
主キー列にはLOBデータ型を設定できません。
これらの要件および制限に問題がある場合は、トランザクション・ログAPI(XLA)をレプリケーション・メカニズムとして使用することを検討できます。『Oracle TimesTen In-Memory Database C開発者ガイド』のレプリケーション・メカニズムとしてのXLAの使用に関する説明を参照してください。
双方向レプリケーション・スキームの設計は、クラシック・レプリケーションで一般的に使用される設計です。双方向レプリケーションの元々の設計では、2つのマスターのみが含まれるものでした。しかし、双方向レプリケーション設計のマスターの数が2つという制限はありません。
3つ以上のマスター(マルチマスター・トポロジ)を使用することと、ttRepAdmin -duplicateを使用して別のストアに複製することを決定した場合、ttRepSubscriberStateSet組込みプロシージャを使用して複製ストアのサブスクライバのレプリケーション状態をリセットし、すべてのサブスクライバを適切な状態に設定する必要があります。
表9-3で示されているように、3つのマスター(master1、master2およびmaster3)があり、それぞれが相互の双方向レプリケーション・スキームを使用するように構成されています。master1でttRepAdmin -duplicateを実行してmaster1からmaster2を再作成する場合は、master2でttRepSubscriberStateSet組込みプロシージャをコールして、master3のレプリケーション状態を設定する必要があります。
クラシック・レプリケーション・スキームは、1つ以上のELEMENT記述で構成されます。ELEMENT記述には、要素の名前、そのタイプ(DATASTORE、TABLEまたはSEQUENCE)、更新が行われるマスター・データベース、更新がレプリケートされるサブスクライバ・データベースが含まれます。
要素の制限は、次のとおりです。
特定のオブジェクト(表、順序またはデータベース)を複数の要素記述に含めないでください。
マスターおよびプロパゲータの両方の役割に同じ要素を定義しないでください。
要素には、現在のホスト上のデータベースがマスター、サブスクライバまたはプロパゲータのいずれかとして含まれている必要があります。
要素名は、レプリケーション・スキーム内で一意である必要があります。
複数のサブスクライバ・スキームに要素を定義する正しい方法については、「RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム」を参照してください。要素を伝播する正しい方法については、「伝播スキーム」を参照してください。
後でALTER REPLICATION文を使用して要素の削除または変更を行う場合は、スキーム内の各要素の名前を使用して要素を識別できます。
既存のレプリケーション・スキームに表、順序およびデータベースを追加できます。「クラシック・レプリケーション・スキームの変更」を参照してください。レプリケーション・スキームから表または順序を除外した後に、そのレプリケーション・スキームの一部であるデータベースから表または順序を削除できます。「クラシック・レプリケーション・スキームからの表または順序の削除」を参照してください。
この項の後半では、次の内容について説明します。
マスター・データベース(masterds)のすべての内容をサブスクライバ・データベース(subscriberds)にレプリケートする場合、ELEMENT記述(ds1)は次のようになります。
ELEMENT ds1 DATASTORE MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2"
データベース・ホストは、hostnameオペレーティング・システム・コマンドから返されるホスト名で識別してください。ホスト名は二重引用符で囲むことをお薦めします。
CREATE REPLICATION文のEXCLUDE TABLE句およびEXCLUDE SEQUENCE句を使用すると、DATASTORE要素からの特定の表および順序の除外を選択できます。EXCLUDE句を使用すると、EXCLUDE句で指定されたオブジェクトを除くデータベース全体が、要素内のすべてのサブスクライバにレプリケートされます。1つの要素記述で使用できるEXCLUDE TABLE句およびEXCLUDE SEQUENCE句はそれぞれ1つのみです。たとえば、この要素記述では2つの表および1つの順序が除外されます。
ELEMENT ds1 DATASTORE MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2" EXCLUDE TABLE ttuser.tab1, ttuser.tab2 EXCLUDE SEQUENCE ttuser.seq1
CREATE REPLICATION文のINCLUDE TABLE句およびINCLUDE SEQUENCE句を使用すると、データベースへの特定の表および順序のみの挿入を選択できます。INCLUDE句を使用すると、INCLUDE句で指定されたオブジェクトのみが、要素内の各サブスクライバにレプリケートされます。1つの要素記述で使用できるINCLUDE TABLE句およびINCLUDE SEQUENCE句はそれぞれ1つのみです。たとえば、この要素記述では1つの表および2つの順序が挿入されます。
ELEMENT ds1 DATASTORE MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2" INCLUDE TABLE ttuser.tab3 INCLUDE SEQUENCE ttuser.seq2, ttuser.seq3
表ttuser.tab1およびttuser.tab2を(masterdsという名前でホストsystem1に配置されている)マスター・データベースから(subscriberdsという名前でホストsystem2に配置されている)サブスクライバ・データベースにレプリケートする場合、ELEMENT記述(aおよびb)は次のようになります。
ELEMENT a TABLE ttuser.tab1 MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2" ELEMENT b TABLE ttuser.tab2 MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2"
クラシック・レプリケーション・スキームの表の要件については、「クラシック・レプリケーション・スキームの表要件および制限」を参照してください。
クラシック・レプリケーション・スキームでは、外部キーで互いに関連付けられている表は、すべての表をレプリケートするか一部の表のみをレプリケートするかを選択できます。これを行うには、各マスターおよびサブスクライバに、表および外部キー関係を作成します。その後、各マスターおよびサブスクライバでALTER REPLICATION ADD ELEMENT文を使用して、表をレプリケーション・スキームに追加します。
ただし、外部キー関係がON DELETE CASCADEを使用して構成されている場合は、すべての表をレプリケーション・スキームを作成する前に作成する必要があります。その後、CREATE REPLICATION文を使用してすべての表を含むようにレプリケーション・スキームを構成しますが、その際、DATASTORE要素(どの表も除外しない)、または関連付けられているすべての表に対してTABLE要素のいずれかを使用します。
ALTER REPLICATION文を使用してレプリケーション・スキームを作成した後に、ON DELETE CASCADEで構成された外部キーで関連付けられている表をレプリケーション・スキームに追加することはできません。かわりに、レプリケーション・スキームを削除し、ON DELETE CASCADEで構成された外部キーで関連付けられている新しい表を作成してから、関連するすべての表を含む新しいレプリケーション・スキームを作成します。
ON DELETE CASCADEで構成された外部キーを持つ表をレプリケートする場合は、サブスクライバ上の対応する外部キーもON DELETE CASCADEで構成されている必要があります。また、その表に対して外部キーで関連付けられている他のすべての表もレプリケートする必要があります。この要件によって、マスター・データベースでカスケード削除を実行した場合にサブスクライバ表で競合が発生しなくなります。
TimesTenでは、カスケード削除が1つの操作としてレプリケートされ、親表で行が削除された場合に子表で発生する個々の行削除はサブスクライバにレプリケートされません。そのため、親表で削除された外部キーの値を含む行がサブスクライバ・データベースの子表に存在する場合は、その行がマスター・データベースの子表に存在していなかった場合でも削除されます。
順序は、レプリケーション・スキームから除外したり、CYCLE属性が指定されていないかぎり、レプリケートされます。順序のレプリケーションは、アクティブ・データベースで順序が更新されるたびに、スタンバイ・データベースで順序番号の範囲を予約することによって最適化されます。順序番号の範囲を予約すると、トランザクション・ログの更新回数を減らすことができます。順序番号の範囲はキャッシュと呼ばれます。アクティブ・データベースでの順序の更新のレプリケートは、順序の更新後にレプリケート・トランザクションが実行される場合、または順序の更新がレプリケート・トランザクションで使用される場合にのみ実行されます。
MINVALUEが1で、INCREMENTが1、デフォルトのCacheが20の順序my.seqについて考えてみます。my.seq.NEXTVALを初めて使用すると、マスター・データベースの順序の現在値は2に変更され、新しい現在値21(20+1)がサブスクライバにレプリケートされます。マスター・データベースのmy.seq.NEXTVALへの次の19回の参照では、サブスクライバ・データベースの現在値21がマスターの現在値より大きいため、新しい現在値のレプリケートは行われません。my.seq.NEXTVALへの21回目の参照では、前回レプリケートされたサブスクライバの現在値21が、この時点でマスターの現在値22より小さくなるため、新しい現在値41(21+20)がサブスクライバ・データベースに送信されます。
順序のレプリケーションには、次の制限があります。
CYCLE属性が指定された順序はレプリケートできません。
レプリケートされる順序の定義は、各ピア・データベースで同じである必要があります。
順序では、競合の検出は実行されません。RETURN TWOSAFEサービスを使用せずに、双方向レプリケーション構成で両方のデータベースの順序を更新すると、両方の順序によって同じNEXTVALが返される可能性があります。
いずれかのピアで更新が行われる双方向レプリケーション・スキームで順序を使用する必要がある場合は、競合を回避するために、各データベースで、異なるMINVALUEおよびMAXVALUE属性が指定された、レプリケートされない順序をかわりに使用できます。たとえば、MINVALUEが1で、MAXVALUEが100の順序my.seqをデータベースDS1に作成し、MINVALUEが101で、MAXVALUEが200の同じ順序をDS2に作成するとします。この場合、DS1およびDS2を双方向レプリケーション・スキームで構成すると、順序my.seqを使用して、いずれのデータベースに対しても順序値が競合しないことを保証して更新を行うことができます。この構成でttRepAdmin -duplicateを使用して障害からリカバリする場合は、複製操作を実行した後で順序を削除し、新しいMINVALUEおよびMAXVALUEを指定して順序を再作成する必要があることに注意してください。
SELECT my.seq.NEXTVAL FROM sys.dualなどの順序に対する操作では、順序値は増加しますが、レプリケートされる表でのトランザクションをその後に行うまでレプリケートは実行されません。この動作には、レプリケートされる表でのトランザクションをその後に行うまでこれらの順序の更新がログからパージされないという副作用があります。このため、これらの順序の更新のみがログの末尾に存在する場合は、ttRepSubscriberWaitおよびttRepAdmin -waitで障害が発生します。
順序ttuser.seqを(masterdsという名前でホストsystem1に配置されている)マスター・データベースから(subscriberdsという名前でホストsystem2に配置されている)サブスクライバ・データベースにレプリケートする場合、要素記述(a)は次のようになります。
ELEMENT a SEQUENCE ttuser.seq MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2"
マテリアライズド・ビューは、ディテール表と呼ばれる1つ以上のTimesTen表から選択されたデータのサマリーです。マテリアライズド・ビューは直接レプリケートできませんが、マテリアライズド・ビューの基礎となるディテール表は通常のTimesTen表の場合と同じ方法でレプリケートできます。
マスター・データベースおよびサブスクライバ・データベースのディテール表は、マテリアライズド・ビューで参照できます。ただし、TimesTenレプリケーションでは、レプリケート対象のディテール表の構造がマスターおよびサブスクライバの両方で同じであることのみが検証されます。マテリアライズド・ビューが各データベースで同じである必要はありません。
マテリアライズド・ビューまたは非マテリアライズド・ビューがDATASTORE要素として含まれているデータベース全体をレプリケートする場合は、ビューに関連付けられているディテール表のみがレプリケートされます。ビュー自体はレプリケートされません。一致するビューは、サブスクライバ・データベースで定義できますが、必須ではありません。ディテール表がレプリケートされると、TimesTenはそれに対応するビューを自動的に更新します。
マテリアライズド・ビューが更新されたときに、オーバーフローまたはアンダーフロー状態が発生するように指定されている場合、レプリケート対象の表に定義されたマテリアライズド・ビューで、レプリケーション障害または非一貫性が発生する場合があります。
データベースが双方向レプリケーションに構成されている場合、複数のデータベースの同一表行が個別に同時に更新されると、レプリケーション競合が発生する可能性があります。
このような競合は、レプリケート表にタイムスタンプを含め、各表の要素記述にオプションのCHECK CONFLICTS句を指定してレプリケーション・スキームを構成することによって、表単位で検出および解消できます。
レプリケーション競合、およびCREATE REPLICATION文のCHECK CONFLICTS句の構成方法の詳細は、第13章「レプリケーション競合の解消」を参照してください。
非同期またはRETURN RECEIPTのレプリケーションで構成されたマスター・データベースは、デフォルトでは永続的になります。そのため、トランザクションのコミットと同時にログ・レコードはディスクにコミットされます。要素記述にTRANSMIT NONDURABLE句を使用して、マスター・データベースを非永続的に設定することもできます。
デフォルトでは、マスター・データベースのログ・バッファ内のトランザクション・レコードは、サブスクライバに転送される前にディスクにフラッシュされます。マスター・データベース全体をレプリケートする(ELEMENTのタイプがDATASTOREである)場合、マスターのログをディスクにフラッシュする処理をレプリケーション・サイクルから除くことによって、レプリケーション・パフォーマンスを向上できます。これを実現するには、要素記述にTRANSMIT NONDURABLE句を含めます。TRANSMITを設定しても、サブスクライバに影響はありません。サブスクライバ・データベースのトランザクション・レコードは、常にディスクにフラッシュされます。
RETURN TWOSAFEレプリケーションで構成されたマスター・データベースはデフォルトでは非永続的になり、永続的にすることはできません。RETURN TWOSAFEレプリケーションで構成されたデータベースにTRANSMIT DURABLEを設定しても、RETURN TWOSAFEトランザクションに影響はありません。
例9-1 TRANSMIT NONDURABLEが設定されたマスター・データベース全体のレプリケーション
マスター・データベース(masterds)のすべての内容をサブスクライバ・データベース(subscriberds)にレプリケートする場合およびログをディスクにフラッシュする処理を除く場合、要素記述(a)は次のようになります。
ELEMENT a DATASTORE MASTER masterds ON "system1" TRANSMIT NONDURABLE SUBSCRIBER subscriberds ON "system2"
通常、マスター・データベースで障害が発生した場合は、ttRepAdmin -duplicate処理(「障害が発生したデータベースのリカバリ」を参照)を開始して、障害が発生したマスターをサブスクライバ・データベースからリカバリする必要があります。これは、マスター・データベースがTRANSMIT DURABLEで構成されている場合は常に適用されます。
TRANSMIT NONDURABLEとして構成されたデータベースは、特定のタイプの双方向スキームで構成されている場合、サブスクライバ・レプリケーション・エージェントによって自動的にリカバリされます(「障害が発生したマスター・データベースの自動キャッチアップ」を参照)。そうでない場合は、「非永続的データベースのリカバリ」の手順に従って、障害が発生した非永続的データベースをリカバリする必要があります。
RETURNサービスを指定してレプリケーション・スキームを構成すると、レプリケーション・データが、マスターおよびサブスクライバ両方のデータベースで一貫していることをより高いレベルの信頼性を持って保証できます。この項では、RETURN RECEIPTおよびRETURN TWOSAFEサービスの構成方法および管理方法について説明します。
CREATE REPLICATIONまたはALTER REPLICATION文で定義されるいずれのサブスクライバの表要素およびデータベース要素に対してもRETURNサービスを指定できます。
マスターおよびサブスクライバ用にRETURNサービスを構成する方法の完全な詳細は、「RETURNサービスの使用」を参照してください。
CREATE REPLICATION文およびALTER REPLICATION文のSTORE属性句は、RETURNサービス、圧縮、タイムアウト、永続コミット動作、競合レポートおよび表定義チェックのオプション動作を設定するために使用されます。クラシック・レプリケーション・スキーム用にSTORE属性を構成および使用する方法の完全な詳細は、「STORE属性の設定」を参照してください。STORE属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE ACTIVE STANDBY PAIRに関する説明を参照してください。
レプリケーション・ホストにネットワーク・インタフェースが複数ある場合は、デフォルト以外のインタフェースを使用するようにレプリケーションを構成することもできます。クラシック・レプリケーション・スキーム用に2つ以上のネットワーク・インタフェースを構成する方法の詳細は、「ROUTE句を使用したネットワーク・インタフェースの構成」を参照してください。
この項で説明する次の例では、様々なクラシック・レプリケーション・スキームの構成方法を示します。
例9-2のクラシック・レプリケーション・スキームは、単一のマスターおよびサブスクライバの単方向レプリケーション・スキームです。2つのデータベースが別々のホストsystem1およびsystem2に配置されています。RETURN RECEIPTサービスを使用して、マスター・データベースのttuser.tab表に対してコミットしたすべてのトランザクションがサブスクライバで受信されることを確認します。
例9-2 1つの表のレプリケーション
CREATE REPLICATION repscheme
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT;
例9-3のスキームは、単一のマスターおよびサブスクライバの単方向レプリケーション・スキームです。2つのデータベースが別々のホストserver1およびserver2に配置されています。マスター・データベースmasterdsは、そのすべての内容をサブスクライバ・データベースsubscriberdsにレプリケートします。
最大128のサブスクライバ・データベースを含むクラシック・レプリケーション・スキームを作成できます。プロパゲータ・データベースを構成する場合は、最大128のプロパゲータを構成できます。各プロパゲータには最大128のサブスクライバ・データベースを構成できます。プロパゲータ・データベースを使用するクラシック・レプリケーション・スキームの例は、「伝播スキーム」を参照してください。
例9-4 2つのサブスクライバへのレプリケーション
この例では、server2にあるsubscriber1dsおよびserver3にあるsubscriber2dsという2つのサブスクライバ・データベースにttuser.tab表をレプリケートするマスター・データベースmasterdsを設定します。クラシック・レプリケーション・スキームの名前はtwosubscribersです。レプリケーション要素の名前はeです。
CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1ds ON "server2",
subscriber2ds ON "server3";
例9-5 RETURN RECEIPTを指定した2つのサブスクライバへのレプリケーション
この例では、例9-4の基本的な例を使用し、それにRETURN RECEIPT属性およびSTOREパラメータを追加します。RETURN RECEIPTで、両方のデータベースに対するRETURN RECEIPTサービスを有効にします。STOREパラメータで、FAILTHRESHOLD値を10に設定し、サブスクライバで障害が発生したとみなされるまでmasterdsに累積可能な、サブスクライバに対するトランザクション・ログ・ファイルの最大数を指定します。
CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1ds ON "server2",
subscriber2ds ON "server3"
RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;
例9-6 1つのみのサブスクライバに対するRETURN RECEIPTの有効化
この例では、subscriber2dsに対してのみRETURN RECEIPTを有効にする方法を示します。subscriber1ds定義の末尾のカンマは不要です。
CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1ds ON "server2"
SUBSCRIBER subscriber2ds ON "server3" RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;
例9-7 サブスクライバで異なるRETURNサービスの有効化
この例では、RETURN RECEIPT BY REQUESTをsubscriber1dsに、RETURN RECEIPTをsubscriber2dsに適用する方法を示します。このクラシック・レプリケーション・スキームでは、subscriber1dsにアクセスするアプリケーションは、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURNサービスを有効にする必要があります。一方、subscriber2dsは無条件に、すべてのトランザクションに対してRETURNサービスを提供します。
CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriberds1 ON "server2" RETURN RECEIPT BY REQUEST
SUBSCRIBER subscriber2ds ON "server3" RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;
例9-8に示されるクラシック・レプリケーション・スキームは、4つの表をレプリケートするcentraldsという名前のマスター・データベースを設定します。ttuser.tab1とttuser.tab2は、サブスクライバbackup1dsにレプリケートされます。ttuser.tab3とttuser.tab4は、backup2dsにレプリケートされます。マスター・データベースはfinanceサーバーにあります。両方のサブスクライバがサーバーbackupsystemに配置されています。
例9-8 異なるサブスクライバへの表のレプリケーション
CREATE REPLICATION twobackups ELEMENT a TABLE ttuser.tab1 MASTER centralds ON "finance" SUBSCRIBER backup1ds ON "backupsystem" ELEMENT b TABLE ttuser.tab2 MASTER centralds ON "finance" SUBSCRIBER backup1ds ON "backupsystem" ELEMENT d TABLE ttuser.tab3 MASTER centralds ON "finance" SUBSCRIBER backup2ds ON "backupsystem" ELEMENT d TABLE ttuser.tab4 MASTER centralds ON "finance" SUBSCRIBER backup2ds ON "backupsystem";
例9-9では、マスター・データベースからプロパゲータに表の更新が送信され、プロパゲータは、2つのサブスクライバに変更を転送します。マスター・データベースはホストfinanceのcentraldsです。プロパゲータ・データベースはホストnethandlerのpropdsです。サブスクライバは、backupsystem1のbackup1dsおよびbackupsystem2のbackup2dsです。
クラシック・レプリケーション・スキームには2つの要素があります。要素aでは、centraldsのtab表に対する変更がプロパゲータ・データベースpropdsにレプリケートされます。要素bでは、propdsで受信したtab表への変更が2つのサブスクライバbackup1dsおよびbackup2dsにレプリケートされます。
例9-10では、ホストwestcoastのwestdsおよびホストeastcoastのeastdsという2つのデータベースがあります。顧客は2つの表で表され、西地区の顧客のデータはwaccounts、東地区の顧客のデータはeaccountsに収められます。westdsデータベースは、waccounts表を更新してeastdsデータベースにレプリケートします。eaccounts表は、eastdsデータベースによって所有され、westdsデータベースにレプリケートされます。RETURN RECEIPT属性は、RETURN RECEIPTサービスを有効にして、いずれのマスター表のトランザクションもそれらのサブスクライバによって受信されることを保証します。
例9-11に、eastdsまたはwestdsのいずれかのデータベースでttuser.accounts表を更新できる一般ワークロードの双方向クラシック・レプリケーション・スキームを示します。各データベースは、accounts表に対してマスターおよびサブスクライバの両方になります。
|
注意: RETURN TWOSAFE戻りサービスを構成して双方向の分散ワークロード・レプリケーション・スキームを使用しないでください。 |
例9-11 双方向の分散ワークロード・スキーム
CREATE REPLICATION r1 ELEMENT elem_accounts_1 TABLE ttuser.accounts MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" ELEMENT elem_accounts_2 TABLE ttuser.accounts MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast";
要素をこの手法でレプリケートする場合、アプリケーションでは、各データベースへの書込みを調整して、同じデータに同時に更新が行われないようにする必要があります。更新競合を管理するには、BINARY(8)型のタイムスタンプ列をレプリケート表に含め、CREATE REPLICATION文にCHECK CONFLICTS句を含めてタイムスタンプ比較を有効にします。更新競合の管理方法の詳細は、第13章「レプリケーション競合の解消」を参照してください。
例9-12では、ttuser.accounts表にtstampタイムスタンプ列が含まれています。CREATE REPLICATION文は、CHECK CONFLICTS句が含まれるように変更されています。
例9-12 更新競合の管理
CREATE TABLE ttuser.accounts (custname VARCHAR2(30) NOT NULL,
address VARCHAR2(80),
curbalance DEC(15,2),
tstamp BINARY(8),
PRIMARY KEY (custname));
CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE ttuser.accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE ttuser.accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast";
クラシック・レプリケーション・スキームを定義する際、CREATE REPLICATION文をSQLファイルに保存します。SQLファイルにクラシック・レプリケーション・スキームを記述した後、-fオプションを指定してttIsqlユーティリティ使用すると、データベースに対してSQLを実行できます。構文は次のとおりです。
ttIsql -f schemefile.sql -connstr "dsn=DSN"
例9-13 SQLファイルの実行によるクラシック・レプリケーション・スキームの作成
クラシック・レプリケーション・スキームをファイルrepscheme.sqlに記述した後、次のように入力して、masterDSNというDSNに対してファイルを実行できます。
> ttIsql -f repscheme.sql -connstr "dsn=masterDSN"
ほとんどの場合、すべてのレプリケート・データベースに対して同じスキームを適用する必要があります。ホストごとに個別のttIsqlコマンドを実行してクラシック・レプリケーション・スキームを適用する必要があります。
例9-14 ホストごとのSQLファイルの実行
クラシック・レプリケーション・スキームが、ホストS1上にmasterDSN、ホストS2上にsubscriber1DSN、ホストS3上のsubscriber2DSNの各データベースを含んでいる場合は、次のようにします。
ホストS1では、次のように入力します。
> ttIsql -f repscheme.sql -connstr "dsn=masterDSN"
ホストS2では、次のように入力します。
> ttIsql -f repscheme.sql -connstr "dsn=subscriber1DSN"
ホストS3では、次のように入力します。
> ttIsql -f repscheme.sql -connstr "dsn=subscriber2DSN"
クラシック・レプリケーション・スキームが含まれているSQLファイルは、データベースへの接続後に、ttIsqlコマンドラインからも実行できます。次に例を示します。
Command> run repscheme.sql;
クラシック・レプリケーション・スキームをスクリプトで作成すると、時間の節約および誤りの回避に有効です。この項では、Perlを使用してレプリケーション・スキームの作成を自動化する場合の推奨事項をいくつか示します。
例9-15に示す一般的なワークロードの双方向スキームについて考えてみます。5つの表ttuser.accounts、ttuser.sales、ttuser.orders、ttuser.inventoryおよびttuser.customersへの要素記述への入力を手動で行うと、時間がかかり、エラーも発生しやすくなります。
例9-15 一般ワークロードの双方向レプリケーション・スキーム
CREATE REPLICATION bigscheme ELEMENT elem_accounts_1 TABLE ttuser.accounts MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" ELEMENT elem_accounts_2 TABLE ttuser.accounts MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast" ELEMENT elem_sales_1 TABLE ttuser.sales MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" ELEMENT elem_sales_2 TABLE ttuser.sales MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast" ELEMENT elem_orders_1 TABLE ttuser.orders MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" ELEMENT elem_orders_2 TABLE ttuser.orders MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast" ELEMENT elem_inventory_1 TABLE ttuser.inventory MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" ELEMENT elem_inventory_2 TABLE ttuser.inventory MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast" ELEMENT elem_customers_1 TABLE ttuser.customers MASTER westds ON "westcoast" SUBSCRIBER eastds ON "eastcoast" ELEMENT elem_customers_2 TABLE ttuser.customers MASTER eastds ON "eastcoast" SUBSCRIBER westds ON "westcoast";
多くの場合、スクリプトを使用してクラシック・レプリケーション・スキームの作成プロセスを自動化するとより効率的です。たとえば、例9-16に示すPerlスクリプトを使用して、例9-15に示したスキームを作成できます。
例9-16 レプリケーション・スキーム作成でのPerlスクリプトの使用
@tables = qw(
ttuser.accounts
ttuser.sales
ttuser.orders
ttuser.inventory
ttuser.customers
);
print "CREATE REPLICATION bigscheme";
foreach $table (@tables) {
$element = $table;
$element =~ s/repl\./elem\_/;
print "\n";
print " ELEMENT $element\_1 TABLE $table\n";
print " MASTER westds ON \"westcoast\"\n";
print " SUBSCRIBER eastds ON \"eastcoast\"\n";
print " ELEMENT $element\_2 TABLE $table\n";
print " MASTER eastds ON \"eastcoast\"\n";
print " SUBSCRIBER westds ON \"westcoast\"";
}
print ";\n";
例9-16の@tables配列は、データベースなどの他の一部のソースから取得できます。たとえば、Perl文でttIsqlおよびfを使用して、所有者名がreplのWestDSNデータベース内のすべての表に対して@tables配列を生成できます。
@tables = 'ttIsql -e "tables; quit" WestDSN
| grep " REPL\."';
例9-17に、WestDSNデータベース内のすべてのrepl表に対してクラシック・レプリケーション・スキームを作成する例9-16のスクリプトの変更バージョンを示します。grep出力から余分な空白および改行を削除するには、置換を行う必要があります。
例9-17 WestDSNにあるすべての表に対するレプリケーション・スキーム作成のためのPerlスクリプト
@tables = 'ttIsql -e "tables; quit" WestDSN
| grep " REPL\."';
print "CREATE REPLICATION bigscheme";
foreach $table (@tables) {
$table =~ s/^\s*//; # Remove extra spaces
$table =~ s/\n//; # Remove line feeds
$element = $table;
$element =~ s/repl\./elem\_/;
print "\n";
print " ELEMENT $element\_1 TABLE $table\n";
print " MASTER westds ON \"westcoast\"\n";
print " SUBSCRIBER eastds ON \"eastcoast\"\n";
print " ELEMENT $element\_2 TABLE $table\n";
print " MASTER eastds ON \"eastcoast\"\n";
print " SUBSCRIBER westds ON \"westcoast\"";
}
print ";\n";
