1. Scaleoutユーザーズ・ガイド
  2. 障害からのリカバリ
  3. 停止しているレプリカ・セットからのリカバリ

停止しているレプリカ・セットからのリカバリ

単一のレプリカ・セット内のすべての要素が停止しているか、障害が発生している場合、停止しているレプリカ・セットに格納されているデータは使用できなくなります。レプリカ・セット全体に障害が発生しないようにするには、レプリカ・セット全体の障害が発生する可能性を軽減するような方法で要素を分散させます。

「データ領域グループへのホストの割当て」を参照してください。

表13-3で説明しているように、停止しているか、障害が発生しているレプリカ・セットがある場合、データを正常に保持できるかどうかは、Durability接続属性の設定によって決まります。「永続性の設定」を参照してください。

表13-3 Durabilityの値に基づくトランザクションのリカバリの可能性

Durabilityの値 レプリカ・セットに障害が発生した場合のトランザクションへの影響

1

参加者は、分散トランザクションのトランザクション・ログに、コミットの準備ログ・レコードまたはコミット・ログ・レコードを同期的に書き込みます。こうすることで、コミットされたトランザクションが保持される可能性を最大限に高めることができます。レプリカ・セットが停止した場合、すべてのトランザクション・ログ・レコードが永続的にファイル・システムにコミットされているため、TimesTen Scaleoutによってリカバリできます。

0

参加者は、分散トランザクションのコミットの準備ログ・レコードおよびコミット・ログ・レコードを非同期的に書き込みます。レプリカ・セット全体が停止した場合、トランザクション・ログ・レコードが永続的にファイル・システムにコミットされる保証はありません。レプリカ・セット内の要素に障害が発生したまたは停止した状況によっては、データ損失の可能性があります。

次の各項では、レプリカ・セットが停止した後に新しいトランザクションで何が行われるか、また、Durability接続属性の値に基づいたレプリカ・セットのリカバリ方法について説明します。

停止しているレプリカ・セットがある場合のトランザクションの動作

次のリストでは、停止しているレプリカ・セットがある場合のトランザクションの動作を説明しています。

  • アクティブなレプリカ・セット内の行のみにアクセスする(停止しているレプリカ・セット内の行にはアクセスしない)問合せのトランザクションは成功します。停止しているレプリカ・セット内のデータにアクセスしようとする問合せは失敗します。アプリケーションは、レプリカ・セットがリカバリされたときにトランザクションを再試行する必要があります。

    停止しているレプリカ・セットからのデータを必要としない、部分的な結果のヒントを持つグローバル読取りは成功します。

    たとえば、レプリカ・セット1のすべての要素で障害が発生しており、トランザクション内の問合せにレプリカ・セット1からのデータが必要な場合、そのトランザクションは失敗します。アプリケーションがトランザクションを再度実行する必要があります。

  • DDL文ではすべてのレプリカ・セットが使用可能である必要があるため、DDL文を使用したトランザクションは停止したレプリカ・セットがある場合は失敗します。アプリケーションがトランザクションをロールバックする必要があります。

  • DML文を含むトランザクションは、停止しているレプリカ・セット内の要素で1つ以上の行を更新しようとすると、失敗します。アプリケーションがトランザクションをロールバックする必要があります。Durability=0の場合、このシナリオでは、データ損失が発生する可能性があります。「Durability=0の場合の障害が発生したレプリカ・セットのリカバリ」を参照してください。

  • Durability=1の場合、停止しているレプリカ・セットからのデータを必要としない、DMLを含むトランザクションは成功します。たとえば、レプリカ・セット1のすべての要素に障害が発生した場合、SELECT、INSERT、INSERT...SELECT、UPDATEまたはDELETEのいずれの文もレプリカ・セット1に格納されたデータに依存していない場合にのみ、トランザクションは成功します。

Durability=1の場合の障害が発生したレプリカ・セットの永続的なリカバリ

次の各項では、Durability=1の場合の、障害が発生したレプリカ・セットのリカバリ・プロセスについて説明します。

