障害からのリカバリ

Oracle Clusterwareが構成されている場合のTimesTenによるリカバリの実行方法

TimesTenデータベース・モニター(ttCRSmasterプロセス)がリカバリを実行します。

forceconnectオプションを使用せずに、障害の発生したデータベースへの接続を試行します。エラー994 ("Data store connection terminated")で接続に失敗した場合、データベース・モニターは再接続を10回試行します。エラー707 ("Attempt to connect to a data store that has been manually unloaded from RAM")で接続に失敗した場合、データベース・モニターはRAMポリシーを変更して接続を再試行します。データベース・モニターは、接続できない場合、接続障害エラーを返します。

データベース・モニターがデータベースに接続できた場合、次のタスクが実行されます。

TTREP.REPLICATIONSレプリケーション表のCHECKSUM列を問い合せます。
CHECKSUM列の値がOracle Cluster Registryに保存されているチェックサムと一致する場合は、データベース・モニターはデータベースのロールを確認します。役割がACTIVEの場合、リカバリは完了です。

役割がACTIVEでない場合、データベース・モニターは、ローカル・データベースのレプリケーションのコミット・チケット番号(CTN)とアクティブ・データベースのCTNを問い合せて、レプリケートされていないトランザクションがあるかどうかを確認します。すべてのトランザクションがレプリケートされていれば、リカバリは完了です。
チェックサムが一致しなかった場合、または一部のトランザクションがレプリケートされていない場合には、データベース・モニターはリモート・データベースから複製操作を実行し、ローカル・データベースを再作成します。

エラー8110または8111(マスター・キャッチアップが必要またはマスター・キャッチアップを実行中)により、データベース・モニターがデータベースへの接続に失敗した場合、forceconnect=1オプションを使用して接続を行い、マスター・キャッチアップを開始します。マスター・キャッチアップが完了すると、リカバリは完了です。エラー8112 ("Operation not permitted")によりマスター・キャッチアップが失敗した場合、データベース・モニターはリモート・データベースから複製操作を実行します。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。

その他のエラーにより接続に失敗した場合には、データベース・モニターはリモート・データベースから複製操作の実行を試みます。

複製操作では、次のことを確認します。

リモート・データベースが使用できる。
レプリケーション・エージェントが稼働している。
リモート・データベースに適切なロールが設定されている。スタンバイ・データベースの作成のために複製操作が試行される場合、役割はACTIVEに設定されている必要があります。読取り専用サブスクライバの作成のために複製操作が試行される場合、役割はSTANDBYまたはACTIVEに設定されている必要があります。

複製操作の条件が満たされている場合は、障害が発生した既存のデータベースは破棄され、複製操作が開始されます。

アクティブ・データベースまたはそのホストで障害が発生した場合

アクティブ・データベースが存在するノードで障害が発生した場合、Oracle Clusterwareでは、スタンバイ・データベースの状態が自動的にACTIVEに変更されます。アプリケーション・フェイルオーバーが構成されている場合は、アプリケーションによって新しいアクティブ・データベースの更新が開始されます。

図8-2では、スタンバイ・データベースの状態がACTIVEに変更され、アプリケーションによって新しいアクティブ・データベースが更新されています。

図8-2 スタンバイ・データベースがアクティブ状態になった場合

「図8-2 スタンバイ・データベースがアクティブ状態になった場合」の説明

Oracle Clusterwareによって、障害が発生したデータベースまたはホストの再起動が試行されます。成功すると、そのデータベースがスタンバイ・データベースになります。

図8-3に、前のアクティブ・マスターがスタンバイ・マスターになったクラスタを示します。

図8-3 前のアクティブ・ホストで起動したスタンバイ・データベース

「図8-3 前のアクティブ・ホストで起動したスタンバイ・データベース」の説明

前のアクティブ・マスターの障害が永続的であり、高度な可用性が構成されている場合は、Oracle Clusterwareでは追加のノードの1つでスタンバイ・マスターが起動されます。

図8-4に、追加のノードの1つでスタンバイ・マスターが起動されたクラスタを示します。

図8-4 追加のホストで起動されたスタンバイ・データベース

「図8-4 追加のホストで起動されたスタンバイ・データベース」の説明

これらの自動アクションが実行されるまで待機しない場合は、「アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行」を参照してください。

スタンバイ・データベースまたはそのホストで障害が発生した場合

スタンバイ・マスターで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。スタンバイ・マスターを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでスタンバイ・マスターが起動されます。

図8-5に、追加のノードの1つでスタンバイ・マスターが起動されたクラスタを示します。

図8-5 新しいホストのスタンバイ・データベース

「図8-5 新しいホストのスタンバイ・データベース」の説明

読取り専用サブスクライバまたはそのホストで障害が発生した場合

サブスクライバ・ノードで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。データベースを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでサブスクライバ・データベースが起動されます。

