| Oracle® TimesTen In-Memory Database開発者および管理者ガイド 11gリリース2 (11.2.2) B66443-07 |
|
 前 |
 次 |
表がアクティブ・スタンバイ・ペアで構成されている場合は、それらの表を読取り専用キャッシュ・グループまたはASYNCHRONOUS WRITETHROUGH (AWT)キャッシュ・グループのいずれかでレプリケートできます。
次の項では、キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアの管理方法を説明します。
読取り専用キャッシュ・グループまたはASYNCHRONOUS WRITETHROUGH (AWT)キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアでは、フェイルオーバーおよびリカバリの一環としてキャッシュ・グループの役割を自動的に変更できます。これにより、データの損失を最小限に抑えてキャッシュ・インスタンスの高可用性を実現できます。「AWTキャッシュ・グループのレプリケート」および「読取り専用キャッシュ・グループのレプリケート」を参照してください。
AWTキャッシュ・グループのアクティブ・スタンバイ・レプリケーションを設定するときに、特別な障害時リカバリ読取り専用サブスクライバを作成することもできます。この特別なサブスクライバはリモートの障害時リカバリ・サイトに配置されており、(同様に障害時リカバリ・サイトに配置されている)2番目のOracle Databaseに更新を伝播できます。「アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用」を参照してください。
この項では、読取り専用キャッシュ・グループ内のキャッシュ表をレプリケートするアクティブ・スタンバイ・ペアを設定する方法について説明します。この項で例として使用するアクティブ・スタンバイ・ペアは、キャッシュ・グリッド・メンバーではありません。
データベースを作成する前に、次の項の情報を参照してください。
ローカルの読取り専用キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアを設定するには、次の手順を実行します。
Oracle Databaseでキャッシュ管理ユーザーを作成します。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseでのユーザーの作成に関する説明を参照してください。
データベースを作成します。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenデータベースでのDSNの作成に関する説明を参照してください。
ttCacheUidPwdSet組込みプロシージャをコールして、キャッシュ管理ユーザーのIDおよびパスワードを設定します。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenデータベースでのキャッシュ管理ユーザー名およびパスワードの設定に関する説明を参照してください。次に例を示します。
Command> call ttCacheUidPwdSet('orauser','orapwd');
データベースでキャッシュ・エージェントを起動します。ttCacheStart組込みプロシージャまたはttAdmin -cachestartユーティリティを使用します。
Command> call ttCacheStart;
CREATE CACHE GROUP文を使用して、読取り専用キャッシュ・グループを作成します。次に例を示します。
Command> CREATE READONLY CACHE GROUP readcache
> AUTOREFRESH INTERVAL 5 SECONDS
> FROM oratt.readtab
> (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));
AUTOREFRESH STATEがPAUSEDに設定されていることを確認します。キャッシュ・グループの作成後、デフォルトではAUTOREFRESH STATEはPAUSEDになっています。AUTOREFRESH STATEは、ttIsql cachegroupsコマンドを実行して確認できます。
Command> cachegroups;
CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション・スキームを作成します。
たとえば、master1およびmaster2がマスター・データベースとして定義され、sub1およびsub2がサブスクライバ・データベースとして定義されているとします。これらのデータベースは、node1、node2、node3およびnode4に存在しています。RETURNサービスはRETURN RECEIPTです。レプリケーション・スキームは、次のように指定できます。
Command> CREATE ACTIVE STANDBY PAIR master1 ON "node1", master2 ON "node2"
> RETURN RECEIPT
> SUBSCRIBER sub1 ON "node3", sub2 ON "node4"
> STORE master1 ON "node1" PORT 21000 TIMEOUT 30
> STORE master2 ON "node2" PORT 20000 TIMEOUT 30;
ttRepStateSet組込みプロシージャをアクティブ・データベース(master1)でコールして、レプリケーション状態をACTIVEに設定します。次に例を示します。
Command> call ttRepStateSet('ACTIVE');
master1にレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
LOAD CACHE GROUP文を使用してキャッシュ・グループをロードします。これにより、自動リフレッシュ・プロセスが開始されます。次に例を示します。
Command> LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS;
インスタンス管理者として、アクティブ・データベース(master1)をスタンバイ・データベース(master2)に複製します。-keepCGオプションを指定してttRepAdmin -duplicateユーティリティを使用し、キャッシュ・グループを保持します。ttRepDuplicateEx C関数を使用してデータベースを複製することもできます。「データベースの複製」を参照してください。ttRepAdminによって-uid、-pwd、-cacheuidおよび-cachepwdの値を入力するよう要求されます。
ttRepAdmin -duplicate -from master1 -host node1 -keepCG -connStr "DSN=master2;UID=;PWD="
master2にレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
スタンバイ・データベースは自動的にSTANDBY状態になります。master2がSTANDBY状態になるまで待機します。master2の状態を確認するには、ttRepStateGet組込みプロシージャをコールします。次に例を示します。
Command> call ttRepStateGet;
ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、master2のキャッシュ・エージェントを起動します。次に例を示します。
Command> call ttCacheStart;
インスタンス管理者として、サブスクライバ(sub1およびsub2)をスタンバイ・データベース(master2)から複製します。ttRepAdmin -duplicateで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ表を通常のTimesTen表に変換します。ttRepAdminによって-uidおよび-pwdの値を入力するよう要求されます。「データベースの複製」を参照してください。次に例を示します。
ttRepAdmin -duplicate -from master2 -host node2 -nokeepCG -connStr "DSN=sub1;UID=;PWD="
サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースのレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
グローバルAWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定方法については、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ表のレプリケートに関する説明を参照してください。その説明でのアクティブ・スタンバイ・ペアは、キャッシュ・グリッド・メンバーになっています。
アクティブ・スタンバイ・ペアでは、TimesTenのユーザー名やパスワード、または(アクティブ・スタンバイ・ペアにキャッシュ・グループが構成されている場合は)TimesTenキャッシュ・マネージャ・ユーザー、そのコンパニオンOracleユーザー、またはキャッシュ管理ユーザーのユーザー名とパスワードのいずれかを変更できます。
DDLReplicationLevel接続属性が2以上の場合は、アクティブ・マスターで行われたユーザー名やパスワードの変更がスタンバイ・マスターおよびすべてのサブスクライバに自動的にレプリケートされます。DDLReplicationLevel接続属性が1の場合、アクティブ・マスターで行われたユーザー名やパスワードの変更はスタンバイ・マスターおよびすべてのサブスクライバに自動的にレプリケートされません。この場合、アクティブ・マスター、スタンバイ・マスター、そしてすべてのサブスクライバで各SQL文を手動で実行する必要があります。
TimesTenユーザーのユーザー名やパスワード、またはアクティブ・スタンバイ・ペアにキャッシュ・グループが構成されている場合はTimesTenキャッシュ・マネージャ・ユーザー、そのコンパニオンOracleユーザー、またはキャッシュ管理ユーザーのユーザー名やパスワードを変更するには、次の手順を実行します。
TimesTenユーザーのパスワードを変更する場合は、アクティブ・マスター・データベースでALTER USER文を使用します。TimesTenユーザー名を変更する場合は、ユーザー名を削除して新しいユーザーを作成する前に、まずTimesTenユーザーが所有しているすべてのオブジェクトを削除する必要があります。
orattユーザーのパスワードを変更するには、次のコマンドを実行します。
|
注意: 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースでのユーザーの作成または指定に関する説明を参照してください。 |
Command> ALTER USER oratt IDENTIFIED BY newpwd;
キャッシュ処理に使用されるユーザー(キャッシュ管理ユーザー、キャッシュ・マネージャ・ユーザー、そのコンパニオンOracleユーザーなど)の名前やパスワードを変更する場合は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・ユーザーの名前またはパスワードの変更で説明されている手順を実行してください。
次の各項では、アクティブ・マスターに障害が発生したが、スタンバイ・データベースには障害が発生しなかったか、障害発生後にリカバリした場合に、スタンバイ・マスターを新しいアクティブ・マスターにしてアクティブ・スタンバイ・ペアをリカバリする方法について説明しています。さらに、その後アクティブ・マスターとスタンバイ・マスターを再度入れ替えて、元のノードに戻すことができます。
|
注意: アクティブ・マスターとスタンバイ・マスターの両方に障害が発生した場合のリカバリ方法については、「アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ」を参照してください。 |
最初の2つの項では、スタンバイ・データベースが使用可能で、アクティブ・データベースと同期されている場合にアクティブ・データベースをリカバリする方法について説明します。最後の項では、最初の2つの項のいずれの説明に従っても失敗し、スタンバイ・データベースは使用可能だがデータは完全に同期されていない場合の対処方法を説明します。
次のタスクを実行します。
スタンバイ・データベースで、レプリケーション・エージェントがまだ停止していない場合は、これを停止します。
スタンバイ・データベースでttRepStateSet('ACTIVE')をコールします。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。
新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')をコールします(ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです)。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。
新しいアクティブ・データベースで、レプリケーション・エージェントとキャッシュ・エージェントを起動します。
ttDestroyユーティリティを使用して、障害が発生したデータベース(古いアクティブ・マスター)を破棄します。
新しいアクティブ・データベースを新しいスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。-keepCG -recoveringNodeオプションをttRepAdminとともに使用して、アクティブ・マスターの障害からキャッシュ・グループをリカバリし、保存します。「データベースの複製」を参照してください。
新しいスタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
新しいスタンバイ・データベースでキャッシュ・エージェントを起動します。
スタンバイ・データベースは、アクティブ・データベースに通信します。アクティブ・データベースは、サブスクライバへの更新の送信を停止します。スタンバイ・データベースがアクティブ・データベースと完全に同期している場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。AWTキャッシュ・グループをレプリケートしている場合、新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。
|
注意: スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。 |
次のタスクを実行します。
スタンバイ・データベースで、レプリケーション・エージェントがまだ停止されていない場合は停止します。
スタンバイ・データベースでttRepStateSet('ACTIVE')をコールします。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。
新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')をコールします(ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです)。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。
新しいアクティブ・データベースで、レプリケーション・エージェントとキャッシュ・エージェントを起動します。
障害が発生したデータベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。データベースのリカバリが正常に行われなかったときは、レプリケーションがRETURN RECEIPTまたは非同期の場合のリカバリ方法の手順5から処理を続けてください。詳細は、「レプリケーションがRETURN RECEIPTまたは非同期の場合」を参照してください。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。
障害が発生したデータベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
障害が発生したデータベースのキャッシュ・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。
スタンバイ・データベースと完全に同期されているとアクティブ・データベースで判断された場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。AWTキャッシュ・グループをレプリケートしている場合、新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。
|
注意: スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateSet組込みプロシージャを使用して確認できます。 |
「レプリケーションがRETURN RECEIPTまたは非同期の場合」または「レプリケーションがRETURN TWOSAFEの場合」のいずれかの手順が失敗した場合は、Oracle Databaseにまだ伝播していない、非同期のデータがAWTキャッシュ・グループに存在する可能性があります。さらに、アクティブ・スタンバイ・ペアのレプリケーション・スキームに含まれているいずれの読取り専用キャッシュ・グループにもアップロードされていない非同期データがOracle Databaseに存在する可能性があります。
アクティブ・データベースに障害が発生したときにまだ伝播されていなかったデータがスタンバイ・マスターのいずれかのAWTキャッシュにある場合は、スタンバイ・データベースを新しいアクティブ・データベースとして単純にリカバリするオプションを選択することはできません。この場合、次の手順を実行します。
スタンバイ・データベースでレプリケーション・エージェントを停止し、DROP ACTIVE STANDBY PAIR文を使用してレプリケーション構成を削除します。
キャッシュ・エージェントを停止し、このリカバリ処理の実行中にこれ以上の更新がAWTキャッシュ・グループに適用されないようにし、レプリケーション・スキームに含まれていたすべての読取り専用キャッシュ・グループが更新されるときを制御できるようにします。
レプリケーション・スキームに含まれているすべての読取り専用キャッシュ・グループについて、ALTER CACHE GROUP ... SET AUTOREFRESH STATE PAUSED文を使用して、自動リフレッシュ状態をpauseに設定します。
スタンバイ・データベースで、すべてのAWTキャッシュ・グループのTimesTenキャッシュ表にある伝播されていないコミット済挿入または更新を、次のようにキャッシュ済Oracle Database表にフラッシュします。
自動コミットをオフに設定します。
パラメータを1に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールします。この組込みプロシージャにより、AWTキャッシュ・グループに対してFLUSH CACHE GROUP文を実行できます(このプロシージャはこのリカバリ・シナリオでのみ使用します)。
Command> call ttCacheAllowFlushAwtSet(1);
各AWTキャッシュ・グループに対してFLUSH CACHE GROUP SQL文を実行し、すべてのデータがOracle Databaseに伝播あれることを確認します。
|
注意: こうした条件下でAWTキャッシュ・グループに対してFLUSH CACHE GROUP文を実行すると、AWTキャッシュ・グループの表の内容のみ(つまり、挿入または更新されたデータのみ)がフラッシュされます。この際に削除処理は考慮されません。つまり、AWTキャッシュ・グループから削除された行がOracle Databaseに存在している可能性があります。削除処理をリカバリするかどうかは、ユーザーにゆだねられます。 |
パラメータを0に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールすると、AWTキャッシュ・グループに対してこれ以上のFLUSH CACHE GROUP文を実行することができなくなります。
Command> call ttCacheAllowFlushAwtSet(0);
パラメータを0に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールした後にコミットします。自動コミットはttCacheAllowFlushAwtSet組込みプロシージャの間のみオフにする必要があるので、これをオンにリセットすることもできます。
DROP CACHE GROUPおよびCREATE CACHE GROUP文を使用して、すべてのAWTキャッシュ・グループを削除および再作成します。
読取り専用キャッシュ・グループをリフレッシュするためにはキャッシュ・エージェントはアクティブになっている必要があり、また、AWTキャッシュ・グループをロードするためにはレプリケーション・エージェントとキャッシュ・エージェントの両方がアクティブになっている必要があるため、レプリケーション・エージェントとキャッシュ・エージェントを起動します。
REFRESH CACHE GROUP文を使用して読取り専用キャッシュ・グループをリフレッシュし、最新のコミット済データをキャッシュ済Oracle Database表からアップロードします。REFRESH CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。
LOAD CACHE GROUP文を使用してすべてのAWTキャッシュ・グループをロードし、自動リフレッシュ・プロセスを開始します。LOAD CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。
レプリケーション・エージェントとキャッシュ・エージェントの両方を停止し、アクティブ・スタンバイ・ペアの再作成に備えます。
スタンバイ・データベースでCREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。
古いスタンバイ・データベースを新しいアクティブ・データベースとして設定し、障害が発生した古いアクティブ・データベースを破棄し、アクティブ・データベースを複製して新しいスタンバイ・データベースを再作成してから、スタンバイでキャッシュ・エージェントとレプリケーション・エージェントを起動します(「レプリケーションがRETURN RECEIPTまたは非同期の場合」にリストした手順を参照)。
フェイルオーバーに成功した後、アクティブ・データベースおよびスタンバイ・データベースが元のノードに存在するようにフェイルバックする必要がある場合があります。詳細は、「アクティブ・データベースとスタンバイ・データベースの役割の入替え」を参照してください。
スタンバイ・データベースの障害からリカバリするには、次のタスクを実行します。
RETURN TWOSAFEサービスが有効になっている場合にスタンバイ・データベースで障害が発生すると、処理中のトランザクションはアクティブ・データベースでコミットされなくなり、エラー8170「Receipt or commit acknowledgement not returned in the specified timeout interval」が発生します。その場合は、localActionパラメータを2 (COMMIT)に設定してttRepSyncSet組込みプロシージャをコールし、トランザクションを再度コミットします。次に例を示します。
Command> call ttRepSyncSet( null, null, 2); Command> commit;
アクティブ・データベースで、ttRepStateSave('FAILED','standby_database','host_name')をコールします。このとき、スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。追加のサブスクライバ・データベースは、アクティブから直接複製することもできます。
次のいずれかの方法で、スタンバイ・データベースをリカバリします。
スタンバイ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。スタンバイ・データベースがリカバリされたら、手順4に進みますが、それ以外の場合は手順3bを続けます。
ttDestroyユーティリティを使用してスタンバイ・データベースの現行バージョンを破棄します。
アクティブ・データベースから新しいスタンバイ・データベースを複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。-keepCG -recoveringNodeオプションをttRepAdminとともに使用して、スタンバイ・マスターの障害からキャッシュ・グループをリカバリし、保存します。「データベースの複製」を参照してください。
レプリケーション・エージェント・ポリシーを設定し、スタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
スタンバイ・データベースでキャッシュ・エージェントを起動します。
アクティブ・データベースで2つのマスター・データベースが同期していると判断し、サブスクライバへの更新の送信を停止すると、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。
|
注意: スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。 |
アクティブ・データベースとスタンバイ・データベースの両方でほぼ同じ時間に障害が発生し、ほとんど即時に両方のデータベースに再接続できた場合は、レプリケーション・エージェント(と、使用可能な場合はキャッシュ・エージェント)を再起動し、続行します。
障害が発生したアクティブ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。
障害が発生したアクティブ・データベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
新しくリカバリされたデータベースで、ttRepStateSet('ACTIVE')をコールします。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。
障害が発生したデータベースのキャッシュ・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。
障害が発生したスタンバイ・マスター・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。
障害が発生したスタンバイ・データベースのレプリケーション・エージェントが再起動したことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
障害が発生したスタンバイ・データベースのキャッシュ・エージェントが再起動したことを確認します。再起動されていない場合は起動します。
または、アクティブ・マスターとスタンバイ・マスター・データベースの両方に障害が発生した場合の、次のシナリオを考えてみます。
スタンバイ・データベースで障害が発生しました。スタンバイが再起動する前、またはスタンバイがアクティブ・データベースと同期される前に、アクティブ・データベースで障害が発生しました。
アクティブ・データベースで障害が発生しました。スタンバイ・データベースがACTIVEになり、リカバリ・プロセスの残りが開始されます。(「アクティブ・データベースの障害からのリカバリ」を参照してください。)新しいスタンバイ・データベースが新しいアクティブ・データベースと完全に同期される前に、そのアクティブ・データベースで障害が発生しました。
これらのシナリオでは、スタンバイ・データベースの場合より多くの変更がサブスクライバに適用されている可能性があります。
この場合、次のいずれかのオプションを実行できる可能性があります。
障害が発生したアクティブ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。
障害が発生したアクティブ・データベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
新しくリカバリされたデータベースで、ttRepStateSet('ACTIVE')をコールします。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。
障害が発生したデータベースのキャッシュ・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。
アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。
スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。
ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。
スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。
サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
障害が発生したスタンバイ・マスター・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。
障害が発生したスタンバイ・マスターのレプリケーション・エージェントが自動的に再起動された場合は、レプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。
キャッシュ・エージェントが自動的に再起動された場合は、そのキャッシュ・エージェントを停止します。
DROP ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を削除します。
DROP CACHE GROUPおよびCREATE CACHE GROUP文を使用して、すべてのキャッシュ・グループを削除および再作成します。
CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。
マスター・データベースで、ttRepStateSet('ACTIVE')をコールして、そのデータベースにACTIVEの役割を割り当てます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。
レプリケーション・エージェント・ポリシーを設定し、新しいアクティブ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
新しいアクティブ・データベースでキャッシュ・エージェントを起動します。
アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。
スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。
ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。
スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。
サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
アクティブ・マスターとスタンバイ・マスターの両方で障害が発生し、どちらも停止したがバックアップがあった場合は、次の手順を実行します。
バックアップからアクティブ・マスターをリストアします(『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・グループによるデータベースのバックアップとリストアに関する説明を参照)。
DROP ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を削除します。
DROP CACHE GROUPおよびCREATE CACHE GROUP文を使用して、すべてのAWTキャッシュ・グループを削除および再作成します。
読取り専用キャッシュ・グループをリフレッシュするためにはキャッシュ・エージェントはアクティブになっている必要があり、また、AWTキャッシュ・グループをロードするためにはレプリケーション・エージェントとキャッシュ・エージェントの両方がアクティブになっている必要があるため、レプリケーション・エージェントとキャッシュ・エージェントを起動します。
REFRESH CACHE GROUP文を使用して読取り専用キャッシュ・グループをリフレッシュし、最新のコミット済データをキャッシュ済Oracle Database表からアップロードします。REFRESH CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。
LOAD CACHE GROUP文を使用してすべてのAWTキャッシュ・グループをロードし、自動リフレッシュ・プロセスを開始します。LOAD CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。
レプリケーション・エージェントとキャッシュ・エージェントの両方を停止し、アクティブ・スタンバイ・ペアの再作成に備えます。
CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。
アクティブ・マスター・データベースで、ttRepStateSet('ACTIVE')をコールして、そのデータベースにACTIVEの役割を割り当てます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。
レプリケーション・エージェント・ポリシーを設定し、アクティブ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
アクティブ・データベースでキャッシュ・エージェントを起動します。
アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。
スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。
ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。
スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。
サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
サブスクライバ・データベースで障害が発生した場合は、次のいずれかの方法を使用してリカバリすることができます。
障害が発生したサブスクライバに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。レプリケーション・エージェントを起動し、サブスクライバによるキャッチアップを可能にします。
スタンバイ・データベースからサブスクライバを複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。
スタンバイ・データベースが停止しているか、またはリカバリ中の場合は、アクティブ・データベースからサブスクライバを複製します。
サブスクライバ・データベースがリカバリされた後、レプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
アクティブ・データベースの役割をスタンバイ・データベースに変更する場合、およびその逆の変更を実行する場合は、次の手順を実行します。
現行のアクティブ・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
現行のスタンバイ・データベースのDSNおよびホストを入力パラメータとして使用して、アクティブ・データベースでttRepSubscriberWaitをコールします。成功すると<00>が返されます。これによって、すべての更新が現行のスタンバイ・データベースに送信されます。
現行のアクティブ・データベースでレプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。
グローバル・キャッシュ・グループが存在しない場合は、現在のアクティブ・データベースでキャッシュ・エージェントを停止します。グローバル・キャッシュ・グループが存在する場合、自動リフレッシュの状態をPAUSEDに設定します。
現在のアクティブ・データベースでttRepDeactivateをコールします。これによって、このデータベースはIDLE状態になります。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがONからPAUSEDに自動的に変更されます。
現在のスタンバイ・データベースで、ttRepStateSet('ACTIVE')をコールします。これによって、このデータベースがアクティブ・スタンバイ・ペアのアクティブ・データベースとして機能するようになります。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。
元のマスター・データベースでレプリケーション・エージェントを起動します。
必要に応じて、レプリケーション・エージェント・ポリシーを構成し、元のアクティブ・データベースでレプリケーション・エージェントを起動します。ttRepStateGet組込みプロシージャを使用して、データベースの状態がIDLEからSTANDBYに変更されたタイミングを確認します。これによって、このデータベースがアクティブ・スタンバイ・ペアのスタンバイ・データベースとして機能するようになります。
キャッシュ・エージェントが実行されていない場合は、元のアクティブ・データベースで起動します。
手順1で一時停止したアプリケーションを再開します。
「二重のアクティブ・データベースの検出」を参照してください。キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアの場合、違いはありません。
TimesTenアクティブ・スタンバイ・ペアのレプリケーションでは、データ・センター内のデータベース間の高速な切替えを可能にすることにより、高可用性が実現されます。これには、AWTキャッシュ・グループを使用してOracle Databaseに変更を伝播するデータベースを自動的に変更する機能が含まれます。ただし、データ・センター全体でのさらなる高可用性を実現するには、サイト全体の障害からリカバリ可能である必要があり、サイト全体の障害には、アクティブ・スタンバイ・ペアのTimesTenマスター・データベースおよびキャッシュ・グループに使用されるOracle Databaseの両方の障害が含まれる場合があります。
サイト全体の障害からリカバリするには、アクティブ・スタンバイ・ペアのレプリケーション・スキームの一部として、特別な障害時リカバリ読取り専用サブスクライバを作成します。スタンバイ・データベースは、読取り専用サブスクライバのキャッシュ・グループ表に更新を送信します。この特別なサブスクライバはリモートの障害時リカバリ・サイトに配置されており、(同様に障害時リカバリ・サイトに配置されている)2番目のOracle Databaseに更新を伝播できます。この障害時リカバリ・サブスクライバは、プライマリ・サイトで全体の障害が発生した場合、障害時リカバリ・サイトで新しいアクティブ・スタンバイ・ペアのアクティブとしての役割を引き継ぐことができます。この場合、すべてのアプリケーションが障害時リカバリ・サイトに接続して処理を続行でき、サービスの中断を最小限に抑えることができます。
障害時リカバリ・サブスクライバを使用する場合の要件は、次のとおりです。
プライマリ・サイトで、AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペア構成を使用していること。アクティブ・スタンバイ・ペアのレプリケーション・スキームには、読取り専用キャッシュ・グループを含めることもできます。読取り専用キャッシュ・グループは、障害時リカバリ・サブスクライバで通常の表に変換されます。AWTキャッシュ・グループ表は、障害時リカバリ・サブスクライバでAWTキャッシュ・グループ表のまま保持されます。
プライマリ・サイトから障害時リカバリ・サイトへの継続的なWAN接続があること。この接続には、少なくとも、通常量のトランザクションを障害時リカバリ・サブスクライバに適切な速度でレプリケートできる十分な帯域幅が必要です。
障害時リカバリ・サイトで、プライマリ・サイトのデータベースと同じスキーマを持つ表を含めるようにOracle Databaseが構成されていること。このデータベースは、レプリケートされた更新をプライマリ・サイトから取得することのみを目的としており、障害時リカバリ・サブスクライバの作成時にキャッシュ・グループによって書き込まれた表になんらかのデータが存在する場合、そのデータは削除されることに注意してください。
プライマリ・サイトと障害時リカバリ・サイトの両方に同じキャッシュ・グループ管理者ユーザーIDおよびパスワードがあること。
必須ではありませんが、障害時リカバリ・サイトに2番目のTimesTenデータベースを構成することをお薦めします。このデータベースは、プライマリ・サイトに障害が発生した後、障害時リカバリ・サブスクライバがアクティブ・データベースに昇格した場合、スタンバイ・データベースの役割を引き継ぐことができます。
障害時リカバリ・サブスクライバを作成するには、次の手順を実行します。
AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアをプライマリ・サイトで作成します。アクティブ・スタンバイ・ペアには、読取り専用キャッシュ・グループを含めることもできます。読取り専用キャッシュ・グループは、障害時リカバリ・サブスクライバがロール・アウトされるときに通常の表に変換されます。
-duplicateおよび-initCacheDRオプションを指定したttRepAdminユーティリティを使用し、障害時リカバリ・サイトで障害時リカバリ・サブスクライバを作成します。また、-cacheUidおよび-cachePwdオプションを使用して、障害時リカバリ・サイトでOracle Databaseのキャッシュ・グループ管理者およびパスワードを指定する必要もあります。
データベースに複数のキャッシュ・グループが含まれている場合、-nThreadsオプションを使用して、キャッシュ・グループを並行してフラッシュするために生成されるスレッドの数を指定することにより、複製処理の効率を向上させることができます。各スレッドはキャッシュ・グループ全体をOracle Databaseにフラッシュし、フラッシュするキャッシュ・グループが残っている場合は、次のキャッシュ・グループに進みます。-nThreadの値が指定されていない場合は、1つのフラッシュ・スレッドのみが生成されます。
たとえば、ホスト名primary、キャッシュ・ユーザーID system、パスワードmanagerのシステムで、スタンバイ・データベースmast2を障害時リカバリ・サブスクライバdrsubに複製し、2つのキャッシュ・グループ・フラッシュ・スレッドを使用するとします。ttRepAdminによって-uid、-pwd、-cacheUidおよび-cachePwdの値を入力するよう要求されます。
ttRepAdmin -duplicate -from mast2 -host primary -initCacheDR -nThreads 2 -connStr "DSN=drsub;UID=;PWD=;"
CでttRepDuplicateEx関数を使用する場合は、ttRepDuplicateExArg.flagsにTT_REPDUP_INITCACHEDRフラグを設定する必要があり、オプションで、ttRepDuplicateExArg.nThreads4InitDRの値を指定できます。
int rc;
ttUtilHandle utilHandle;
ttRepDuplicateExArg arg;
memset( &arg, 0, sizeof( arg ) );
arg.size = sizeof( ttRepDuplicateExArg );
arg.flags = TT_REPDUP_INITCACHEDR;
arg.nThreads4InitDR = 2;
arg.uid="ttuser"
arg.pwd="ttuser"
arg.cacheuid = "system";
arg.cachepwd = "manager";
arg.localHost = "disaster";
rc = ttRepDuplicateEx( utilHandle, "DSN=drsub",
"mast2", "primary", &arg );
サブスクライバが複製されると、TimesTenでは、AWTキャッシュ・グループからOracle Databaseに更新を伝播し、TimesTenのキャッシュ・グループに対応するOracle Databaseの表を切り捨て、キャッシュ・グループのすべてのデータをOracle Databaseにフラッシュするレプリケーション・スキームが自動的に構成されます。
障害時リカバリ・サブスクライバに障害しきい値を設定する場合は、ttCacheAWTThresholdSet組込みプロシージャをコールし、障害時リカバリ・サブスクライバが停止しているか、またはキャッチアップに時間がかかりすぎているとみなされる前に累積可能なトランザクション・ログ・ファイルの数を指定します。
障害時リカバリ・サブスクライバが作成される前に、一方または両方のマスター・データベースに障害しきい値が構成されている場合、障害時リカバリ・サブスクライバはttRepAdmin -duplicate -initCacheDRコマンドで作成されたときに障害しきい値の値を引き継ぎます。これらのマスター・データベースの障害しきい値が異なる場合は、大きい方の値が障害時リカバリ・サブスクライバに使用されます。
障害しきい値の詳細は、「トランザクション・ログ障害しきい値の設定」を参照してください。
障害時リカバリ・サブスクライバのレプリケーション・エージェントを起動するには、ttRepStart組込みプロシージャまたは-repstartオプションを指定したttAdminユーティリティを使用します。次に例を示します。
ttAdmin -repstart drsub
スタンバイ・データベースから障害時リカバリ・サブスクライバに更新がレプリケートされます。この後、これらの更新は、障害時リカバリ・サブスクライバによって障害時リカバリ・サイトのOracle Databaseに伝播されます。
プライマリ・サイトに障害が発生した場合は、2つのうちいずれかの方法で障害時リカバリ・サイトに切り替えることができます。障害時リカバリ・サイトでのデータ損失を最小限に抑えることが目的である場合は、障害時リカバリ・サブスクライバをアクティブ・データベースとして使用し、新しいアクティブ・スタンバイ・ペアをロール・アウトします。障害時リカバリ・データベースに後で障害が発生してデータが失われる可能性があっても、アプリケーションの停止時間を最小限に抑えることが目的である場合は、障害時リカバリ・サブスクライバからレプリケーション・スキームを削除し、単一の非レプリケート・データベースとして使用することを選択できます。後でアクティブ・スタンバイ・ペアを障害時リカバリ・サイトにデプロイできます。
読取り専用アプリケーションは、障害時リカバリ・サブスクライバにすぐにリダイレクトできます。データベースに対して更新を行うアプリケーションのリダイレクトは、手順7で実行します。
ttRepSubscriberWait組込みプロシージャまたは-waitオプションを指定したttRepAdminコマンドを使用して、キャッシュ・グループへの新しい更新がすべてOracle Databaseに伝播されていることを確認します。
Command> call ttRepSubscriberWait( null, null, '_ORACLE', null, 600 );
成功すると<00>が返されます。ttRepSubscriberWaitでタイムアウトを示す0x01が返されたら、手順3に進む前に、キャッシュ・グループによる伝播が完了していない原因を調べて特定します。
障害時リカバリ・サブスクライバのレプリケーション・エージェントを停止するには、ttRepStop組込みプロシージャまたは-repstopオプションを指定したttAdminコマンドを使用します。たとえば、サブスクライバdrsubのレプリケーション・エージェントを停止するには、次のように入力します。
Command> call ttRepStop;
DROP ACTIVE STANDBY PAIR文を使用して、サブスクライバのアクティブ・スタンバイ・ペアのレプリケーション・スキームを削除します。次に例を示します。
Command> DROP ACTIVE STANDBY PAIR;
障害時リカバリ・サブスクライバ上に、アクティブ・データベースの読取り専用キャッシュ・グループ表から変換された表が存在する場合、障害時リカバリ・サブスクライバでそれらの表を削除します。
障害時リカバリ・サブスクライバで読取り専用キャッシュ・グループを作成します。AUTOREFRESH STATEがPAUSEDに設定されていることを確認します。
CREATE ACTIVE STANDBY PAIR文を使用し、新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成し、障害時リカバリ・サブスクライバをアクティブ・データベースとして指定します。たとえば、前のサブスクライバdrsubをアクティブ・データベースとして使用し、新しいデータベースdrstandbyをスタンバイ・データベースとして使用する新しいアクティブ・スタンバイ・ペアを作成し、RETURN TWOSAFE戻りサービスを使用するには、次のように入力します。
Command> CREATE ACTIVE STANDBY PAIR drsub, drstandby RETURN TWOSAFE;
ttRepStateSet組込みプロシージャを使用して、新しいアクティブ・スタンバイ・データベースを、ACTIVEステータスに設定します。たとえば、この例のデータベースdrsubで次のようにコールします。
Command> call ttRepStateSet( 'ACTIVE' );
TimesTenデータベースへの書込みを必要とするすべてのアプリケーションが、新しいアクティブ・データベースにリダイレクトされるようになりました。
読取り専用キャッシュ・グループをレプリケートしている場合は、LOAD CACHE GROUP文を使用してキャッシュ・グループをロードし、自動リフレッシュ・プロセスを開始します。AWTキャッシュ・グループをレプリケートしている場合も、キャッシュ・グループをロードできます(必須ではありません)。
アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。
スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。
ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。
スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。
サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。
読取り専用アプリケーションは、障害時リカバリ・サブスクライバにすぐにリダイレクトできます。データベースに対して更新を行うアプリケーションのリダイレクトは、手順5で実行します。
障害時リカバリ・サブスクライバのレプリケーション・エージェントを停止するには、ttRepStop組込みプロシージャまたは-repstopオプションを指定したttAdminコマンドを使用します。たとえば、サブスクライバdrsubのレプリケーション・エージェントを停止するには、次のように入力します。
Command> call ttRepStop;
DROP ACTIVE STANDBY PAIR文を使用して、サブスクライバのアクティブ・スタンバイ・ペアのレプリケーション・スキームを削除します。次に例を示します。
Command> DROP ACTIVE STANDBY PAIR;
障害時リカバリ・サブスクライバ上に、アクティブ・データベースの読取り専用キャッシュ・グループ表から変換された表が存在する場合、障害時リカバリ・サブスクライバでそれらの表を削除します。
障害時リカバリ・サブスクライバで読取り専用キャッシュ・グループを作成します。
構成済のアクティブ・スタンバイ・ペアはなくなりましたが、AWTキャッシュ・グループでは、レプリケーション・エージェントの起動を必要とします。ttRepStart組込みプロシージャまたは-repstartオプションを指定したttAdminコマンドを使用して、データベースでレプリケーション・エージェントを起動します。たとえば、データベースdrsubのレプリケーション・エージェントを起動するには、次のように入力します。
Command> call ttRepStart;
TimesTenデータベースへの書込みを必要とするすべてのアプリケーションが、このデータベースにリダイレクトされるようになりました。
|
注意: アクティブ・スタンバイ・ペアは、後から障害時リカバリ・サイトでロール・アウトできます。これを行うには、「障害時リカバリ・サイトへの切替え後の新しいアクティブ・スタンバイ・ペアの作成」の手順に従い、手順2から開始し、手順4は省略してください。 |
プライマリ・サイトが再び使用可能になったときに、稼働中のアクティブ・スタンバイ・ペアを障害時リカバリ・サイトからプライマリ・サイトに戻す場合があります。元の障害時リカバリ・サイトの作成および切替えに使用したプロセスを逆順で行うと、サービスの中断を最小限に抑えながらこの処理を行うことができます。次の手順を実行します。
必要に応じてttDestroyユーティリティを使用して、プライマリ・サイトで元のアクティブ・データベースを破棄します。たとえば、mast1というデータベースを破棄するには、次のように入力します。
ttDestroy mast1
「障害時リカバリ・サブスクライバのローリング・アウト」の手順に従って、プライマリ・サイトで障害時リカバリ・サブスクライバを作成します。元のアクティブ・データベースを新しい障害時リカバリ・サブスクライバに対して使用します。
「障害時リカバリ・サイトへの切替え」の説明に従って、プライマリ・サイトで新しい障害時リカバリ・サブスクライバに切り替えます。スタンバイ・データベースもロール・アウトします。
「障害時リカバリ・サブスクライバのローリング・アウト」の説明に従って、障害時リカバリ・サイトで新しい障害時リカバリ・サブスクライバをロール・アウトします。
