ヘッダーをスキップ

Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド リリース6.0 B25769-01 |
| 目次 | 索引

前へ | 次へ |

## データ・ストアのフェイルオーバーおよびリカバリの管理

に関する項で説明しているように、高可用性システムの設計での基本的な要素は、障害からすぐにリカバリできる機能です（「高可用性システムの設計」を参照）。障害は、次の項目に関連している場合があります。

ハードウェアの問題:

- システムの障害
- ネットワークの障害

ソフトウェアの問題:

- オペレーティング・システムの障害
- アプリケーションの障害
- データ・ストアの障害
- オペレータのエラー

レプリケート・システムでは、クラスタ・マネージャまたはカスタム・ソフトウェアを使用して、このような障害を検出し、マスター・データ・ストアに関連する障害が発生した場合は、ユーザー・ロードをいずれかのサブスクライバにリダイレクトする必要があります。TimesTenでは、クラスタ・マネージャは提供されておらず、それらの動作についても想定されていません。そのため、ここでは、アプリケーションまたはクラスタ・マネージャで障害のリカバリに使用できるTimesTenメカニズムについて説明します。

レプリケーション・スキームがRETURN TWOSAFEを使用するように設定されていないかぎり、TimesTenでは、元のトランザクションがマスター・データ・ストアにコミットした後にのみ、更新がレプリケートされます。サブスクライバ・データ・ストアが稼働できない場合、またはサブスクライバ・データ・ストアへの通信で障害が発生した場合でも、マスターでの更新は妨げられません。サブスクライバ・システムの停止中、サブスクライバへの更新はTimesTenトランザクション・ログに保存されます。

注意: アクセス制御を有効にしてTimesTenをインストールした場合、この項のほとんどの手順を実行するには、データ・ストアに対するADMIN権限が必要です。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のアクセス制御とroot以外のインストールに関する章を参照してください。

## 一般的なフェイルオーバーおよびリカバリの手順

フェイルオーバーおよびリカバリを管理するための手順は、主に次の内容に依存します。

- レプリケーション・スキーム（「フェイルオーバーおよびリカバリ」に関する項を参照）。
- 障害がマスターまたはサブスクライバのデータ・ストアのいずれで発生したか。
- 問題が解決され、データ・ストアを再接続する前に、マスターのトランザクション・ログのしきい値を超えてしまったかどうか。

### サブスクライバの障害

レプリケーション・スキームがデフォルトの非同期レプリケーションに設定されていると、サブスクライバ・データ・ストアが稼働できない場合、またはサブスクライバ・データ・ストアへの通信で障害が発生した場合でも、マスターでの更新は妨げられないため、クラスタ・マネージャですぐに処理を行う必要はありません。

注意: 障害が発生したサブスクライバがRETURNサービスを使用するように設定されている場合は、まず、RETURNサービス・ブロッキングを無効にする必要があります（「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照）。

サブスクライバ・システムの停止中、サブスクライバへの更新はマスターのトランザクション・ログに保存されます。マスターがFAILTHRESHOLDに達する前にサブスクライバ・エージェントがマスターとの通信を再開した場合、ログに保存されていた更新はサブスクライバに自動的に送信されるため、これ以上の処理は必要ありません（マスター・データ・ストアのFAILTHRESHOLD値の設定方法の詳細は、「ログ障害しきい値の設定」を参照）。

FAILTHRESHOLDを超えた場合、マスターはサブスクライバをFailed状態に設定します。このサブスクライバは、「障害が発生したデータ・ストアのリカバリ」の説明に従ってリカバリする必要があります。障害が発生したサブスクライバに接続中のアプリケーションは、レプリケーション・ピアがそのデータ・ストアをFailedにマークしたことを示すtt_ErrReplicationInvalid (8025)警告を受信します。

アプリケーションでは、ODBCのSQLGetInfo関数を使用して、接続中のサブスクライバ・データ・ストアがFailed状態に設定されているかどうかを確認できます。SQLGetInfo関数には、TimesTen固有の情報タイプTT_REPLICATION_INVALIDが含まれています。これは、データ・ストアで障害が発生した場合は32ビットの整数値1、障害が発生しなかった場合は0（ゼロ）を返します。情報タイプTT_REPLICATION_INVALIDはTimesTen固有であるため、これを使用するすべてのアプリケーションでは、他のODBCインクルード・ファイルに加えて、timesten.hファイルをインクルードする必要があります。

