| Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド
リリース7.0 E05169-02 |
|
 前へ |
 次へ |
『Oracle TimesTen Cache Connect to Oracle開発者および管理者ガイド』で説明されているように、キャッシュ・グループとは、中央のOracleデータベースに保存されている表のグループが、ローカルのTimesTenデータ・ストアにキャッシュされたものです。この項では、TimesTenデータ・ストア間でキャッシュ・グループをレプリケートする方法について説明します。推奨されるキャッシュ・グループのレプリケート方法は、障害が発生した場合のリカバリを簡略化する機能を持つ、アクティブ・スタンバイ・ペアのレプリケーション・スキームを使用する方法です。高可用性を目的としてキャッシュ・グループをレプリケートするこの方法については、「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペア」を参照してください。リカバリ可能性が低いその他のキャッシュ・グループのレプリケート方法の詳細は、「キャッシュ・グループのレプリケート」を参照してください。
この項で説明するキャッシュ・グループのほとんどのレプリケーション例では、特に説明がないかぎり、Oracleデータベースが実行されているデータベース・サーバーが1つ、TimesTenデータ・ストアがホスティングされているアプリケーション・サーバーが2つ（AおよびB）あると想定しています。AおよびB上のTimesTenデータ・ストアは、Oracleデータベース内の同じ表のサブセットをキャッシュしています。
この項では、キャッシュ・グループをレプリケートする次の5つの例について説明します。
また、この項では、キャッシュ・グループのエージングがレプリケーションに与える影響についても説明します。
データ・ストアAのキャッシュ・グループとデータ・ストアBの表には、Oracleに保存されている同じカタログ情報の同一のサブセットが含まれている必要があります。この情報は4時間ごとに変更されます。
図1.14に示すように、READONLYキャッシュ・グループをデータ・ストアAに作成し、同一の列定義を持つ通常の表をデータ・ストアBに作成できます。データ・ストアAのキャッシュ・グループにカタログ情報をキャッシュし、Aのキャッシュ・グループからBの表への単方向レプリケーションを設定できます。その後、カタログ情報が4時間ごとにリフレッシュされるように、データ・ストアAのキャッシュ・グループのAUTOREFRESH INTERVAL値を設定します。
この構成は、アプリケーションのロードを複数のデータ・ストアに分散させる場合に役立つ可能性がありますが、データ・ストアAで障害が発生した場合、リカバリに時間がかかります。すべてのデータ・ストアを再作成して、中央のデータベースに格納されているカタログ情報に同期させる必要があるためです。
データ・ストアAのキャッシュ・グループとデータ・ストアBの表には、Oracleに保存されている同じカタログ情報の同一のサブセットが含まれている必要があります。この情報は4時間ごとに変更されます。また、データ・ストアAで障害が発生した場合にデータ・ストアBでデータ・ストアAの処理を引き継ぐことができる必要があります。
図1.15に示すように、アクティブ・スタンバイ・ペアのロールアウト手順を実行した後、データ・ストアAとBの両方にREADONLYキャッシュ・グループを作成できます。アクティブ・スタンバイ・ペアにおいて、データ・ストアAはアクティブ・マスター・データ・ストアとして、データ・ストアBはスタンバイ・マスター・データ・ストアとして動作します。アクティブ・スタンバイ・ペアによって、カタログ情報をデータ・ストアAのキャッシュ・グループにキャッシュして、Aのキャッシュ・グループとBのキャッシュ・グループの間に双方向レプリケーションを設定できます。その後、4時間ごとにカタログ情報がリフレッシュされるように、AUTOREFRESH INTERVAL値を設定できます。ただし、データ・ストアBのキャッシュ・グループでは、アクティブ・スタンバイ・ペアのロールアウト手順の一部として、AUTOREFRESHが自動的にPAUSED状態に設定されるため、データ・ストアAのキャッシュ・グループのみがAUTOREFRESHメカニズムによって更新されます。カタログ情報に対する更新がデータ・ストアAのキャッシュ・グループに自動リフレッシュされると、それらの更新はレプリケーションによってBのキャッシュ・グループに自動的に転送されます。また、必要なブックキーピング情報もこのレプリケーションによって転送され、データ・ストアAで障害が発生した場合に自動リフレッシュされるキャッシュ・グループとしての役割をBのキャッシュ・グループで引き継ぐことが可能になります。
データ・ストアAで障害が発生すると、データ・ストアBは即時にアクティブ・スタンバイ・ペアのアクティブ・マスター・データ・ストアとして再構成されます。これによってデータ・ストアBのキャッシュ・グループのAUTOREFRESH構成が自動的にON状態に設定され、自動リフレッシュされるキャッシュ・グループとしての役割をデータ・ストアBで引き継ぐことができます。この構成によって、データ・ストアの可用性が中断される時間を最小限に抑えて、データ・ストアの障害からの迅速なリカバリが可能になります。
データ・ストアAとデータ・ストアBのキャッシュ・グループには、同じOracleインスタンスの同一のサブセット（顧客プロファイル）が含まれている必要があります。顧客プロファイルは、いずれのデータ・ストアでも問合せが行われます。プロファイルは、TimesTenでは更新される場合がありますが、Oracleでは更新されません。更新される場合、アメリカの東部および中部の顧客はデータ・ストアAのキャッシュ・グループで更新され、西部およびアラスカ/ハワイの顧客はデータ・ストアBで更新されます。
図1.16に示すように、データ・ストアAとBには同等のSYNCHRONOUS WRITETHROUGHまたはASYNCHRONOUS WRITETHROUGHキャッシュ・グループを作成できます。このキャッシュ・グループでは、キャッシュ・グループに対する更新が自動的にOracleに送信されます。2つのキャッシュ・グループ間には、一般ワークロードの双方向レプリケーションを設定できます。このスキームでは、Aのキャッシュ・グループに対する更新は、自動的にOracleに適用され、Bにレプリケートされます。同様に、Bのキャッシュ・グループに対する更新は、自動的にOracleに適用され、Aにレプリケートされます。
| 注意: | レプリケートされた情報はOracleには伝播されません。したがって、データ・ストアAのキャッシュ・グループに対する更新は、データ・ストアBにはレプリケートされますが、BからOracleには伝播されません。 |
詳細は、「キャッシュ・グループのレプリケート」を参照してください。
Oracle内の同じ顧客プロファイル・インスタンスの同一サブセットを複数個キャッシュする必要があります。このプロファイルは、TimesTenでは更新される場合がありますが、Oracleでは更新されません。また、TimesTenに接続しているアプリケーションで頻繁に読み取られます。さらに、停止時間をほとんど発生させずに、構成全体を堅牢にする必要があります。
図1.17に示すように、アクティブ・スタンバイ・ペアのロールアウト手順を実行した後、データ・ストアAとBの両方にASYNCHRONOUS WRITETHROUGHキャッシュ・グループを作成できます。データ・ストアAおよびBのキャッシュ・グループは相互にレプリケートされるとともに、データ・ストアCおよびDの標準の表にもレプリケートされます。アプリケーションの読取りは、読取り専用サブスクライバであるデータ・ストアCおよびDに分散され、アプリケーションの更新は、アクティブ・マスターであるデータ・ストアAに対して加えられます。データ・ストアAに加えた更新は、双方向レプリケーションによってスタンバイ・マスターであるデータ・ストアBに自動的にレプリケートされた後、データ・ストアBからOracleデータベースに転送され、データ・ストアCおよびDにレプリケートされます。データ・ストアBがスタンバイ・マスターの間は、データ・ストアBを直接更新することはできないことに注意してください。
アクティブまたはスタンバイのいずれかのマスター・データ・ストアに障害が発生した場合は、障害が発生したデータ・ストアがリカバリされるまで、残りのマスター・データ・ストアが、通常の役割に加えて、障害が発生したデータ・ストアの役割を引き継ぎます。たとえば、データ・ストアAに障害が発生した場合、データ・ストアBはアプリケーションの更新を受け入れるとともに、継続してそれらの更新をOracleデータベースに転送し、データ・ストアCおよびDにレプリケートします。
読取り専用のサブスクライバ・データ・ストアで障害が発生した場合は、そのデータ・ストアをスタンバイ・マスター・データ・ストアから再作成できます。その処理の間は、障害が発生していない読取り専用サブスクライバ・データ・ストアで、すべてのアプリケーションの読取りが行われます。たとえば、データ・ストアCで障害が発生した場合、データ・ストアCをデータ・ストアBから再作成している間、アプリケーションの読取りをデータ・ストアDで継続して行うことができます。
詳細は、「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペア」を参照してください。
データ・ストアAとBのキャッシュ・グループに、同じOracleインスタンスの同一のサブセット（ショッピング・カート情報）を含めます。ショッピング・アプリケーションは、TimesTenにキャッシュされたデータに対して挿入、削除、更新を行います。このキャッシュ・されたデータは、最終的にOracleにフラッシュされます。
図1.18に、一般ワークロードの双方向レプリケーションを使用した同じUSERMANAGEDキャッシュ・グループを示します。
同じUSERMANAGEDキャッシュ・グループを作成して、ショッピング・カート情報を保持できます。2つのキャッシュ・グループ間に一般ワークロードの双方向レプリケーションを設定し、TimesTenからOracleへの更新の自動伝播を無効にします。いずれかのキャッシュ・グループに対する挿入、削除、更新のみでなく、新しいショッピング・カートの作成も他方に自動的にレプリケートされます。2つのキャッシュ・グループには、ユーザーのショッピング・カートの同一コピーが常に含まれているため、ショッピング・アプリケーションでいずれのデータ・ストアにもアクセスできます。ユーザーがいずれかのキャッシュ・グループに発注すると、アプリケーションによって、FLUSH CACHE GROUPリクエストが発行され、ショッピング・カートの内容がOracleに送信されます。
キャッシュ・グループに最低使用頻度（LRU）または時間ベースのエージングのいずれかが構成されている場合は、レプリケーションの実行に次のルールが適用されます。
| 注意: | レプリケート表のエージング設定は、すべてのピア・データ・ストアで同じにする必要があります。この制限は、レプリケート表がアクティブ・スタンバイ・ペアの一部である場合にも適用されます。エージングによって表が更新された場合、その更新内容はアクティブ・スタンバイ・ペアのスタンバイ・データ・ストアにレプリケートされますが、エージング設定をアクティブとスタンバイの両方のデータ・ストアでONにしておく必要があります。TimesTenでは、データ・ストアの役割がアクティブかスタンバイかに基づいて、実際にエージングを実行しているデータ・ストアが自動的に判別されます。 |
