| Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド
リリース7.0 E05169-03 |
|
 前へ |
 次へ |
「TimesTenレプリケーション」で説明されているように、すべてのレプリケーション・スキームの主要目的は次のとおりです。
高可用性システムを設計する場合、マスター・データ・ストアに影響を与える可能性がある障害が発生しても、サブスクライバ・データ・ストアは影響を受けないようにする必要があります。最低限、マスターとサブスクライバは別々のマシンに配置する必要があります。一部のアプリケーションでは、個別の電源を供給できる環境にサブスクライバを配置する必要がある場合もあります。場合によっては、完全に別のサイトにサブスクライバを配置する必要もあります。
アプリケーションのワークロードを最も効率的に分散し、限られた数のサーバー・マシンを最大限利用できるようにデータ・ストアを設定します。たとえば、各サーバーがホット・スタンバイ構成で個別にマスターおよびサブスクライバとして機能するのではなく、マスターおよびサブスクライバの両方として機能するように分散ワークロード方式で双方向にデータ・ストアを設定するほうが、より効率的で経済的です。ただし、分散ワークロード・スキームは、主にデータ・ストアから読取りを行うアプリケーションで最も効率的に機能します。データ・ストアの同じ要素に頻繁に書込みを行うアプリケーションに対して分散ワークロード・スキームを実装すると、パフォーマンスが低下し、更新競合を回避または管理するための解決方法を実装するように要求される可能性があります（「レプリケーション競合の検出および解消」を参照）。
レプリケーション・スキームを計画する場合は、想定可能なすべてのフェイルオーバーおよびリカバリの使用例を検討してください。たとえば、通常、サブスクライバで発生した障害は、マスター・データ・ストアに接続しているアプリケーションには影響が及ばないため、ユーザー・サービスを中断せずにリカバリできます。一方、マスター・データ・ストアで障害が発生した場合は、アプリケーションのロードをサブスクライバにリダイレクトし、中断なしまたは最小限の中断でサービスを続行するための方法が必要です。通常、この処理は、クラスタ・マネージャまたはカスタム・ソフトウェアによって行われます。このソフトウェアは、障害を検出し、障害が発生したデータ・ストアからそのサブスクライバの1つにユーザーまたはアプリケーションをリダイレクトして、障害が発生したデータ・ストアのリカバリを管理するように設計されています。
フェイルオーバー方法を計画する場合は、マスターの役割を引き受けるサブスクライバおよび対象ユーザーまたはアプリケーションについて検討してください。また、障害が発生したマスターがそのデータ・ストアを最新のサブスクライバからリカバリできる必要があること、すべてのサブスクライバをそのマスターからリカバリできる必要があることなどのリカバリの要件についても検討してください。
図3.1に示す、単方向にレプリケートされるデータ・ストアの障害例について考えてみます。マスターで障害が発生した場合、アプリケーションは、サブスクライバからリカバリされるまでデータ・ストアにアクセスできません。ALTER REPLICATION文を使用してサブスクライバ・データ・ストアをマスターとして再定義しないかぎり、アプリケーションの接続またはユーザー・ロードをサブスクライバに切り替える方法はありません。
図3.2に示すホット・スタンバイ・スキームなどの双方向一般ワークロード・スキームでデータ・ストアが設定されている場合、フェイルオーバーおよびリカバリはより効率的に実行されます。ホット・スタンバイ・スキームでは、マスター・データ・ストアで障害が発生した場合、クラスタ・マネージャで、ユーザー・ロードをサブスクライバ・データ・ストアのホット・スタンバイ・アプリケーションに切り替える必要のみがあります。障害が発生したデータ・ストアがリカバリされると、サービスへの割込みを最小限に抑えてマスター/サブスクライバの役割を入れ替え、レプリケーションを再開できます。
図3.3に示すような分散ワークロード・スキームを使用して設定したデータ・ストアのフェイルオーバー手順は、ホット・スタンバイで使用した手順と類似しています。ただし、障害が発生したデータ・ストアによって影響を受けたユーザーを移動して、影響を受けなかったデータ・ストア上のアプリケーションの他のユーザーに追加する必要があります。リカバリが完了すると、リカバリしたデータ・ストア上のアプリケーションにワークロードを再分散できます。
レプリケーション・スキームの設計時に、フェイルオーバーおよびリカバリの複雑さとパフォーマンスの効率を比較する必要があります。フェイルオーバーおよびリカバリを複雑にする要因には、マスターをそのサブスクライバと接続するネットワーク・トポロジ、レプリケーション・スキームの複雑さなどがあります。たとえば、選択した要素が異なるサブスクライバにレプリケートされるマスターをリカバリするより、1つのサブスクライバに完全にレプリケートされるマスターをリカバリするほうがより簡単です。
レプリケーションは、非同期、RETURN RECEIPTサービスによる半同期、またはRETURN TWOSAFEサービスによる完全同期で動作するように設定できます（「レプリケーションの動作」を参照）。次の項では、非同期、RETURN RECEIPTおよびRETURN TWOSAFEモードの動作の概要を示し、それらの動作によるレプリケーションのパフォーマンスおよび障害からのリカバリ機能への影響を比較します。ここでは、双方向のホット・スタンバイ・レプリケーションおよびデータ・ストア全体のレプリケーションに設定された2つのデータ・ストアがあることを想定しています。
フェイルオーバーおよびリカバリの詳細は、「データ・ストアのフェイルオーバーおよびリカバリの管理」を参照してください。
マスター・データ・ストアは、永続的または非永続的のいずれかになります（「レプリケーション・エージェントによって更新をデータ・ストア間でコピーする方法」および「データ・ストア要素に対する送信永続性の設定」を参照）。非同期またはRETURN RECEIPTのレプリケーションで設定されたマスター・データ・ストアはデフォルトでは永続的になりますが、CREATE REPLICATION文のTRANSMIT NONDURABLEオプションを使用して非永続的に設定することもできます。RETURN TWOSAFEレプリケーションで設定されたマスター・データ・ストアはデフォルトでは非永続的になり、永続的にすることはできません。
通常、マスター・データ・ストアで障害が発生した場合は、ttRepAdmin -duplicate 処理（「障害が発生したデータ・ストアのリカバリ」を参照）を開始して、障害が発生したマスターをサブスクライバ・データ・ストアからリカバリする必要があります。これは、マスター・データ・ストアがTRANSMIT DURABLEで設定されている場合は常に適用されます。
TRANSMIT NONDURABLEで設定されたデータ・ストアは、特定のタイプのホット・スタンバイ・スキームで設定されている場合、サブスクライバ・レプリケーション・エージェントによって自動的にリカバリされます（「障害が発生したマスター・データ・ストアの自動キャッチアップ」を参照）。そうでない場合は、「NONDURABLEデータ・ストアのリカバリ」の手順に従って、障害が発生した非永続的データ・ストアをリカバリする必要があります。
いずれのタイプのレプリケーション構成のサブスクライバで障害が発生した場合でも、そのサブスクライバをリカバリしてレプリケーションを再開することができます。リカバリされたサブスクライバで一部のトランザクション・レコードが欠落している場合がありますが、確認応答が行われていないトランザクションに関連付けられているすべてのレコードがマスターからサブスクライバに再送信されます（これは、RETURNサービスによって有効にされたアプリケーション・レベルの確認応答ではなく、サブスクライバ・レプリケーション・エージェントがマスター・レプリケーション・エージェントに送信する確認応答です）。サブスクライバは、重複レコードを自動的に削除します。
別の方法として、ttRepAdmin -duplicate処理（「障害が発生したデータ・ストアのリカバリ」を参照）を開始して、障害が発生したサブスクライバをリカバリする方法もあります。
詳細は、「サブスクライバの障害」を参照してください。
