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