レプリカ・セット内のすべての要素が一時的にでも停止した場合、TimesTen Scaleoutでは、次のようにして完全なレプリカ・セットを自動的にリカバリできることがあります(最初の問題が解決されている場合)。

  1. シード要素を判別してリカバリします。シード要素と呼ばれる、障害が発生した要素の中で最新の変更を持つ要素が最初にリカバリされます。シード要素は、チェックポイントおよびトランザクション・ログ・ファイルの最新のトランザクションにリカバリされます。

  2. 要素のリカバリが完了すると、TimesTen Scaleoutはインダウト・トランザクションがないか確認します。

    一時障害または予期しない終了の後で、要素がファイル・システム(チェックポイントおよびトランザクションログ・ファイル)からロードされた場合、準備されていたが、コミットされていない2フェーズ・コミット・トランザクションはすべて保留のままになります。これは、インダウト・トランザクションと呼ばれます。トランザクションが中断された場合、2フェーズ・コミットのプロトコルによってトランザクション全体がコミットされたかどうかが疑わしいことがあります。

    • インダウト・トランザクションがない場合、処理は通常どおり続行されます。

    • インダウト・トランザクションがある場合、すべてのインダウト・トランザクションが解決されるまで、このレプリカ・セットを含む標準処理は続行されません。インダウト・トランザクションがある場合、TimesTen Scaleoutはトランザクション・ログを確認して、いずれかの参加者でトランザクションがコミットされたか、コミットする準備ができているかを判別します。トランザクション・ログ・レコードには、トランザクション内の他の参加者に関する情報が含まれています。TimesTen Scaleoutによるインダウト・トランザクションの解決方法は、表13-4を参照してください。

      このプロセス中に要素に障害が発生し、トランザクションがコミットまたはロールバックされた後に再度起動した場合、要素は参加している他の要素の結果をリクエストすることでそれ自体をリカバリします。

  3. シード要素がリカバリされると、レプリカ・セット内の他の要素は、複製およびログベースのキャッチアップ方法を使用して、シード要素からリカバリされます。複製の方法とログベースのキャッチ・アップの方法の詳細は、「要素が停止した後のレプリカ・セットのリカバリ」を参照してください。

表13-4 TimesTen Scaleoutによるインダウト・トランザクションの解決方法

障害 処置

少なくとも1人の参加者がコミット・ログ・レコードを受信しました。他のすべての参加者は、少なくともコミットの準備ログ・レコードを受信します。

トランザクションは、すべての参加者でコミットされます

トランザクションのすべての参加者が、コミットの準備ログ・レコードを受信しました。

トランザクションは、すべての参加者でコミットされます。

少なくとも1人の参加者が、コミットの準備ログ・レコードを受信していません。

トランザクション・マネージャからすべての参加者に、トランザクションのロールバックの導入である、コミットの準備を元に戻すように通知されます。

  • autocommit 1によりトランザクションが実行された場合、トランザクション・マネージャはトランザクションをロールバックします。

  • autocommit 0によりトランザクションが実行された場合、トランザクション・マネージャは、トランザクションをロールバックする必要があることをアプリケーションに通知するエラーをスローします。

ただし、停止しているレプリカ・セット内の要素をリカバリできない場合は、いずれかの要素を削除して置換するか、レプリカ・セット全体を除去する必要がある場合があります。「レプリカ・セットに永続的な障害が発生した要素がある場合のリカバリ」を参照してください。

Durability=0の場合の障害が発生したレプリカ・セットのリカバリ

次に、Durability=0の場合の、障害が発生したレプリカ・セットのリカバリ・プロセスについて説明します。

Durability=0と設定した場合は、レプリカ・セットに障害が発生した場合にデータ損失の可能性があることを認めることになります。ただし、TimesTen Scaleoutでは、複数の異なる時点で要素に障害が発生した場合、データ損失を回避しようとします。

  • レプリカ・セット内の1つを除くすべての要素に障害が発生した場合、TimesTen Scaleoutは、レプリカ・セット内の最後の残りの要素(k >= 2の場合)を永続モードに切り替えようとします。つまり、(Durability=0の場合に最後の残りの要素で障害が発生すると生じる)データ損失を制限するために、TimesTen Scaleoutでは、Durability=1と構成されているかのように、要素の永続性の動作を変更します。

    TimesTen Scaleoutがレプリカ・セット内の最後の残りの要素を永続モードに切り替えることができる場合、参加している要素は、分散トランザクションのファイル・システムにコミットの準備ログ・レコードを同期的に書き込みます。その後、この要素にも障害が発生してレプリカ・セット全体が停止した場合、TimesTen Scaleoutによってトランザクション・ログ・レコードからレプリカ・セットがリカバリされます。したがって、このシナリオではトランザクションは失われず、TimesTen Scaleoutは、Durability=1と設定された場合と同様にレプリカ・セットを自動的にリカバリします。単一の要素がリカバリされた後のリカバリの詳細は、「Durability=1の場合の障害が発生したレプリカ・セットの永続的なリカバリ」を参照してください。

  • 最後の残りの要素に障害が発生するまでに、TimesTen Scaleoutでレプリカ・セットを永続モードに切り替えることができなかった場合は、データが失われることがあり、これは、レプリカ・セットに発生している障害が一時的か永続的かで異なります。

    • 要素が非永続的である場合の一時的なレプリカ・セットの障害: レプリカ・セット内のいずれの要素も、レプリカ・セットが停止する前に関与していた分散トランザクションのコミットの準備ログ・レコードを同期的に書き込んでいないため、最後に成功したエポック・トランザクションの後にコミットされたトランザクションはすべて失われます。

      すべての要素のステータスがwaiting for seedである場合、レプリカ・セットが停止する前に永続モードへの切替えは行われていません。この場合は、エポック・リカバリが必要で、最後に成功したエポック・トランザクションの後にコミットされたトランザクションはすべて失われます。このレプリカ・セット内の要素は、いずれもトランザクション・ログを使用してリカバリできないため、リカバリされたときにwaiting for seedステータスのままになることがあります。かわりに、レプリカ・セットをリカバリまたは削除してからデータベースをアンロードして再ロードすることで、エポック・リカバリを実行する必要があります。「非永続状態のレプリカ・セットに障害が発生した場合のプロセス」を参照してください。

    • 永続的なレプリカ・セットの障害: レプリカ・セット内のどの要素もリカバリできない場合、これらの要素の除去が必要な場合があります。これにより、そのレプリカ・セットのデータが失われます。「レプリカ・セットに永続的な障害が発生した要素がある場合のリカバリ」を参照してください。

