| Oracle TimesTen In-Memory Database概要
リリース7.0 E05163-01 |
|
 前へ |
 次へ |
レプリケーションとは、データベース間でデータをコピーするプロセスです。TimesTenレプリケーションの重要な目的は、パフォーマンスへの影響を最小限に抑えて、ミッション・クリティカルなアプリケーションのデータの可用性を高めることにあります。
障害リカバリにおける役割の他に、レプリケーションは、ユーザー負荷を複数のデータベースに分散してパフォーマンスを最大化させたり、「TimesTenのアップグレード」で説明するように、オンライン・アップグレードとメンテナンスを容易にする場合に有効なプロセスです。
図6.1は、TimesTenレプリケーションがマスター・データベースに対して実行された更新をサブスクライバ・データベースにコピーしていることを示しています。
効率性の向上とオーバーヘッドの低減を実現するために、TimesTenはトランザクション・ログに基づいたレプリケーション・スキームを使用します。
マスターおよびサブスクライバの各データベースのレプリケーションは、TCP/IPストリーム・ソケットを介して通信するレプリケーション・エージェントによって制御されます。マスター・データベースのレプリケーション・エージェントは、トランザクション・ログからレコードを読み取ります。レプリケートされた要素への変更をサブスクライバ・データベースのレプリケーション・エージェントに転送します。その後、サブスクライバ・データベースのレプリケーション・エージェントが、それらの更新をサブスクライバ・データベースに適用します。マスター・エージェントは、更新転送時にサブスクライバ・エージェントが稼働していない場合、サブスクライバで適用可能になるまでそれらの更新をログに保持します。
TimesTenレプリケーションは、パフォーマンスと可用性のバランスが最適になるように様々な方法で構成できます。
レプリケーションはSQL文を介して構成されます。通常、マスターから1つ以上のサブスクライバへの単方向（一方向）、またはマスターおよびサブスクライバの両方として機能する2つ以上のデータベース間の双方向（2方向）になるよう、レプリケーションを構成できます。双方向レプリケーションとして構成される2つ以上のデータベースは、N-wayまたはupdate-anywhereレプリケーションと呼ばれる場合があります。
図6.3に、ホットスタンバイ・バックアップ・データベースを実現するためのレプリケーションの構成方法を示します。アプリケーション自体に組み込まれた、適切なフェイルオーバー・メカニズムを持つサブスクライバ・データベースに、単一のマスター・データベースがレプリケートされます。
ホットスタンバイ・データベースを使用するサンプル・アプリケーションについては、「使用例1: 携帯利用者の利用状況計測アプリケーション」を参照してください。
図6.4に、ロード・バランシングの2つの構成を示します。2つの双方向レプリケーション・データベース間でワークロードを分割できます。ロード・バランス化の構成には、2つの基本タイプがあります。
分散ワークロード構成では、アプリケーションで作業を2つのシステム間で分割して、レプリケーションの衝突が発生しないようにする必要があります。衝突が発生した場合、TimesTenにはタイムスタンプ・ベースの衝突検出と問題解消の機能があります。
また、レプリケーションを使用して、1つ以上のデータベースから多数のデータベースに更新を伝播できます。これは、より低い帯域幅の接続で複製データベースを保持する場合や、マスター・データベースを多数のサブスクライバにレプリケートする必要がある構成でレプリケーション・ロードを分散させる（または放射状に広げる）場合に有効です。
図6.5に、伝播の構成を示します。
図6.6に、アクティブ・スタンバイ・ペアを示します。
アクティブ・スタンバイ・ペアには、アクティブ・マスター・データベース、スタンバイ・マスター・データベース、サブスクライバ・データベース、データベースを構成する表およびキャッシュ・グループが含まれます。
アクティブ・スタンバイ・ペアでは、2つのデータベースがマスターとして定義されます。1つは、アクティブ・マスター・データベースで、もう1つはスタンバイ・マスター・データベースです。アクティブ・マスター・データベースは直接更新されます。スタンバイ・マスター・データベースは、直接更新できません。スタンバイ・マスター・データベースは、アクティブ・マスター・データベースからの更新を受信し、それらの変更を読取り専用サブスクライバ・データベースに伝播します。この構成では、スタンバイ・マスター・データベースがサブスクライバ・データベースより常に先行し、アクティブ・マスター・データベースで障害が発生した場合は、スタンバイ・データベースに即時にフェイルオーバーできます。
1つのマスター・データベースのみが、特定の時間にアクティブ・マスター・データベースとして機能できます。アクティブ・ロールは、ttRepStateSetプロシージャを使用して指定します。アクティブ・データベースで障害が発生した場合、ユーザーは、ttRepStateSetプロシージャを使用して、障害が発生したデータベースをスタンバイ・データベースとしてリカバリする前に、スタンバイ・マスター・データベースのロールをアクティブに変更できます。新しいスタンバイ・マスター・データベースで、レプリケーション・エージェントを起動する必要があります。
スタンバイ・マスター・データベースで障害が発生した場合は、アクティブ・マスター・データベースでサブスクライバに変更を直接レプリケートできます。スタンバイ・マスター・データベースは、リカバリ後、アクティブ・マスター・データベースに接続し、スタンバイ・マスター・データベースの停止またはリカバリ中にサブスクライバに送信された更新を受信します。アクティブ・マスター・データベースとスタンバイ・マスター・データベースで同期が取られている場合、スタンバイ・マスター・データベースは、サブスクライバへの変更の伝播を再開します。
次のタイプのキャッシュ・グループのアクティブ・スタンバイ・ペアを構成することで、キャッシュ・インスタンスの高可用性を実現できます。
これらのタイプのキャッシュ・グループのいずれかをレプリケートするアクティブ・スタンバイ・ペアは、データ損失を最小限に抑えたフェイルオーバーとリカバリの一部としてキャッシュ・グループの役割を自動的に変更できます。『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のキャッシュ・グループを持つアクティブ・スタンバイ・ペアに関する項を参照してください。
TimesTenレプリケーションは、デフォルトでは非同期メカニズムになります。非同期レプリケーションを使用する場合、アプリケーションは、マスター・データベースを更新すると、サブスクライバがその更新を受信するまで待機せずに処理を続行します。マスターおよびサブスクライバのデータベースには、サブスクライバが更新を正常に受信およびコミットしたことを確認するための内部メカニズムがあります。これらのメカニズムは、更新がサブスクライバで1回のみ適用されることを保証しますが、アプリケーションでは透過的です。
非同期レプリケーションは最高のパフォーマンスを実現しますが、アプリケーションは、サブスクライバ上のレプリケートされた要素の受信プロセスと完全に切り離されます。また、TimesTenでは、レプリケートされたデータがマスター・データベースとサブスクライバ・データベース間で一貫していることをより高いレベルで保証する必要があるアプリケーションに、2つのRETURN RECEIPTサービス・オプションを提供します。
RETURNサービスを使用するアプリケーションでは、パフォーマンスは低下しますが、マスター・データベースとサブスクライバ・データベース間でのより高いレベルのデータの整合性および一貫性が保証されます。このアプリケーションでは、マスターで障害が発生した場合でも、マスターでコミットされたトランザクションがサブスクライバ・データベースに保持されることが高度なレベルで保証されます。RETURN RECEIPTのレプリケーションでは、同期性を低くすることによって、RETURN TWOSAFEのレプリケーションよりパフォーマンスへの影響が小さくなっています。
パフォーマンスに及ぼす影響を最小限に抑え、アプリケーションのデータの可用性を高めるには、できるかぎりシームレスに、障害のあったデータベースから、保持されているそのバックアップにユーザーを移動することが必要になります。
フェイルオーバーとリカバリ処理の管理は、TimesTenでは行えません。かわりに、TimesTenレプリケーションは、カスタムとサード・パーティ両方のクラスタ・マネージャと連携して動作するように設計およびテストされています。クラスタ・マネージャは、障害を検出し、ユーザーやアプリケーションを障害が発生したデータベースからそのサブスクライバの1つにリダイレクトし、障害のあったデータベースのリカバリを管理します。クラスタ・マネージャまたは管理者は、TimesTenのttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、障害の発生していないデータベースを複製し、障害の発生したデータベースをリカバリできます。
通常、サブスクライバの障害は、マスター・データベースに接続したアプリケーションに影響を及ぼすことはなく、ユーザー・サービスを中断させることなくリカバリできます。マスター・データベースで障害が発生した場合、サービスを中断させずに、または最小限の中断でサービスを継続するために、クラスタ・マネージャはアプリケーション負荷をサブスクライバにリダイレクトする必要があります。
図6.8のホットスタンバイ・スキームや図6.9の分散ワークロード・スキームのように、データベースが双方向の一般ワークロード・スキームで構成される場合、フェイルオーバーとリカバリはより効率的です。
ホットスタンバイ・スキームでは、マスター・データベースで障害が発生した場合にクラスタ・マネージャは、サブスクライバ・データベース上のホットスタンバイ・アプリケーションに、ユーザー負荷をシフトします。障害のあったデータベースのリカバリでは、マスター・データベースとサブスクライバ・データベースの役割を交替させることで、サービスの中断を最小限に抑えてレプリケーションを再開できます。
分散ワークロード・スキームを使用して構成したデータベースのフェイルオーバーの手順は、障害のあったデータベースの影響を受けたユーザーを移動して、障害が発生していないデータベース上の他のアプリケーションのユーザーに加えることを除けば、ホットスタンバイで使用する手順と類似しています。リカバリが完了すると、リカバリしたデータベース上のアプリケーションにワークロードを再分散できます。