##### 例8.7

たとえば、hdbcハンドルで識別されたデータ・ストアがFailed状態に設定されているかどうかを確認するには、次のように入力します。

    SQLINTEGER retStatus;
    SQLGetInfo(hdbc, TT_REPLICATION_INVALID,
      (PTR)&retStatus, NULL, NULL);

### マスターの障害

クラスタ・マネージャは、障害がマスター・データ・ストアに関連している場合により中心的な役割を果たします。マスター・データ・ストアで障害が発生すると、クラスタ・マネージャはこの障害を検出し、影響を受けなかったいずれかのデータ・ストアにユーザー・ロードをリダイレクトする必要があります。影響を受けなかったこのサブスクライバが新しいマスターとなり、トランザクションを処理して、障害を受けなかった他のサブスクライバ・データ・ストアにレプリケートします。障害が発生したマスターと障害の影響を受けなかったサブスクライバを双方向方式で設定していた場合、障害が発生したマスターからサブスクライバへのユーザー・ロードの転送でレプリケーション・スキームを変更する必要はありません。ただし、単方向レプリケーションまたはプロパゲータが関連するスキームなどの複雑なスキームを使用している場合は、1つ以上のALTER REPLICATION文を発行して、障害の影響を受けなかったサブスクライバを新しいマスターとしてスキームに再設定する必要があります。例は、「マスター・データ・ストアの交換」を参照してください。

問題の解決時に、「障害が発生したマスター・データ・ストアの自動キャッチアップ」で説明されているホット・スタンバイ構成またはアクティブ・スタンバイ・ペアを使用していない場合は、「障害が発生したデータ・ストアのリカバリ」の説明に従ってマスター・データ・ストアをリカバリする必要があります。

データ・ストアがオンラインに戻った後、クラスタ・マネージャは、ユーザー・ロードを元のマスターに戻すか、または元のマスターを代理マスターのサブスクライバとして再設定することもできます。詳細は、「フェイルオーバーおよびリカバリ」を参照してください。

### 障害が発生したマスター・データ・ストアの自動キャッチアップ

マスター・キャッチアップ機能は、ttRepAdmin -duplicate処理（「障害が発生したデータ・ストアのリカバリ」を参照）を実行する必要がなく、サブスクライバ・データ・ストアから障害のあったマスター・データ・ストアを自動的にリストアします。

マスター・キャッチアップ機能は、設定の必要はありませんが、次のタイプの設定でのみ使用できます。

- 1つのサブスクライバに双方向ホット・スタンバイ方式でレプリケートされる1つのマスター
- 最大62の読取り専用サブスクライバに変更を伝播するスタンバイ・データ・ストアにアクティブ・マスター・データ・ストアがレプリケートされるアクティブ・スタンバイ・ペア

また、次の要件を満たす必要があります。

- ELEMENTタイプがDATASTOREである。
- TRANSMIT NONDURABLEが有効である（TRANSMIT NONDURABLEは、非同期およびRETURN RECEIPTトランザクションの場合はオプションで、RETURN TWOSAFEトランザクションの場合は必須）。

クラッシュまたは無効化の後にマスター・レプリケーション・エージェントを再起動すると、マスターで消失したトランザクションがサブスクライバからマスターに自動的にレプリケートされます。マスター・ストアがサブスクライバと完全に同等となるまで、マスター・ストアに接続することはできません。キャッチアップ・フェーズでデータ・ストアへの接続を試行したアプリケーションは、キャッチアップ中であることを示すエラーを受信します。例外は、DSNにForceConnect属性が設定されているデータ・ストアに接続する場合のみです。

キャッチアップ・フェーズが終了すると、アプリケーションでデータ・ストアに接続できます。キャッチアップ・フェーズの終了は、システム・ログへのSNMPトラップおよびメッセージで示されます。

