1. レプリケーション・ガイド
  2. データベースのフェイルオーバーおよびリカバリの管理
  3. 一般的なフェイルオーバーおよびリカバリの手順

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

フェイルオーバーおよびリカバリを管理するための手順は、主に、いくつかの事柄で決まります。

  • レプリケーション・スキーム

  • 障害がマスターまたはサブスクライバのデータベースのいずれで発生したか。

  • 問題が解決され、データベースを再接続する前に、マスターのトランザクション・ログのしきい値を超えてしまったかどうか。

次の項では、フェイルオーバーを管理するための様々な手順について説明します。

サブスクライバの障害

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

ノート:

障害が発生したサブスクライバがRETURNサービスを使用するように構成されている場合は、まず、RETURNサービス・ブロッキングを無効にする必要があります(「RETURNサービス・ブロッキングの手動による無効化」を参照)。

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

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

アプリケーションでは、ODBCのSQLGetInfo関数を使用して、接続中のサブスクライバ・データベースがfailed状態に設定されているかどうかを確認できます。SQLGetInfo関数には、TimesTen固有の情報タイプTT_REPLICATION_INVALIDが含まれていて、データベースで障害が発生した場合は整数値1、障害が発生しなかった場合は0(ゼロ)を返します。

ノート:

情報タイプTT_REPLICATION_INVALIDはTimesTenに固有であるため、これを使用するすべてのアプリケーションでは、ODBCの他のincludeファイルに加えて、timesten.hファイルをインクルードする必要があります。

ただし、各データベースがマスターとサブスクライバの両方として動作する双方向のレプリケーション・スキームを使用している場合に、一方のサブスクライバが失敗すると、エラーが発生します。たとえば、双方向のレプリケーション・スキームのマスターおよびサブスクライバが次のように定義されているとします。

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE ttuser.accounts
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE ttuser.accounts
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast";

  • eastdsサブスクライバが失敗すると、westdsマスターは失敗を受信するため、このサブスクライバへの更新の蓄積を停止します。

  • eastdsサブスクライバが失敗すると、eastdsのレプリケーション・エージェントは停止します。ただし、eastdsマスターはレプリケーション・エージェントが停止されていることを認識せず、更新の蓄積を続行し、westdsのサブスクライバに伝播します。レプリケーション・エージェント(レコードをサブスクライバに伝播し、FAILTHRESHOLDを監視する)が停止しているため、これらの更新は、定義されたFAILTHRESHOLDを超えて蓄積され続けます。

サブスクライバまたはスタンバイ・データベースでTT_REPLICATION_INVALIDが1に設定されている場合、サブスクライバまたはスタンバイが更新を受信していないことが原因となってレプリケーション・エージェントは停止します。レプリケーション・スキームの双方向構成に関与しているデータベースに障害が発生すると、レプリケーション・エージェントは実行されず、FAILTHRESHOLDは無視されます。この状況を解決するには、サブスクライバまたはスタンバイ・データベースを削除して再作成します。

  1. 失敗したデータベースを破棄します(この例ではeastdsデータベース)。

  2. 双方向のレプリケーション・スキームのもう一方のマスターからttRepAdmin -duplicate操作を実行して、失敗したデータベースを再作成します(この例ではwestdsのマスター)。

hdbcハンドルで識別されたデータベースがfailed状態に設定されているかどうかを確認します。 

SQLINTEGER retStatus;

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

マスターの障害

クラスタ・マネージャは、障害がマスター・データベースに関連している場合により中心的な役割を果たします。マスター・データベースで障害が発生すると、クラスタ・マネージャはこの障害を検出し、影響を受けなかったいずれかのデータベースにユーザー・ロードをリダイレクトする必要があります。

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

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

データベースがオンラインに戻った後、クラスタ・マネージャは、ユーザー・ロードを元のマスターに戻すか、または元のマスターを代理マスターのサブスクライバとして再設定することもできます。

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

マスター・キャッチアップ機能では、ttRepAdmin -duplicate操作を呼び出す必要なく、障害が発生したマスター・データベースがサブスクライバ・データベースから自動的にリストアされます。

「障害が発生したデータベースのリカバリ」を参照してください。

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

  • 1つのサブスクライバに双方向方式でレプリケートされる1つのマスター

  • RETURN TWOSAFEを使用して構成されているアクティブ・スタンバイ・ペア

