障害からのリカバリ
Oracle Clusterwareは、様々な種類の障害から自動的にリカバリできます。
次の項では、いくつかの障害の例と、Oracle Clusterwareによる障害の管理方法を示します。
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
に変更され、アプリケーションによって新しいアクティブ・データベースが更新されています。
Oracle Clusterwareによって、障害が発生したデータベースまたはホストの再起動が試行されます。成功すると、そのデータベースがスタンバイ・データベースになります。
図8-3に、前のアクティブ・マスターがスタンバイ・マスターになったクラスタを示します。
前のアクティブ・マスターの障害が永続的であり、高度な可用性が構成されている場合は、Oracle Clusterwareでは追加のノードの1つでスタンバイ・マスターが起動されます。
図8-4に、追加のノードの1つでスタンバイ・マスターが起動されたクラスタを示します。
これらの自動アクションが実行されるまで待機しない場合は、「アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行」を参照してください。
スタンバイ・データベースまたはそのホストで障害が発生した場合
スタンバイ・マスターで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。スタンバイ・マスターを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでスタンバイ・マスターが起動されます。
図8-5に、追加のノードの1つでスタンバイ・マスターが起動されたクラスタを示します。
読取り専用サブスクライバまたはそのホストで障害が発生した場合
サブスクライバ・ノードで障害が発生した場合、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およびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。
次のステップでは、例としてbasicDSN
データベースおよびcluster.oracle.ini
ファイルを使用します。
基本的な可用性構成で手動リカバリを実行するには、次のステップを実行します。
データベースが破損した場合の同じマスター・ノードへの手動リカバリ
両方のマスター・ノードで障害が発生し、データベースが破損する場合があります。同じマスター・ノードにリカバリできます。
同じマスター・ノードにリカバリするには、次の手順を実行します:
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
次のリカバリ手順を実行します。
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 start resource
およびcrsctl stop resource
コマンドの詳細は、Oracle DatabaseドキュメントのOracle Clusterware管理およびデプロイメント・ガイドを参照してください。