レプリカ・セット内の単一の要素に障害が発生した場合のリカバリ
k >= 2
の場合、レプリカ・セット内で単一の要素が失敗した場合に実行できるリカバリ方法があります。
要素ステータスに基づくトラブルシューティング
要素ステータスの中には、ユーザーによる介入が必要なものがあります。要素ステータスを表示したときに、これらの各要素ステータスに対応できます。
表13-2に、各要素ステータスの詳細と要素ステータスの変更への推奨される対応方法を示します。
表13-2 要素ステータス
ステータス | 意味 | ノートおよび推奨事項 |
---|---|---|
|
要素をクローズしようとして失敗しました。 |
障害の詳細は、
|
|
要素をクローズ中です。 |
しばらく待ってから、 |
|
要素を作成しようとして失敗しました。 |
障害の詳細は、
|
|
要素を作成中です。 |
しばらく待ってから、 |
|
要素を破棄しようとして失敗しました。 |
障害の詳細は、 要素ステータスが |
|
要素が破棄されました。 |
要素は存在しません。 ノート: データベースの最後の要素が破棄されると、要素ステータスを含め、データベースのレコードは何も存在しなくなります。 |
|
要素を破棄中です。 |
しばらく待ってから、 |
|
この要素が配置されているデータ・インスタンスが実行されていません。 |
データ・インスタンスが停止している場合、要素のステータスはdownです。
「停止しているデータ・インスタンスの再起動」および「データ・インスタンスが停止している場合のリカバリ」を参照してください。 |
|
要素は |
要素ステータスが |
|
要素は |
しばらく待ってから、 要素ステータスが |
|
要素は |
しばらく待ってから、 要素ステータスが |
|
要素をロードしようとして失敗しました。 |
障害の詳細は、
|
|
要素がロードされました。 |
要素はロードされ、オープンできるようになりました。 |
|
要素をロード中です。 |
しばらく待ってから、 |
|
要素はオープンしています。 |
機能している要素の標準ステータスです。要素を介してデータベース接続が可能です。 |
|
要素をオープンしようとして失敗しました。 |
障害の詳細は、
|
|
要素をオープン中です。 |
しばらく待ってから、 |
|
要素を作成する必要がありますが、作成はまだ開始されていません。 |
しばらく待ってから、 |
|
要素はアンロードされました。 |
データベースを再度ロード(
|
|
要素をアンロード中です。 |
しばらく待ってから、 |
|
要素はロードされますが、レプリカ・セット内のシード要素がロードされる後まではロードされません。 |
レプリカ・セット内のシード要素のステータスに注意してください。最新の変更で失敗したレプリカ・セットの要素は、シード要素と呼ばれます。シード要素は最初に、チェックポイントおよびトランザクション・ログ・ファイルの最新のトランザクションでリカバリされます。
|
ノート:
ノートおよび推奨事項の列では、頻繁にttGridAdmin
コマンドが示されています。これらのコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』内で、ttGridAdmin dbStatus
についてはデータベースのステータスのモニター(dbStatus)、ttGridAdmin dbCreate
についてはデータベースの作成(dbCreate)、ttGridAdmin dbOpen
についてはデータベースのオープン(dbOpen)、ttGridAdmin dbLoad
についてはメモリーへのデータベースのロード(dbLoad)、ttGridAdmin dbUnload
についてはデータベースのアンロード(dbUnload)、ttGridAdmin dbClose
についてはデータベースのクローズ(dbClose)、ttGridAdmin dbDestroy
についてはデータベースの破棄(dbDestroy)、ttGridAdmin instanceExec
についてはグリッド・インスタンスでのコマンドまたはスクリプトの実行(instanceExec)を参照してください。
次の各項では、レプリカ・セット内の単一の要素に障害が発生した場合の様々なシナリオへの対応方法を示します。
要素の作成の再試行
要素の作成が失敗した場合は、その要素が存在する必要がある同じデータ・インスタンスで、ttGridAdmin dbCreate -instance
コマンドを使用して要素の作成を再試行してください。
% ttGridAdmin dbCreate database1 -instance host3
Database database1 creation started
停止しているデータ・インスタンスの再起動
データ・インスタンスが停止している場合、データ・インスタンス内の要素は停止しています。ttGridAdmin dbStatus -all
コマンドを使用して、データ・インスタンスが停止しているかどうかを確認できます。
ttDaemonAdmin -start
またはttDaemonAdmin -restart
コマンドのいずれかを実行するには、ttGridAdmin instanceExec -only
コマンドを使用してデータ・インスタンスのデーモンを再起動します。
次の例では、host4.instance1
データ・インスタンスを起動します。
% ttGridAdmin instanceExec -only host4.instance1 ttDaemonAdmin -start
Overall return code: 0
Commands executed on:
host4.instance1 rc 0
Return code from host4.instance1: 0
Output from host4.instance1:
TimesTen Daemon (PID: 15491, port: 14000) startup OK.
データ・インスタンスが再起動しない場合は、「データ・インスタンスが停止している場合のリカバリ」を参照してください。
除去された要素または破棄が失敗した要素の破棄
要素を除去した場合でも、その要素が使用しているファイル・システム領域を解放するために、要素を破棄する必要があります。その後で、新しい要素を作成できます。
要素ステータスがdestroy failed
またはevicted
の場合は、ttGridAdmin dbDestroy -instance
コマンドを使用して、データ・インスタンスの要素を破棄します。
% ttGridAdmin dbDestroy database1 -instance host3 Database database1 destroy started
「レプリカ・セットに永続的な障害が発生した要素がある場合のリカバリ」を参照してください。
要素が停止した後のレプリカ・セットのリカバリ
-
障害が発生した要素がリカバリされた場合、その要素はしばらくの間使用不可能になり、トランザクション上の遅れが生じます。この要素がグリッド内のレプリカ・セットにおける役割を再開するためには、レプリカ・セットのアクティブな要素とデータを同期する必要があります。
-
要素にファイル・システム障害などの永続的な障害が発生した場合は、
ttGridAdmin dbDistribute -remove -replaceWith
コマンドを使用して、レプリカ・セットからその要素を削除し、別の要素に置き換える必要があります。「別の要素での要素の置換」を参照してください。
TimesTen Scaleoutでは、次の方法を使用して、レプリカ・セット内のリストアされた要素または新しい要素のデータが自動的に再同期およびリストアされます。
-
ログベースのキャッチ・アップ: このプロセスでは、レプリカ・セット内のアクティブな要素からトランザクション・ログを転送し、リカバリされる要素に欠落しているトランザクション・レコードを適用します。この操作によって、要素がレプリカ・セットに参加していなかったときに実行されたDML文またはDDL文が適用されます。ただし、TimesTen Scaleoutでは、リカバリする要素がログベースのキャッチ・アップでリカバリされている間は、新しいDDL文はブロックされます。
レプリカ・セットのいずれかの要素が停止していたときに開始されたトランザクションは、停止していた要素のリカバリ時に再実行する必要があります。ログベースのキャッチアップ・プロセスでは、すべてのオープン・トランザクションがコミットまたはロールバックするまで待機してから、それらのトランザクションをトランザクション・ログから再実行します。停止している要素が長時間にわたってリカバリ処理中の場合は、リカバリされる要素に対するログベースのキャッチアップ・プロセスの完了を妨げるオープン・トランザクションが(アクティブな要素に)存在してる可能性があります。
ttXactAdmin
ユーティリティを使用して、オープン・トランザクションがないか確認します。すべてのオープン・トランザクションを、コミットするかロールバックして解決します。 -
複製: TimesTen Scaleoutは、リカバリされる要素または障害が発生した要素を置換する新しい要素のいずれかに、アクティブな要素を複製します。複製操作では、アクティブな要素のすべてのチェックポイントおよびログ・ファイルがリカバリされる要素にコピーされます。
ただし、アクティブな要素は複製操作中も引き続きトランザクションを受け入れるため、コピーされたトランザクション・ログ・ファイルに含まれない追加のトランザクション・ログ・レコードが存在する可能性があります。複製操作が完了すると、TimesTen Scaleoutはアクティブな要素に接続してログベースのキャッチアップ操作を実行し、新しい要素を完全に最新の状態に更新します。
レプリカ・セット内の障害が発生した要素の削除および置換
k >= 2の場合に、要素を自動的にリカバリできないときは、障害の原因を調査する必要があります。
ドライブを再マウントする必要があるなど、修正できる問題が見つかる場合もあります。ただし、ドライブが完全に破壊されているなど、修正できない問題が見つかることもあります。永続的でリカバリ不可能な障害のほとんどは、通常はハードウェアの障害に関連しています。
-
修正可能な場合は、ホストまたはデータ・インスタンスの問題を修正してから、次のいずれかを実行します。
-
データ・インスタンスを再起動します。「データ・インスタンスが停止している場合のリカバリ」を参照してください。
-
ttGridAdmin dbload
コマンドを使用して、TimesTenデータベースを再ロードします。これにより、要素の再ロードが試行されます。
-
-
ホストまたはデータ・インスタンスに関する問題を修正できない場合は、要素のデータが取得できない状態になっている可能性があります。この場合は、要素を削除して、別の要素に置換する必要があります。置換されると、アクティブな要素によって、このレプリカ・セットのデータで新しい要素が更新されます。
いずれかのホストで複数のエラーが発生している場合(自動的にリカバリ可能であった場合でも)、より信頼性が高い別のホストに置き換えることをお薦めします。
データを失うことなく要素を置換するには、ttGridAdmin dbDistribute -remove -replaceWith
コマンドを実行します。これは、置換する要素に存在するデータを取得して、新しい要素に再分散します。「別の要素での要素の置換」を参照してください。