キャッチアップ・プロセスでいずれかのストアが無効にされたか、またはクラッシュした場合、キャッチアップ・フェーズは、ストアが再起動されると再開します。

### マスター/サブスクライバの障害

それぞれがマスターおよびサブスクライバの両方として機能する、双方向にレプリケートされた複数のデータ・ストアにワークロードを分散することができます（「単方向レプリケーションまたは双方向レプリケーション」を参照）。マスター/サブスクライバ・データ・ストアをリカバリする場合、レプリケーションの再起動時に、障害が発生したデータ・ストアのログに問題が示される可能性があります。

分散ワークロード・スキームのデータ・ストアで障害が発生し、影響を受けなかったデータ・ストアに作業を切り替えた場合、影響を受けなかったデータ・ストアには障害が発生したデータ・ストアより新しい情報が反映されます。影響を受けなかったデータ・ストアでFAILTHRESHOLDに達する前に、障害が発生したシステムでレプリケーションが再起動された場合、両方のデータ・ストアは、トランザクション・ログの内容を使用して互いの更新を試行します。この場合、障害が発生したデータ・ストアのトランザクション・ログの古い更新が、影響を受けなかったシステムの新しいデータを上書きする可能性があります。

このような状況でリカバリするには、次の2つの方法があります。

- タイムスタンプによる競合解消ルール（「レプリケーション競合の検出および解消」を参照）がアプリケーションの一貫性の保証に十分な場合は、障害が発生したシステムを再起動し、障害が発生したデータ・ストアの更新を影響を受けなかったデータ・ストアに伝播することができます。この競合解消ルールによって、新しい更新が上書きされなくなります。
- 「障害が発生したデータ・ストアのリカバリ」の説明に従って、障害が発生したデータ・ストアを再作成します。

注意: データ・ストアを再作成する必要がある場合、障害が発生したデータ・ストアのログに保存されていた更新のうち、障害が発生していないデータ・ストアで受信していない更新を識別またはリストアすることはできません。障害が発生していないデータ・ストアが複数ある場合は、どのデータ･ストアを使用して障害が発生したデータ・ストアを再作成するかを選択する必要があります。障害が発生したデータ・ストアを再作成する時点において、再作成に使用するデータ・ストアが、障害が発生していない他のデータ・ストアからの更新のすべてを受信していないこともあります。この場合、データ・ストア間で相違が発生します。このような状況を避ける唯一の方法として、再作成に使用するデータ・ストアから、障害が発生していない他のデータ・ストアすべてを再作成する方法があります。

### ネットワークの障害

一時的なネットワークの障害が発生した場合、レプリケーションを続行するために特定の処理を実行する必要はありません。通信中だったレプリケーション・エージェントは、数秒ごとに再接続を試行します。マスター・データ・ストアがログ領域を使い果たす前にエージェントが再接続すると、レプリケーション・プロトコルによって、レプリケーション更新の見落しも重複もないことが確認されます。ネットワークを長期間使用できず、マスター・ログのFAILTHRESHOLDを超えた場合は、「障害が発生したデータ・ストアのリカバリ」の説明に従って、サブスクライバをリカバリする必要があります。

## 障害が発生したデータ・ストアのリカバリ

再起動したデータ・ストアをマスターのトランザクション・ログからリカバリして、レプリケーション・システムの他のデータ・ストアとの一貫性を保つことができない場合、そのレプリケーション・ピアの1つからデータ・ストアを再作成する必要があります。データ・ストアがホット・スタンバイ・レプリケーション・スキームで設定されている場合、障害が発生したマスター・データ・ストアはサブスクライバから自動的に最新の状態にされます（「障害が発生したマスター・データ・ストアの自動キャッチアップ」を参照）。他のタイプのレプリケーション・スキームに設定されているデータ・ストアは、コマンドライン・ユーティリティを使用するか、またはTimesTenユーティリティC関数をプログラムで使用してリストアする必要があります（次の項を参照）。

注意: 障害が発生したデータ・ストアのDSNを再作成する必要はありません。

