| Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド
リリース7.0 E05169-03 |
|
 前へ |
 次へ |
高可用性システムの設計での基本的な要素は、障害からすぐにリカバリできる機能です（「高可用性システムの設計」を参照）。障害は、次の項目に関連している場合があります。
ハードウェアの問題:
ソフトウェアの問題:
レプリケート・システムでは、クラスタ・マネージャまたはカスタム・ソフトウェアを使用して、このような障害を検出し、マスター・データ・ストアに関連する障害が発生した場合は、ユーザー・ロードをいずれかのサブスクライバにリダイレクトする必要があります。TimesTenでは、クラスタ・マネージャは提供されておらず、それらの動作についても想定されていません。そのため、ここでは、アプリケーションまたはクラスタ・マネージャで障害のリカバリに使用できるTimesTenメカニズムについて説明します。
レプリケーション・スキームがRETURN TWOSAFEを使用するように設定されていないかぎり、TimesTenでは、元のトランザクションがマスター・データ・ストアにコミットした後にのみ、更新がレプリケートされます。サブスクライバ・データ・ストアが稼働できない場合、またはサブスクライバ・データ・ストアへの通信で障害が発生した場合でも、マスターでの更新は妨げられません。サブスクライバ・システムの停止中、サブスクライバへの更新はTimesTenトランザクション・ログに保存されます。
| 注意: | アクセス制御を有効にしてTimesTenをインストールした場合、この項のほとんどの手順を実行するには、データ・ストアに対するADMIN権限が必要です。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のアクセス制御に関する説明を参照してください。 |
フェイルオーバーおよびリカバリを管理するための手順は、主に次の内容に依存します。
レプリケーション・スキームがデフォルトの非同期レプリケーションに設定されていると、サブスクライバ・データ・ストアが稼働できない場合、またはサブスクライバ・データ・ストアへの通信で障害が発生した場合でも、マスターでの更新は妨げられないため、クラスタ・マネージャですぐに処理を行う必要はありません。
| 注意: | 障害が発生したサブスクライバが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ファイルをインクルードする必要があります。
たとえば、hdbcハンドルで識別されたデータ・ストアがFailed状態に設定されているかどうかを確認するには、次のように入力します。
SQLINTEGER retStatus;
SQLGetInfo(hdbc, TT_REPLICATION_INVALID,
(PTR)&retStatus, NULL, NULL);
クラスタ・マネージャは、障害がマスター・データ・ストアに関連している場合により中心的な役割を果たします。マスター・データ・ストアで障害が発生すると、クラスタ・マネージャはこの障害を検出し、影響を受けなかったいずれかのデータ・ストアにユーザー・ロードをリダイレクトする必要があります。影響を受けなかったこのサブスクライバが新しいマスターとなり、トランザクションを処理して、障害を受けなかった他のサブスクライバ・データ・ストアにレプリケートします。障害が発生したマスターと障害の影響を受けなかったサブスクライバを双方向方式で設定していた場合、障害が発生したマスターからサブスクライバへのユーザー・ロードの転送でレプリケーション・スキームを変更する必要はありません。ただし、単方向レプリケーションまたはプロパゲータが関連するスキームなどの複雑なスキームを使用している場合は、1つ以上のALTER REPLICATION文を発行して、障害の影響を受けなかったサブスクライバを新しいマスターとしてスキームに再設定する必要があります。例は、「マスター・データ・ストアの交換」を参照してください。
問題の解決時に、「障害が発生したマスター・データ・ストアの自動キャッチアップ」で説明されているホット・スタンバイ構成またはアクティブ・スタンバイ・ペアを使用していない場合は、「障害が発生したデータ・ストアのリカバリ」の説明に従ってマスター・データ・ストアをリカバリする必要があります。
データ・ストアがオンラインに戻った後、クラスタ・マネージャは、ユーザー・ロードを元のマスターに戻すか、または元のマスターを代理マスターのサブスクライバとして再設定することもできます。詳細は、「フェイルオーバーおよびリカバリ」を参照してください。
マスター・キャッチアップ機能は、ttRepAdmin -duplicate処理（「障害が発生したデータ・ストアのリカバリ」を参照）を実行する必要がなく、サブスクライバ・データ・ストアから障害のあったマスター・データ・ストアを自動的にリストアします。
マスター・キャッチアップ機能は、設定の必要はありませんが、次のタイプの設定でのみ使用できます。
また、次の要件を満たす必要があります。
クラッシュまたは無効化の後にマスター・レプリケーション・エージェントを再起動すると、マスターで消失したトランザクションがサブスクライバからマスターに自動的にレプリケートされます。マスター・ストアがサブスクライバと完全に同等となるまで、マスター・ストアに接続することはできません。キャッチアップ・フェーズでデータ・ストアへの接続を試行したアプリケーションは、キャッチアップ中であることを示すエラーを受信します。例外は、DSNにForceConnect属性が設定されているデータ・ストアに接続する場合のみです。
キャッチアップ・フェーズが終了すると、アプリケーションでデータ・ストアに接続できます。キャッチアップ・フェーズの終了は、システム・ログへのSNMPトラップおよびメッセージで示されます。
キャッチアップ・プロセスでいずれかのストアが無効にされたか、またはクラッシュした場合、キャッチアップ・フェーズは、ストアが再起動されると再開します。
それぞれがマスターおよびサブスクライバの両方として機能する、双方向にレプリケートされた複数のデータ・ストアにワークロードを分散することができます（「単方向レプリケーションまたは双方向レプリケーション」を参照）。マスター/サブスクライバ・データ・ストアをリカバリする場合、レプリケーションの再起動時に、障害が発生したデータ・ストアのログに問題が示される可能性があります。
分散ワークロード・スキームのデータ・ストアで障害が発生し、影響を受けなかったデータ・ストアに作業を切り替えた場合、影響を受けなかったデータ・ストアには障害が発生したデータ・ストアより新しい情報が反映されます。影響を受けなかったデータ・ストアでFAILTHRESHOLDに達する前に、障害が発生したシステムでレプリケーションが再起動された場合、両方のデータ・ストアは、トランザクション・ログの内容を使用して互いの更新を試行します。この場合、障害が発生したデータ・ストアのトランザクション・ログの古い更新が、影響を受けなかったシステムの新しいデータを上書きする可能性があります。
このような状況でリカバリするには、次の2つの方法があります。
| 注意: | データ・ストアを再作成する必要がある場合、障害が発生したデータ・ストアのログに保存されていた更新のうち、障害が発生していないデータ・ストアで受信していない更新を識別またはリストアすることはできません。障害が発生していないデータ・ストアが複数ある場合は、どのデータ・ストアを使用して障害が発生したデータ・ストアを再作成するかを選択する必要があります。障害が発生したデータ・ストアを再作成する時点において、再作成に使用するデータ・ストアが、障害が発生していない他のデータ・ストアからの更新のすべてを受信していないこともあります。この場合、データ・ストア間で相違が発生します。このような状況を避ける唯一の方法として、再作成に使用するデータ・ストアから、障害が発生していない他のデータ・ストアすべてを再作成する方法があります。 |
一時的なネットワークの障害が発生した場合、レプリケーションを続行するために特定の処理を実行する必要はありません。通信中だったレプリケーション・エージェントは、数秒ごとに再接続を試行します。マスター・データ・ストアがログ領域を使い果たす前にエージェントが再接続すると、レプリケーション・プロトコルによって、レプリケーション更新の見落しも重複もないことが確認されます。ネットワークを長期間使用できず、マスター・ログのFAILTHRESHOLDを超えた場合は、「障害が発生したデータ・ストアのリカバリ」の説明に従って、サブスクライバをリカバリする必要があります。
キューされたログを再生してレプリケーションをリカバリできる場合、リンクで障害が発生した後に処理を行う必要はありません。
ただし、障害が発生したノードが長時間にわたって停止した場合は、ttRepAdmin -duplicateコマンドを使用して、障害の影響を受けなかったノードから障害が発生したノードのデータ・ストアにトランザクションを再移入する必要があります。順序は、障害のリカバリ中にロールバックされないためです。この場合、ttRepAdmin -duplicateコマンドによって、ノード間の順序定義のコピーが実行されます。
再起動したデータ・ストアをマスターのトランザクション・ログからリカバリして、レプリケーション・システムの他のデータ・ストアとの一貫性を保つことができない場合、そのレプリケーション・ピアの1つからデータ・ストアを再作成する必要があります。データ・ストアがホット・スタンバイ・レプリケーション・スキームで設定されている場合、障害が発生したマスター・データ・ストアはサブスクライバから自動的に最新の状態にされます（「障害が発生したマスター・データ・ストアの自動キャッチアップ」を参照）。他のタイプのレプリケーション・スキームに設定されているデータ・ストアは、コマンドライン・ユーティリティを使用するか、またはTimesTenユーティリティC関数をプログラムで使用してリストアする必要があります（次の項を参照）。
| 注意: | 障害が発生したデータ・ストアのDSNを再作成する必要はありません。 |
サブスクライバで障害が発生した場合、RETURNサービスで設定された表に対するマスター・データ・ストアでのコミットは、RETURNサービス・タイムアウト時間に達するまで実行されません。これを回避するには、RETURNサービスの障害およびリカバリ・ポリシーをレプリケーション・スキームに設定します（「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照）。RETURN RECEIPTサービスを使用している場合は、ALTER REPLICATIONを使用してNO RETURN属性を設定し、サブスクライバがリストアされ、最新情報を反映するまでRETURN RECEIPTを無効にすることもできます。反映した時点で、別のALTER REPLICATIONを実行してRETURN RECEIPTを再設定できます。
データ・ストアを完全にレプリケートする場合は、ttDestroyを使用して、障害が発生したデータ・ストアをメモリーから削除し、ttRepAdmin -duplicateを使用して、影響を受けなかったデータ・ストアから再作成することができます。データ・ストアにキャッシュ・グループが含まれている場合は、ttRepAdminの-keepCGオプションも使用する必要があります。
たとえば、障害が発生したデータ・ストアsubscriberdsをホストsystem1のマスターmasterdsからリカバリするには、次のように入力します。
> ttDestroy /tmp/subscriberds
> ttRepAdmin -dsn subscriberds -duplicate -from masterds
-host "system1"
| 注意: | ttRepAdmin -duplicateは、同一のTimesTenリリースおよびパッチ・リリース間でのみサポートされます（メジャーおよびマイナーのリリース番号が同じである必要があります）。 |
ttRepAdmin -duplicateを使用してデータ・ストアを再作成した後、データ・ストアに最初に接続すると、データ・ストアがメモリーにリロードされます。大容量のデータ・ストアの複製時にパフォーマンスを向上させるには、ttRepAdmin -ramLoadオプションを使用して複製処理後もデータ・ストアをメモリー内に保持して、リロード・ステップを回避します。
たとえば、障害のあったデータ・ストア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関数を使用して、影響を受けなかったデータ・ストアから再作成することができます。
たとえば、ホストsystem1のマスターmasterdsから、ホストsystem2の障害が発生したデータ・ストアsubscriberdsをリカバリおよび起動するには、次のように入力します。
int rc;
ttUtilHandle utilHandle;
ttRepDuplicateExArg arg;
memset( &arg, 0, sizeof( arg ) );
arg.size = sizeof( ttRepDuplicateExArg );
arg.flags = TT_REPDUP_REPSTART | TT_REPDUP_RAMLOAD;
arg.localHost = "system2";
rc = ttDestroyDataStore( utilHandle, "subscriberds", 30 );
rc = ttRepDuplicateEx( utilHandle, "DSN=subscriberds",
"masterds", "system1", &arg );
この例では、ttDestroyDataStore処理のタイムアウト時間は30秒です。ttRepDuplicateEx関数の最後のパラメータは、2つのフラグ（複製処理の完了後にsubscriberdsデータ・ストアをStart状態に設定するTT_REPDUP_RESTART、およびRAMポリシーをmanualに設定してメモリーにデータ・ストアを保持するTT_REPDUP_RAMLOAD）を含む引数構造になっています。
| 注意: | ttRepDuplicateExでTT_REPDUP_RAMLOADフラグを使用すると、複製データ・ストアのRAMポリシーは、ttRamPolicy関数またはttAdmin -ramPolicyで明示的に再設定されるまでmanualとなります。 |
TimesTen C言語ユーティリティ・ライブラリで提供される関数の完全なリストについては、『Oracle TimesTen In-Memory Database C開発者およびリファレンス・ガイド』のTimesTenユーティリティAPIに関する説明を参照してください。
ホット・スタンバイ構成でTRANSMIT NONDURABLEオプションを指定してデータ・ストアを設定する場合は、障害が発生したマスター・データ・ストアをリカバリするために処理を行う必要はありません（「障害が発生したマスター・データ・ストアの自動キャッチアップ」を参照）。
他のタイプの設定では、TRANSMIT NONDURABLEオプションで設定されたデータ・ストアで障害が発生した場合、ttRepAdmin -duplicateまたはttRepDuplicateExを使用して、最新のサブスクライバ・データ・ストアからマスター・データ・ストアを再作成する必要があります。アプリケーションで最初に複製処理を行わずに、マスター・データ・ストアに再接続しようとすると、レプリケーション・エージェントによってデータ・ストアはリカバリされますが、複製を行うように忠告するエラーが返されます。このエラーが発生しないようにするには、アプリケーションで接続属性ForceConnectを1に設定して再接続する必要があります。
障害を検出した後、クラスタ・マネージャは、例8.12の擬似コードで示されたプロシージャを効果的に実行するスクリプトを実行する必要があります。
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
これは、マスターまたはサブスクライバのいずれかのデータ・ストアに適用します。マスターで障害が発生すると、一部のトランザクションが失われる場合があります。