非永続状態のレプリカ・セットに障害が発生した場合のプロセス

レプリカ・セットが停止し、その状態が非永続的である場合、TimesTen Scaleoutによってレプリカ・セットの停止が認識されるまで、トランザクションがデータベースに対してコミットを続けることがあります。(エポック・トランザクションの実行が失敗した後で) TimesTen Scaleoutがレプリカ・セットの停止を認識すると、失われるトランザクションの数を最小限に抑えるために、データベースが読取り専用に切り替えられます。エポック・リカバリ時には、データベースが最後に成功したエポック・トランザクションまで再ロードされ、実質上、最後に成功したエポック・トランザクションの後にコミットされたすべてのトランザクションが失われます。このシナリオでは、EpochInterval接続属性の値によって、エポック・トランザクション間の時間のみでなく、コミットされたトランザクションが失われる可能性のあるおおよその時間の長さも決定されます。

ノート:

停止しているレプリカ・セットが原因でエポック・トランザクションが失敗した場合、データベースは読取り専用に設定されます。その他の理由でエポック・トランザクションが失敗した場合、TimesTen Scaleoutではデータベースを読取り専用に設定しません。

図13-3に、8つの期間にわたって行われるアクションを示します。

図13-3 Durability=0でレプリカ・セットに障害が発生する

図13-3の説明が続きます
「図13-3 Durability=0でレプリカ・セットに障害が発生する」の説明

  1. エポック・トランザクションは正常にコミットされます。

  2. エポック・トランザクションが正常に実行された後、トランザクションを続行できます。停止しているレプリカ・セット内の要素はいずれもトランザクション・ログを永続的にフラッシュできなかったため、最後に成功したエポック・トランザクションの後にコミットされたトランザクションはすべて、エポック・リカバリ後に失われます。

  3. レプリカ・セット1は、いずれの要素も永続モードに切り替えずに停止します。

    ノート:

    レプリカ・セットが停止している間に、順序が増分することがあります。

  4. データベースがまだ読取り専用に設定されていない場合、トランザクションはレプリカ・セットの停止後も続行できます。停止しているレプリカ・セット内の要素はいずれもトランザクション・ログを永続的にフラッシュできなかったため、最後に成功したエポック・トランザクションの後にコミットされたトランザクションはすべて、エポック・リカバリ後に失われます。

    ノート:

    「停止しているレプリカ・セットがある場合のトランザクションの動作」で説明されているように、レプリカ・セットが停止した後のトランザクションの動作は、トランザクション内の文のタイプによって異なります。

  5. 稼働していないレプリカ・セットがあるため、次のエポック・トランザクションは失敗します。TimesTen Scaleoutからすべてのデータ・インスタンスに、データベースが読取り専用になったことが通知されます。すべてのアプリケーションは、オープン・トランザクション内でDML文、DDL文またはコミット文を実行すると失敗します。ユーザーが各トランザクションをロールバックする必要があります。

    ノート:

    ttGridAdmin dbStatusコマンドには、読取り専用モードまたは読取り/書込みモードであるかどうかなど、データベースの状態が示されます。

  6. レプリカ・セットをリカバリまたは除去する必要があります。

    • 停止しているレプリカ・セットをリカバリします。複数のレプリカ・セットが停止している場合、すべてのレプリカ・セットがリカバリされるか置換されるまで、データベースは読取り/書込みモードを開始できません。

    • レプリカ・セット内のどの要素もリカバリできない場合、レプリカ・セットを除去する必要がある場合があります。除去すると、そのレプリカ・セットのデータが失われます。「レプリカ・セットに永続的な障害が発生した要素がある場合のリカバリ」を参照してください。

  7. 一貫した方法でデータベースをリカバリしてデータ損失を一部に制限するために、データベースをアンロードしてから、最後に成功したエポック・トランザクションまで再ロードすることで、エポック・リカバリを実行します。データベースをアンロードしてから、最後に成功したエポック・トランザクションまで再ロードすると、最後に成功したエポックの後にコミットされたトランザクションがすべて失われます。ttGridAdmin dbLoadコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のメモリーへのデータベースのロード(dbLoad)を参照してください。ttGridAdmin dbUnloadコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベースのアンロード(dbUnload)を参照してください。

  8. 新しいエポック・トランザクションが成功します。データベースが読取り/書込みに設定されます。通常のトランザクション動作が再開されます。

ノート:

トランザクションのデータが必ずリカバリされるようにするには、トランザクションをエポック・トランザクションに昇格させます。「エポック・トランザクション」を参照してください。