両方のマスター・ノードで障害が発生した場合

両方のマスター・ノードで障害が発生した場合の自動および手動でのリカバリ方法を説明します。

この項の内容は次のとおりです。

自動リカバリ

Oracle Clusterwareでは、両方のマスター・ノードで一時的な障害が発生し、それらのノードが復旧された後に、自動リカバリを実行できます。

次の場合に自動リカバリを実行できます:

アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。

Oracle Clusterwareでは、次のような場合に、両方のマスター・ノードで発生した永続的な障害からの自動リカバリを実行できます。

高度な可用性(仮想IPアドレスおよび少なくとも4つのホスト)が構成されている。
アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートしていない。
アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。

cluster.oracle.iniファイルの例は、「両方のマスター・ノードに恒久的な障害が発生した場合のリカバリの構成」を参照してください。

高度な可用性の場合の手動リカバリ

この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。

次のステップでは、例としてmanrecoveryDSNデータベースおよびcluster.oracle.iniファイルを使用します。

高度な可用性構成で手動リカバリを実行するには、次の手順を実行します。

TimesTenクラスタ・エージェント(ttCRSAgent)がローカル・ホストで実行されていることを確認します。
```
ttCWAdmin -init -hosts localhost
```
バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。
```
ttCWAdmin -restore -dsn manrecoveryDSN
```
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
新しいホストがcluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsで指定されていない場合、新しいホストが含まれるようにファイルを変更します。

このステップでは、manrecoveryDSNを使用します。cluster.oracle.iniファイルにはすでに追加のホストが指定されているため、manrecoveryDSNにはこのステップは必要はありません。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
```
ttCWAdmin -create -dsn manrecoveryDSN
```
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
```
ttCWAdmin -start -dsn manrecoveryDSN
```

基本的な可用性の場合の手動リカバリ

この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。

次のステップでは、例としてbasicDSNデータベースおよびcluster.oracle.iniファイルを使用します。

基本的な可用性構成で手動リカバリを実行するには、次のステップを実行します。

アクティブ・スタンバイ・ペアのデータベース用に新しいホストを取得します。
TimesTenクラスタ・エージェント(ttCRSAgent)がローカル・ホストで実行されていることを確認します。
```
ttCWAdmin -init -hosts localhost
```
バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。
```
ttCWAdmin -restore -dsn basicDSN
```
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。この例では、basicDSNデータベースを使用します。MasterHostsエントリはhost1からhost10に変更されます。SubscriberHostsエントリはhost2からhost20に変更されます。
```
[basicDSN]
MasterHosts=host10,host20
```
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
```
ttCWAdmin -create -dsn basicDSN
```
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
```
ttCWAdmin -start -dsn basicDSN
```

データベースが破損した場合の同じマスター・ノードへの手動リカバリ

両方のマスター・ノードで障害が発生し、データベースが破損する場合があります。同じマスター・ノードにリカバリできます。

同じマスター・ノードにリカバリするには、次の手順を実行します:

TimesTenデーモン・モニター(ttCRSmaster)、レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。この例では、basicDSNデータベースを使用します。
```
ttCWAdmin -stop -dsn basicDSN
```
ttDestroyユーティリティを使用し、新しいアクティブ・データベースを配置するノードでデータベースを破棄します。
```
ttDestroy basicDSN
```
バックアップ・データベースをリストアします。
```
ttCWAdmin -restore -dsn basicDSN
```
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
```
ttCWAdmin -create -dsn basicDSN
```
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
```
ttCWAdmin -start -dsn basicDSN
```

RETURN TWOSAFEが構成されている場合の手動リカバリ

RETURNサービスがRETURN TWOSAFEになるようにアクティブ・スタンバイ・ペアを構成できます。

RETURN TWOSAFEを構成するには、cluster.oracle.iniファイル内のReturnServiceAttributeクラスタウェア属性を使用します。

次のcluster.oracle.iniの例では、データベース・ログを利用できなかった場合のバックアップ構成を示します。

[basicTwosafeDSN]
MasterHosts=host1,host2
ReturnServiceAttribute=RETURN TWOSAFE
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600

次のリカバリ手順を実行します。

TimesTenデーモン・モニター(ttCRSmaster)、レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。
```
ttCWAdmin -stop -dsn basicTwosafeDSN
```
アクティブ・スタンバイ・ペアを削除します。
```
ttCWAdmin -drop -dsn basicTwosafeDSN
```
前のアクティブ・データベースまたはスタンバイ・データベースのどちらがより新しいかを判断し、新しい方のデータベースを使用してアクティブ・スタンバイ・ペアを再度作成します。アクティブ・データベースを配置するホストを選択するように要求されます。
```
ttCWAdmin -create -dsn basicTwosafeDSN
```
どちらのデータベースも使用できない場合、バックアップからデータベースをリストアします。
```
ttCWAdmin -restore -dsn basicTwosafeDSN
```
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
```
ttCWAdmin -start -dsn basicTwosafeDSN
```