サブスクライバで障害が発生した場合、RETURNサービスで設定された表に対するマスター・データ・ストアでのコミットは、RETURNサービス・タイムアウト時間に達するまで実行されません。これを回避するには、RETURNサービスの障害およびリカバリ・ポリシーをレプリケーション・スキームに設定します（「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照）。RETURN RECEIPTサービスを使用している場合は、ALTER REPLICATIONを使用してNO RETURN属性を設定し、サブスクライバがリストアされ、最新情報を反映するまでRETURN RECEIPTを無効にすることもできます。反映した時点で、別のALTER REPLICATIONを実行してRETURN RECEIPTを再設定できます。

注意: 複製処理を使用して、障害の影響を受けなかったデータ・ストア（キャッシュ・グループを含む）からリカバリした場合、リカバリしたデータ・ストアですべてのキャッシュ・グループ表が通常の表に変換されます。リカバリしたデータ・ストアでキャッシュ・グループを再作成するには、表を手動で削除し、CREATE CACHE GROUPを使用してキャッシュ・グループを再作成する必要があります。

### コマンドラインから

データ・ストアを完全にレプリケートする場合は、ttDestroyを使用して、障害が発生したデータ・ストアをメモリーから削除し、ttRepAdmin -duplicateを使用して、影響を受けなかったデータ・ストアから再作成することができます。

##### 例8.8

たとえば、障害が発生したデータ・ストアsubscriberdsをホストsystem1のマスターmasterdsからリカバリするには、次のように入力します。

    > ttDestroy /tmp/subscriberds
    > ttRepAdmin -dsn subscriberds -duplicate -from masterds
    -host "system1"

注意: ttRepAdmin -duplicateは、同一のTimesTenリリースおよびパッチ・リリース間でのみサポートされます（メジャーおよびマイナーのリリース番号が同じである必要があります）。

ttRepAdmin -duplicateを使用してデータ・ストアを再作成した後、データ・ストアに最初に接続すると、データ・ストアがメモリーにリロードされます。大容量のデータ・ストアの複製時にパフォーマンスを向上させるには、ttRepAdmin -ramLoadオプションを使用して複製処理後もデータ・ストアをメモリー内に保持して、リロード・ステップを回避します。

##### 例8.9

たとえば、障害のあったデータ・ストアsubscriberdsをホストsystem1のマスターmasterdsからリカバリし、データ・ストアをメモリー内に保持して、複製処理の後でレプリケーションを再起動するには、次のように入力します。

    > ttDestroy /tmp/subscriberds
    > ttRepAdmin -dsn subscriberds -duplicate -ramLoad -from masterds
    -host "system1" -setMasterRepStart

注意: ttRepAdmin -duplicate -ramLoadオプションを使用してデータ・ストアを複製した後、データ・ストアのRAMポリシーは、ttAdmin -ramPolicyまたはttRamPolicy関数で明示的に再設定されるまでmanualとなります。

### プログラムから

TimesTenユーティリティ・ライブラリで提供されるC関数を使用して、障害が発生したデータ・ストアをプログラムでリカバリできます。

データ・ストアを完全にレプリケートする場合は、ttDestroyDataStore関数を使用して、障害が発生したデータ・ストアを削除し、ttRepDuplicateEx関数を使用して、影響を受けなかったデータ・ストアから再作成することができます。

##### 例8.10

たとえば、ホストsystem1のマスターmasterdsから、ホストsystem2の障害が発生したデータ・ストアsubscriberdsをリカバリおよび起動するには、次のように入力します。

    int           rc;
    ttUtilHandle  utilHandle;
    rc = ttDestroyDataStore (utilHandle, "/tmp/subscriberds",  30);
    rc = ttRepDuplicateEx (utilHandle,
                         "/tmp/subscriberds", "/tmp/masterds",
                         "system2", "system1",
                         TT_FALSE, TT_FALSE, TT_TRUE, TT_TRUE);

    この例では、ttDestroyDataStore処理のタイムアウト時間は30秒です。ttRepDuplicateEx関数の最後の2つのパラメータで、subscriberdsデータ・ストアをStart状態に、そのRAMポリシーをmanualに設定して、複製処理後にメモリーにデータ・ストアを保持します。

