レプリカ・セット内の単一の要素に障害が発生した場合のリカバリ

k >= 2の場合、レプリカ・セット内で単一の要素が失敗した場合に実行できるリカバリ方法があります。

要素ステータスに基づくトラブルシューティング

要素ステータスの中には、ユーザーによる介入が必要なものがあります。要素ステータスを表示したときに、これらの各要素ステータスに対応できます。

表13-2に、各要素ステータスの詳細と要素ステータスの変更への推奨される対応方法を示します。

表13-2 要素ステータス

ステータス 意味 ノートおよび推奨事項

close failed

要素をクローズしようとして失敗しました。

障害の詳細は、ttGridAdmin dbStatusコマンド出力を参照してください。

ttGridAdmin dbCloseを再度試行できます。

closing

要素をクローズ中です。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素がクローズしたことを確認します。一部の要素がまだクローズされている途中で、データベースをアンロードすることはできますが、ttGridAdmin dbUnload -forceコマンドを使用する必要があります。

create failed

要素を作成しようとして失敗しました。

障害の詳細は、ttGridAdmin dbStatus出力を参照してください。よくある問題は、要素を作成するために十分なセマフォがないこと、またはチェックポイント・ファイルのディレクトリになんらかの問題がある(権限が正しくない)ことです。「SEMMSLおよびSEMMNSパラメータの設定」を参照してください。

-instance hostname[.instancename]オプションを指定してttGridAdmin dbCreateコマンドを使用すると、そのデータ・インスタンスでの要素の作成を再試行できます。「要素の作成の再試行」を参照してください。

creating

要素を作成中です。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素が作成されたことを確認します。

destroy failed

要素を破棄しようとして失敗しました。

障害の詳細は、ttGridAdmin dbStatusコマンド出力を参照してください。

要素ステータスがdestroy failedの場合は、-instance hostname[.instancename]オプションを指定したttGridAdmin dbDestroyコマンドを使用して、そのデータ・インスタンスでの要素の破棄を再試行できます。「除去された要素または破棄が失敗した要素の破棄」を参照してください。

destroyed

要素が破棄されました。

要素は存在しません。

ノート: データベースの最後の要素が破棄されると、要素ステータスを含め、データベースのレコードは何も存在しなくなります。

destroying

要素を破棄中です。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素が破棄されたことを確認します。

down

この要素が配置されているデータ・インスタンスが実行されていません。

データ・インスタンスが停止している場合、要素のステータスはdownです。

instanceExecコマンドを使用してデータ・インスタンスを再起動し、ttDaemonAdmin -startコマンドを実行してみてください。instanceExecのオプション-only hostname[.instancename]を使用します。

「停止しているデータ・インスタンスの再起動」および「データ・インスタンスが停止している場合のリカバリ」を参照してください。

evicted

要素はttGridAdmin dbDistributeにより除去または削除され、分散マップから削除されました。

要素ステータスがevictedの場合は、-instance hostname[.instancename]オプションを指定したttGridAdmin dbDestroyコマンドを使用して、データ・インスタンスの要素を破棄します。「除去された要素または破棄が失敗した要素の破棄」を参照してください。

evicted (loaded)

要素はttGridAdmin dbDistributeにより除去または削除されましたが、分散マップからの削除はまだ開始されていません。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素がアンロードされたことを確認します。

要素ステータスがevictedの場合は、-instance hostname[.instancename]オプションを指定したttGridAdmin dbDestroyコマンドを使用して、要素を破棄します。「除去された要素または破棄が失敗した要素の破棄」を参照してください。

evicted (unloading)

要素はttGridAdmin dbDistributeにより除去または削除され、分散マップから削除中です。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素がアンロードされたことを確認します。

要素ステータスがevictedの場合は、-instance hostname[.instancename]オプションを指定したttGridAdmin dbDestroyコマンドを使用して、データ・インスタンスの要素を破棄します。「除去された要素または破棄が失敗した要素の破棄」を参照してください。

load failed

要素をロードしようとして失敗しました。

障害の詳細は、ttGridAdmin dbStatusコマンド出力を参照してください。

-instance hostname[.instancename]オプションを指定したttGridAdmin dbLoadコマンドを使用して、要素のロードを再度試行できます。

loaded

要素がロードされました。

要素はロードされ、オープンできるようになりました。ttGridAdmin dbStatus -replicasetコマンドを使用して、分散マップに要素が含まれているかどうかを確認できます。

loading

要素をロード中です。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素がロードされたことを確認します。

opened

要素はオープンしています。

機能している要素の標準ステータスです。要素を介してデータベース接続が可能です。

open failed

要素をオープンしようとして失敗しました。

障害の詳細は、ttGridAdmin dbStatusコマンド出力を参照してください。

ttGridAdmin dbOpenを再度試行できます。

opening

要素をオープン中です。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素がオープンしたことを確認します。

uncreated

要素を作成する必要がありますが、作成はまだ開始されていません。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、作成が開始されたことを確認します(ステータスはcreating)。

unloaded

要素はアンロードされました。

データベースを再度ロード(ttGridAdmin dbLoad)または破棄(ttGridAdmin dbDestroy)できるようになりました。

ttGridAdmin dbLoadコマンドを実行して、データベースを再ロードできます。

unloading

要素をアンロード中です。

しばらく待ってから、ttGridAdmin dbStatusコマンドを再度実行して、要素がアンロードされたことを確認します。

waiting for seed

要素はロードされますが、レプリカ・セット内のシード要素がロードされる後まではロードされません。