3つ以上のマスター・ホストで障害が発生した場合

二重のホスト障害のより極端なケースとして、3つ以上のマスター・ホストの障害対応について説明します。

次のガイドラインを使用してください:

停電やネットワーク障害などの場合は、障害の根本原因に対処します。
アクティブ・データベースおよびスタンバイ・データベース用の少なくとも2つの正常なホストを識別または取得します。
cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。
その後に実行する操作のガイドラインは、「高度な可用性の場合の手動リカバリ」および「基本的な可用性の場合の手動リカバリ」を参照してください。

アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行

TimesTenおよびOracle Clusterwareによって自動リカバリが実行されるまで待機せずに、スタンバイ・データベースに強制的にスイッチオーバーする場合は、Oracle Clusterwareコマンドを使用してアプリケーションを作成します。

次のことを実行します:

crsctl stop resourceコマンドを使用して、アクティブ・データベースでTimesTenデーモン・モニター(ttCRSmaster)リソースを停止します。これにより、スタンバイ・データベースのロールがアクティブに変更されます。
以前のアクティブ・データベースでttCRSmasterリソースを再起動するには、crsctl start resourceコマンドを使用します。これにより、データベースがリカバリされ、スタンバイ・データベースになります。

次の例は、host1のアクティブ・データベースからhost2のスタンバイ・データベースへの強制スイッチオーバーを示しています。

crsctl status resourceコマンドを使用して、すべてのTimesTenリソースを検索します。

% crsctl status resource | grep TT
  NAME=TT_Activeservice_tt181_ttadmin_REP1
  NAME=TT_Agent_tt181_ttadmin_HOST1
  NAME=TT_Agent_tt181_ttadmin_HOST2
  NAME=TT_App_tt181_ttadmin_REP1_updateemp
  NAME=TT_Daemon_tt181_ttadmin_HOST1
  NAME=TT_Daemon_tt181_ttadmin_HOST2
  NAME=TT_Master_tt181_ttadmin_REP1_0
  NAME=TT_Master_tt181_ttadmin_REP1_1
  NAME=TT_Subservice_tt181_ttadmin_REP1

ttCRSActiveServiceリソースのステータスを取得して、アクティブ・データベースが存在するホストを検索します。

% crsctl status resource TT_Activeservice_tt181_ttadmin_REP1
  NAME=TT_Activeservice_tt181_ttadmin_REP1
  TYPE=application
  TARGET=ONLINE
  STATE=ONLINE on host1

初期ステータス・レポートには2つのttCRSmasterリソースがリストされています。どのttCRSmasterリソースがアクティブ・データベースと同じホストにあるかを確認します。

% crsctl status resource TT_Master_tt181_ttadmin_REP1_0
  NAME=TT_Master_tt181_ttadmin_REP1_0
  TYPE=application
  TARGET=ONLINE
  STATE=ONLINE on host1

% crsctl status resource TT_Master_tt181_ttadmin_REP1_1
  NAME=TT_Master_tt181_ttadmin_REP1_1
  TYPE=application
  TARGET=ONLINE
  STATE=ONLINE on host2

アクティブ・データベースが存在するホストのttCRSmasterリソースを停止します。

% crsctl stop resource TT_Master_tt181_ttadmin_REP1_0
  CRS-2673: Attempting to stop 'TT_Master_tt181_ttadmin_REP1_0'
  on 'host1'
  CRS-2677: Stop of 'TT_Master_tt181_ttadmin_REP1_0' on
 'host1' succeeded

最初のアクティブ・データベースでttCRSmasterリソースを再起動します。

% crsctl start resource TT_Master_tt181_ttadmin_REP1_0
  CRS-2672: Attempting to start 'TT_Master_tt181_ttadmin_REP1_0'
  on 'host1'
  CRS-2676: Start of 'TT_Master_tt181_ttadmin_REP1_0' on
 'host1' succeeded

アクティブ・サービスttCRSActiveServiceおよびスタンバイ・サービスttCRSsubserviceリソースがある場所を確認して、強制スイッチオーバーが成功していることを確認します。

% crsctl status resource TT_Activeservice_tt181_ttadmin_REP1
  NAME=TT_Activeservice_tt181_ttadmin_REP1
  TYPE=application
  TARGET=ONLINE
  STATE=ONLINE on host2
 
% crsctl status resource TT_Subservice_tt181_ttadmin_REP1
  NAME=TT_Subservice_tt181_ttadmin_REP1
  TYPE=application
  TARGET=ONLINE
  STATE=ONLINE on host1

crsctl start resourceおよびcrsctl stop resourceコマンドの詳細は、Oracle Databaseドキュメントの『Oracle Clusterware Clusterware管理およびデプロイメント・ガイド』を参照してください。