表がアクティブ・スタンバイ・ペアで構成されている場合は、それらの表を読取り専用キャッシュ・グループまたは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
「障害時リカバリ・サブスクライバのローリング・アウト」の手順に従って、プライマリ・サイトで障害時リカバリ・サブスクライバを作成します。元のアクティブ・データベースを新しい障害時リカバリ・サブスクライバに対して使用します。
「障害時リカバリ・サイトへの切替え」の説明に従って、プライマリ・サイトで新しい障害時リカバリ・サブスクライバに切り替えます。スタンバイ・データベースもロール・アウトします。
「障害時リカバリ・サブスクライバのローリング・アウト」の説明に従って、障害時リカバリ・サイトで新しい障害時リカバリ・サブスクライバをロール・アウトします。