レプリカ・セット内のシード要素のステータスに注意してください。最新の変更で失敗したレプリカ・セットの要素は、シード要素と呼ばれます。シード要素は最初に、チェックポイントおよびトランザクション・ログ・ファイルの最新のトランザクションでリカバリされます。

  • シード要素のステータスがloadingの場合、失敗した要素は、シード要素のステータスがloadedになるとすぐにロードされます。

  • シード要素のステータスがload failedの場合は、その問題に対処してください。前述のload failedのエントリを参照してください。

  • シード要素のステータスがdownの場合、失敗した要素はリカバリできません。この表のdown要素ステータスに示されている情報に従って、データ・インスタンスを再起動してください。

  • レプリカ・セット内のすべての要素がwaiting for seed状態の場合、レプリカ・セットをリカバリする方法は次のいずれかのみです。

    - ttGridAdmin dbLoadコマンドを使用してデータベースをリロードします。「データベースのリカバリ」を参照してください。

    - データベースをリロードしても要素がリカバリされない場合や、Durability=0の場合は、ttGridAdmin dbDistribute -evictunLoadおよびdbLoadコマンドを使用して、レプリカ・セットを削除し、データベースをアンロードしてから再ロードする必要があることがあります。「Durability=0の場合の障害が発生したレプリカ・セットのリカバリ」を参照してください。

ノート:

ノートおよび推奨事項の列では、頻繁に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

「レプリカ・セットに永続的な障害が発生した要素がある場合のリカバリ」を参照してください。

要素が停止した後のレプリカ・セットのリカバリ

k >= 2の場合、同じレプリカ・セット内のすべてのアクティブな要素は、トランザクション上同期されます。レプリカ・セット内の1つの要素に適用されるDML文またはDDL文はすべて、レプリカ・セット内の他のすべての要素にも適用されます。レプリカ・セット内の1つの要素が稼働していない場合、レプリカ・セット内の別の要素がDML文またはDDL文の実行を続行します。
  • 障害が発生した要素がリカバリされた場合、その要素はしばらくの間使用不可能になり、トランザクション上の遅れが生じます。この要素がグリッド内のレプリカ・セットにおける役割を再開するためには、レプリカ・セットのアクティブな要素とデータを同期する必要があります。

  • 要素にファイル・システム障害などの永続的な障害が発生した場合は、ttGridAdmin dbDistribute -remove -replaceWithコマンドを使用して、レプリカ・セットからその要素を削除し、別の要素に置き換える必要があります。「別の要素での要素の置換」を参照してください。

TimesTen Scaleoutでは、次の方法を使用して、レプリカ・セット内のリストアされた要素または新しい要素のデータが自動的に再同期およびリストアされます。

  • ログベースのキャッチ・アップ: このプロセスでは、レプリカ・セット内のアクティブな要素からトランザクション・ログを転送し、リカバリされる要素に欠落しているトランザクション・レコードを適用します。この操作によって、要素がレプリカ・セットに参加していなかったときに実行されたDML文またはDDL文が適用されます。ただし、TimesTen Scaleoutでは、リカバリする要素がログベースのキャッチ・アップでリカバリされている間は、新しいDDL文はブロックされます。

    レプリカ・セットのいずれかの要素が停止していたときに開始されたトランザクションは、停止していた要素のリカバリ時に再実行する必要があります。ログベースのキャッチアップ・プロセスでは、すべてのオープン・トランザクションがコミットまたはロールバックするまで待機してから、それらのトランザクションをトランザクション・ログから再実行します。停止している要素が長時間にわたってリカバリ処理中の場合は、リカバリされる要素に対するログベースのキャッチアップ・プロセスの完了を妨げるオープン・トランザクションが(アクティブな要素に)存在してる可能性があります。ttXactAdminユーティリティを使用して、オープン・トランザクションがないか確認します。すべてのオープン・トランザクションを、コミットするかロールバックして解決します。

  • 複製: TimesTen Scaleoutは、リカバリされる要素または障害が発生した要素を置換する新しい要素のいずれかに、アクティブな要素を複製します。複製操作では、アクティブな要素のすべてのチェックポイントおよびログ・ファイルがリカバリされる要素にコピーされます。

    ただし、アクティブな要素は複製操作中も引き続きトランザクションを受け入れるため、コピーされたトランザクション・ログ・ファイルに含まれない追加のトランザクション・ログ・レコードが存在する可能性があります。複製操作が完了すると、TimesTen Scaleoutはアクティブな要素に接続してログベースのキャッチアップ操作を実行し、新しい要素を完全に最新の状態に更新します。

レプリカ・セット内の障害が発生した要素の削除および置換

k >= 2の場合に、要素を自動的にリカバリできないときは、障害の原因を調査する必要があります。

ドライブを再マウントする必要があるなど、修正できる問題が見つかる場合もあります。ただし、ドライブが完全に破壊されているなど、修正できない問題が見つかることもあります。永続的でリカバリ不可能な障害のほとんどは、通常はハードウェアの障害に関連しています。

  • 修正可能な場合は、ホストまたはデータ・インスタンスの問題を修正してから、次のいずれかを実行します。

  • ホストまたはデータ・インスタンスに関する問題を修正できない場合は、要素のデータが取得できない状態になっている可能性があります。この場合は、要素を削除して、別の要素に置換する必要があります。置換されると、アクティブな要素によって、このレプリカ・セットのデータで新しい要素が更新されます。

いずれかのホストで複数のエラーが発生している場合(自動的にリカバリ可能であった場合でも)、より信頼性が高い別のホストに置き換えることをお薦めします。

データを失うことなく要素を置換するには、ttGridAdmin dbDistribute -remove -replaceWithコマンドを実行します。これは、置換する要素に存在するデータを取得して、新しい要素に再分散します。「別の要素での要素の置換」を参照してください。