注意: ttRepDuplicateEx ramLoadポリシーをTT_TRUEに設定すると、複製データ・ストアのRAMポリシーは、ttRamPolicy関数またはttAdmin -ramPolicyで明示的に再設定されるまでmanualとなります。

TimesTen C言語ユーティリティ・ライブラリで提供される関数の完全なリストについては、『Oracle TimesTen In-Memory Database C開発者およびリファレンス・ガイド』のTimesTenユーティリティAPIに関する章を参照してください。

## 特別なリカバリ

データ・ストアがNONDURABLEである場合、またはSEQUENCE番号を使用している場合は、特別な処理が必要となります。

### NONDURABLEデータ・ストアのリカバリ

ホット・スタンバイ構成でTRANSMIT NONDURABLEオプションを指定してデータ・ストアを設定する場合は、障害が発生したマスター・データ・ストアをリカバリするために処理を行う必要はありません（「障害が発生したマスター・データ・ストアの自動キャッチアップ」を参照）。

他のタイプの設定では、TRANSMIT NONDURABLEオプションで設定されたデータ・ストアで障害が発生した場合、ttRepAdmin -duplicateまたはttRepDuplicateを使用して、最新のサブスクライバ・データ・ストアからマスター・データ・ストアを再作成する必要があります。アプリケーションで最初に複製処理を行わずに、マスター・データ・ストアに再接続しようとすると、レプリケーション・エージェントによってデータ・ストアはリカバリされますが、複製を行うように忠告するエラーが返されます。このエラーが発生しないようにするには、アプリケーションで接続属性ForceConnectを1に設定して再接続する必要があります。

### SEQUENCE番号を持つデータ・ストアのリカバリ

SEQUENCE値は各データ・ストアから独立していて、レプリケートされません。たとえば、masterdsデータ・ストアで1から100,000までの順序を定義し、subscriberdsで100,001から200,000までの順序を定義する場合があります。これらの順序を使用して、1つ以上のレプリケート表の列に値を移入する場合は、各データ・ストアでその範囲から一意の値を割り当てる必要があります。

ネットワークの障害が発生し、レプリケーションがログからリカバリされる場合、SEQUENCE値は想定したとおりにリカバリされます。ただし、障害が発生したデータ・ストアをttRepAdmin -duplicateまたはttRepDuplicateを使用して再作成する必要がある場合は、SEQUENCE定義が一方のデータ・ストアから他方のデータ・ストアにコピーされるため、結果として両方のデータ・ストアで同じ範囲の順序値（100,001から200,000など）が生成されます。これを回避するには、データ・ストアに対してアプリケーションを再起動する前に、DROP SEQUENCEおよびCREATE SEQUENCE文を使用して、重複を生成しない範囲ですべての順序を再作成します。

これらの方法をレプリケーション設定で使用することで、一意性の保証にSEQUENCEを使用できます。最大値に達した場合、SEQUENCEは、CREATE SEQUENCEのCYCLEオプションの値に応じて、サイクルする（開始値に戻る）か、またはエラー文を返します。

## 障害リカバリ・スクリプトの作成

障害を検出した後、クラスタ・マネージャは、例8.11の擬似コードで示されたプロシージャを効果的に実行するスクリプトを実行する必要があります。

##### 例8.11

    Detect problem {
     if (Master == unavailable) {
      FailedDataStore = Master
      FailedDSN = Master_DSN
      SurvivorDataStore = Subscriber
      switch users to SurvivorDataStore
     }
     else {
      FailedDataStore = Subscriber
      FailedDSN = Subscriber_DSN
      SurvivorDataStore = Master
     }
    }
    Fix problem....
    If (Problem resolved) {
     Get state for FailedDataStore
     if (state == "failed") {
      ttDestroy FailedDataStore
      ttRepAdmin -dsn FailedDSN -duplicate
          -from SurvivorDataStore -host SurvivorHost
          -setMasterRepStart
     }
     else {
      ttAdmin -repStart FailedDSN
     }
     while (backlog != 0) {
      wait
     }
    }
    Switch users back to Master

これは、マスターまたはサブスクライバのいずれかのデータ・ストアに適用します。マスターで障害が発生すると、一部のトランザクションが失われる場合があります。