アクティブ・データベースの障害からのリカバリ

アクティブ・マスターに障害が発生し、スタンバイ・データベースは障害が発生していないか障害発生後にリカバリされている場合は、スタンバイ・マスターを新しいアクティブ・マスターにすることでアクティブ・スタンバイ・ペアをリカバリできます。

さらに、その後アクティブ・マスターとスタンバイ・マスターを再度入れ替えて、元のノードに戻すことができます。

ノート:

アクティブ・マスターとスタンバイ・マスターの両方に障害が発生した場合は、「アクティブ・データベースとスタンバイ・データベースの二重の障害からのリカバリ」を参照してください。

スタンバイ・データベースが使用可能な場合のリカバリ

最初の2つの項では、スタンバイ・データベースが使用可能で、アクティブ・データベースと同期されている場合にアクティブ・データベースをリカバリする方法について説明します。最後の項では、最初の2つの項のいずれの説明に従っても失敗し、スタンバイ・データベースは使用可能だがデータは完全に同期されていない場合の対処方法を説明します。

レプリケーションがRETURN RECEIPTまたは非同期の場合

アクティブ・データベースで障害が発生した場合は、スタンバイ・データベースにフェイルオーバーできます。

次のタスクを実行します。

スタンバイ・データベースで、レプリケーション・エージェントがまだ停止していない場合は、これを停止します。
スタンバイ・データベースで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組込みプロシージャを使用して確認できます。

レプリケーションがRETURN TWOSAFEの場合

アクティブ・データベースで障害が発生した場合は、スタンバイ・データベースにフェイルオーバーできます。

次のタスクを実行します。

スタンバイ・データベースで、レプリケーション・エージェントがまだ停止されていない場合は停止します。
スタンバイ・データベースで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状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。

同期されていないデータがキャッシュ・グループ内にある場合

アクティブ・データベースに障害が発生したときは、キャッシュ・グループ内に同期されていないデータがある場合でも、スタンバイ・データベースにフェイルオーバーできます。

「レプリケーションがRETURN RECEIPTまたは非同期の場合」または「レプリケーションがRETURN TWOSAFEの場合」のどちらかの手順で失敗した場合は、Oracleデータベースに伝播されていない、同期されていないデータがAWTキャッシュ・グループ内に存在する可能性があります。さらに、アクティブ・スタンバイ・ペアのレプリケーション・スキームに含まれているいずれの読取り専用キャッシュ・グループにもアップロードされていない非同期データがOracle Databaseに存在する可能性があります。

アクティブ・データベースに障害が発生したときにまだ伝播されていなかったデータがスタンバイ・マスターのいずれかのAWTキャッシュにある場合は、スタンバイ・データベースを新しいアクティブ・データベースとして単純にリカバリするオプションを選択することはできません。この場合、次の手順を実行します。

スタンバイ・データベースでレプリケーション・エージェントを停止し、DROP ACTIVE STANDBY PAIR文を使用してレプリケーション構成を削除します。
キャッシュ・エージェントを停止し、このリカバリ処理の実行中にこれ以上の更新がAWTキャッシュ・グループに適用されないようにし、レプリケーション・スキームに含まれていたすべての読取り専用キャッシュ・グループが更新されるときを制御できるようにします。
レプリケーション・スキームに含まれているすべての読取り専用キャッシュ・グループについて、ALTER CACHE GROUP ... SET AUTOREFRESH STATE PAUSED文を使用して、自動リフレッシュ状態をpauseに設定します。
スタンバイ・データベースで、すべてのAWTキャッシュ・グループのTimesTenキャッシュ表にある伝播されていないコミット済挿入または更新を、次のようにキャッシュ済Oracle Database表にフラッシュします。
1. 自動コミットをオフに設定します。
2. パラメータを1に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールします。この組込みプロシージャにより、AWTキャッシュ・グループに対してFLUSH CACHE GROUP文を実行できます(このプロシージャはこのリカバリ・シナリオでのみ使用します)。
```
call ttCacheAllowFlushAwtSet(1);
```
3. 各AWTキャッシュ・グループに対してFLUSH CACHE GROUP SQL文を実行し、すべてのデータがOracleデータベースに伝播されることを確認します。
  
  ノート:
  
  こうした条件下でAWTキャッシュ・グループに対してFLUSH CACHE GROUP文を実行すると、AWTキャッシュ・グループの表の内容のみ(つまり、挿入または更新されたデータのみ)がフラッシュされます。この際に削除処理は考慮されません。つまり、AWTキャッシュ・グループから削除された行がOracle Databaseに存在している可能性があります。削除処理をリカバリするかどうかは、ユーザーにゆだねられます。
4. パラメータを0に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールして、AWTキャッシュ・グループでのFLUSH CACHE GROUP文の今後の実行を禁止します。
```
call ttCacheAllowFlushAwtSet(0);
```
5. パラメータを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または非同期の場合」で示した手順を参照)。

元のノードへのフェイルバック

フェイルオーバーに成功した後、アクティブ・データベースおよびスタンバイ・データベースが元のノードに存在するようにフェイルバックする必要がある場合があります。

「アクティブ・データベースとスタンバイ・データベースの役割の入替え」を参照してください。