TimesTen Classic内のデータ・レプリケーション
TimesTen Classic内のデータ・レプリケーションの重要な目的は、パフォーマンスへの影響を最小限に抑えて、アプリケーションのデータの可用性を高めることにあります。障害リカバリにおける役割の他に、レプリケーションは、アプリケーション・ワークロードを複数のデータベースに分散してパフォーマンスを最大化させたり、オンライン・アップグレードとメンテナンスを容易にする場合にも有効です。
レプリケーションとは、データをマスター・データベースからサブスクライバ・データベースにコピーするプロセスのことです。マスターおよびサブスクライバの各データベースのレプリケーションは、TCP/IPストリーム・ソケットを介して通信するレプリケーション・ エージェントによって制御されます。マスター・データベースのレプリケーション・エージェントは、マスター・データベースのトランザクション・ログからレコードを読み取ります。レプリケートされた要素への変更をサブスクライバ・データベースのレプリケーション・エージェントに転送します。その後、サブスクライバ・データベースのレプリケーション・エージェントが、それらの更新をサブスクライバ・データベースに適用します。マスター・エージェントは、更新転送時にサブスクライバ・エージェントが稼働していない場合、サブスクライバで適用可能になるまでそれらの更新をトランザクション・ログに保持します。
データベースの作成時にパラレル・レプリケーションを構成することで、レプリケーションのスループットを向上できます。サブスクライバに更新を適用するためのスレッド数を構成します。更新はコミット順に転送されます。『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』の自動パラレル・レプリケーションの構成を参照してください。
TimesTenで可用性を最大限に高めるには、アクティブ・スタンバイ・ペア構成をお薦めします。これは、キャッシュ・グループのレプリケートに使用できる唯一のレプリケーション構成です。
ノート:
レプリケーションの詳細は、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のTimesTenレプリケーションの概要を参照してください。
この項の後半の内容は次のとおりです。
アクティブ・スタンバイ・ペア
アクティブ・スタンバイ・ペアには、アクティブ・データベース、スタンバイ・データベース、オプションの読取り専用サブスクライバ・データベース、データベースを構成する表およびキャッシュ・グループが含まれます。
図6-1に、アクティブ・スタンバイ・ペアを示します。
アクティブ・スタンバイ・ペアでは、2つのデータベースがマスターとして定義されます。1つは、アクティブ・データベースで、もう1つはスタンバイ・データベースです。アクティブ・データベースは直接更新されます。スタンバイ・データベースは、直接更新できません。これは、アクティブ・データベースからの更新を受信し、それらの変更を読取り専用サブスクライバに伝播します。この構成では、スタンバイ・データベースが読取り専用サブスクライバより常に先行し、アクティブ・データベースで障害が発生した場合は、スタンバイ・データベースに即時にフェイルオーバーできます。
1つのマスター・データベースのみが、特定の時間にアクティブ・データベースとして機能できます。アクティブ・データベースで障害が発生した場合は、障害が発生したデータベースをスタンバイ・データベースとしてリカバリする前に、スタンバイ・データベースのロールをアクティブに変更する必要があります。新しいスタンバイ・データベースで、レプリケーション・エージェントを起動する必要があります。
スタンバイ・データベースで障害が発生した場合は、アクティブ・データベースから読取り専用サブスクライバに変更を直接レプリケートします。スタンバイ・データベースは、リカバリ後、アクティブ・データベースに接続し、スタンバイ・データベースの停止またはリカバリ中に読取り専用サブスクライバに送信された更新を受信します。アクティブ・データベースとスタンバイ・データベースで同期が取られている場合、スタンバイ・データベースは、サブスクライバへの変更の伝播を再開します。
アクティブ・スタンバイ・レプリケーションをキャッシュとともに使用すると、層をまたいだ高可用性を実現できます。アクティブ・スタンバイ・レプリケーションは、読取り専用キャッシュ・グループおよび非同期のWRITETHROUGHキャッシュ・グループの両方で使用可能です。読取り専用キャッシュ・グループとともに使用する場合、更新はOracle Databaseからアクティブ・データベースに送信されます。つまり、この構成のOracle Databaseは、アプリケーションの役割を果たします。同期のWRITETHROUGHキャッシュ・グループとともに使用する場合、スタンバイ・データベースはアクティブ・データベースから受信した更新をOracle Databaseに伝播します。この場合、Oracle Databaseは読取り専用サブスクライバの役割を果たします。
これらのタイプのキャッシュ・グループのいずれかをレプリケートするアクティブ・スタンバイ・ペアでは、フェイルオーバーを実行できるため、データ損失を最小限に抑えて自動的にリカバリを実行できます。『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のアクティブ・スタンバイ・ペア内のキャッシュ・グループのレプリケートを参照してください。
クラシック・レプリケーション構成
TimesTenレプリケーション・アーキテクチャには、パフォーマンスおよび可用性のバランスをとることのできる十分な柔軟性が備えられています。
通常、クラシック・レプリケーションは次のように構成できます。
- 単方向レプリケーション: マスターから1つ以上のサブスクライバへの単方向。
-
双方向レプリケーション: マスターおよびサブスクライバの両方として機能する2つ以上のデータベース間の双方向。
単方向レプリケーション
単方向レプリケーション・スキームでは、アプリケーションは、マスター・ホストで障害が発生した場合にサブスクライバが処理を引き継ぐように両方のホストで構成されます。
図6-2に、単方向レプリケーション・スキームを示します。
マスター・ノードが稼働中の場合、アプリケーションからマスター・データベースへの更新がサブスクライバ・データベースにレプリケートされます。サブスクライバ・ホスト上のアプリケーションはサブスクライバ・データベースに対する更新は実行しませんが、サブスクライバ・データベースからの読取りを行うことがあります。マスターで障害が発生した場合、サブスクライバ・ホスト上のアプリケーションは更新機能を引き継ぎ、サブスクライバ・データベースの更新を開始します。
レプリケーションは、更新を1つのマスター・データベースから多くのサブスクライバ・データベースにコピーする場合にも使用できます。図6-3に、複数のサブスクライバが存在するレプリケーション・スキームを示します。
図6-4に、伝播の構成を示します。1つのマスター・コピーは、3つのサブスクライバ・ノードに更新されます。このノードは、プロパゲータ・ノードとして機能し、追加サブスクライバに同じ更新を転送します。
非同期およびRETURNサービス・レプリケーション
TimesTenレプリケーションは、デフォルトで非同期です。非同期レプリケーションを使用する場合、アプリケーションは、マスター・データベースを更新すると、サブスクライバがその更新を受信するまで待機せずに処理を続行します。
マスターおよびサブスクライバのデータベースには、サブスクライバが更新を正常に受信およびコミットしたことを確認するための内部メカニズムがあります。これらのメカニズムは、更新がサブスクライバで1回のみ適用されることを保証しますが、アプリケーションでは透過的です。
非同期レプリケーションは最高のパフォーマンスを実現しますが、アプリケーションは、サブスクライバ上のレプリケートされた要素の受信プロセスと完全に切り離されます。また、TimesTenでは、レプリケートされたデータがマスター・データベースとサブスクライバ・データベース間で一貫していることをより高いレベルで保証する必要があるアプリケーションに、2つのRETURNサービス・オプションを提供します。
-
RETURN RECEIPTサービスでは、サブスクライバ・レプリケーション・エージェントが更新を受信したことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、アプリケーションをレプリケーション・メカニズムと同期化します。
-
RETURN TWOSAFEサービスでは、サブスクライバが更新を受信およびコミットしたことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、完全な同期レプリケーションが可能です。
ノート:
双方向レプリケーションでRETURN TWOSAFEサービスを使用しないでください。デッドロックが発生する可能性があります。
RETURNサービスを使用するアプリケーションでは、パフォーマンスは低下しますが、マスター・データベースとサブスクライバ・データベース間でのより高いレベルの一貫性が保証され、トランザクションが失われる可能性が軽減されます。このアプリケーションでは、マスターで障害が発生した場合でも、マスターでコミットされたトランザクションがサブスクライバ・データベースに保持されることが高度なレベルで保証されます。RETURN RECEIPTのレプリケーションでは、トランザクションが失われる可能性を低くすることによって、RETURN TWOSAFEのレプリケーションよりパフォーマンスへの影響が小さくなっています。
レプリケーションのフェイルオーバーおよびリカバリ
レプリケーションで、パフォーマンスに及ぼす影響を最小限に抑えてアプリケーションのデータの可用性を高めるためには、障害のあったデータベースからそのバックアップにできるかぎりシームレスにアプリケーションを移動する方法が必要です。
TimesTen ClassicでOracle Clusterwareを使用して、アクティブ・スタンバイ・ペアがあるシステムでの障害を自動的に管理できます。その他の種類のレプリケーション・スキームを管理するには、カスタムまたはサード・パーティのクラスタ・マネージャを使用します。クラスタ・マネージャは障害を検出し、障害が発生したデータベースからスタンバイ・データベースまたはサブスクライバにユーザーまたはアプリケーションをリダイレクトし、障害が発生したデータベースのリカバリを管理します。クラスタ・マネージャまたは管理者は、TimesTenが提供するユーティリティおよび関数を使用して、障害の発生していないデータベースを複製し、障害の発生したデータベースをリカバリできます。
通常、サブスクライバの障害は、マスター・データベースに接続したアプリケーションに影響を及ぼすことはなく、ユーザー・サービスを中断させることなくリカバリできます。マスター・データベースで障害が発生した場合、サービスを中断させずに、または最小限の中断でサービスを継続するために、クラスタ・マネージャはアプリケーション負荷をスタンバイ・データベースまたはサブスクライバにリダイレクトする必要があります。
アクティブ・スタンバイ・ペアのレプリケーションの場合の自動クライアント・フェイルオーバー
クライアント/サーバー接続によるアクティブ・スタンバイ・ペアを使用するTimesTen Classicデータベースに対して、自動クライアント・フェイルオーバーを構成できます。これにより、クライアントは、スタンバイ・データベースが存在するサーバーに自動的にフェイルオーバーできます。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の自動クライアント・フェイルオーバーの使用を参照してください。