アクティブ・スタンバイ・ペアではないレプリケーション・スキームの場合、次の要件を満たす必要があります。

  • ELEMENTタイプがDATASTOREである。

  • TRANSMIT NONDURABLEまたはRETURN TWOSAFEが有効である必要がある。

  • すべてのレプリケート対象のトランザクションが非永続的にコミットされる必要がある。ローカル・データベースでコミットされる前にリモート・データベースに送信される必要があります。たとえば、レプリケーション・スキームがRETURN TWOSAFE BY REQUESTで構成され、最初にRETURN TWOSAFEを有効にせずにトランザクションがコミットされた場合、マスターに障害が発生した後マスター・キャッチアップが発生しないことがあります。

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

次のような状況では、マスター・キャッチアップは失敗する場合があります。

  • 障害が発生したデータベースが長時間オフラインになり、サブスクライバ・データベース(アクティブ・スタンバイ・ペアのスタンバイ・データベース)で障害しきい値を超えた。

  • 障害発生時に、アクティブ・スタンバイ・ペアのアクティブ・データベースで動的なロード処理が実行されていた。RETURN TWOSAFEは、アクティブ・データベースに対して有効になっていても、動的なロード処理では有効になりません。データベースの障害によって動的なロードのトランザクションがトラップされ、RETURN TWOSAFEで障害が発生します。

アクティブ・スタンバイ・ペアにマスター・キャッチアップが必要な場合

TimesTenエラー8110(Connection not permitted. This store requires Master Catchup.)は、スタンバイ・データベースがアクティブ・データベースより先行し、レプリケーションが再開するにはマスター・キャッチアップが必要であることを示します。

アクティブ・スタンバイ・ペアでマスター・キャッチアップを使用している場合、スタンバイ・データベースがフェイルオーバーにより新しいアクティブ・データベースになる必要があります。古いアクティブ・データベースのリカバリができると、そのデータベースが新しいスタンバイ・データベースになります。リカバリができない場合は、古いアクティブ・データベースを破棄し、新しいアクティブ・データベースを複製することによって新しいスタンバイ・データベースを作成する必要があります。RETURN TWOSAFEが構成されている(マスター・キャッチアップに必要)場合の、アクティブ・データベースの障害からのリカバリの詳細は、「レプリケーションがRETURN TWOSAFEの場合」を参照してください。

RETURN TWOSAFEを使用して構成されているアクティブ・スタンバイ・ペアでは、トラップされたトランザクションが含まれる可能性があります。フェイルオーバー後新しいアクティブ・データベースに存在しないトランザクションが新しいスタンバイ・データベースに存在する場合に、トラップされたトランザクションが発生します。エラー16227(Standby store has replicated transactions not present on the active)はトラップされたトランザクションを示す一例です。トラップされたトランザクションの数は、手動リカバリ処理中に各データベースでレプリケート表のレコード数をチェックすることによって確認できます。たとえば、次のように文を入力します。 

SELECT COUNT(*) FROM reptable;

トラップされたトランザクションがある場合、次のタスクを実行してリカバリを行います。

  1. ttRepStateSet組込みプロシージャを使用して、スタンバイ・データベースの状態を'ACTIVE'に変更します。

  2. 古いアクティブ・データベースを破棄します。

  3. ttRepAdmin -duplicateを使用して、すべてのトランザクションを含む新しいアクティブ・データベースから新しいスタンバイ・データベースを作成します。「データベースの複製」を参照してください。

双方向の分散ワークロード・スキームの障害

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

「双方向の分散ワークロード・スキーム」を参照してください。

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

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

  • タイムスタンプによる競合解消ルール(レプリケーション競合の解消を参照)がアプリケーションの一貫性の保証に十分な場合は、障害が発生したシステムを再起動し、障害が発生したデータベースから残存しているデータベースに更新を伝播できます。この競合解消ルールによって、新しい更新が上書きされなくなります。

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

ネットワークの障害

一時的なネットワークの障害が発生した場合、レプリケーションを続行するために特定の処理を実行する必要はありません。

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

順序に関わる障害

キューされたログを再生してレプリケーションをリカバリできる場合、ネットワーク・リンクで障害が発生した後に処理を行う必要はありません。

ただし、障害が発生したホストが長時間にわたって停止した場合は、順序は障害のリカバリ中にロールバックされないため、ttRepAdmin -duplicateコマンドを使用して、障害の影響を受けなかったホストから障害が発生したホストのデータベースにトランザクションを再移入する必要があります。この場合、ttRepAdmin -duplicateコマンドによって、データベース間の順序定義のコピーが実行されます。