1. Kubernetesオペレータ・ユーザーズ・ガイド
  2. TimesTen Scaleoutの管理
  3. waiting for seedの状態について

waiting for seedの状態について

TimesTen Scaleoutで、レプリカ・セット全体に同時に障害が発生するという状況が考えられます。レプリカ・セット内のすべての要素に同時に障害が発生した場合は、データベース全体をアンロードしてからリロードしないと、要素をリロードできないことがあります。さらに、リロードによって、TimesTen Scaleoutで、アンロード操作前にコミットされた他のレプリカ・セットに対するトランザクションが破棄される場合があります。

TimesTen Scaleoutでのレプリカ・セット障害の詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のダウンしたレプリカ・セットからのリカバリを参照してください。

Kubernetes環境でこの状況が発生した場合のデフォルト動作では、TimesTenオペレータによってこの状況が検出され、この状況の発生時にデータベースが強制的にアンロードされてリロードされます。この動作は、レプリカ・セット内のすべての要素がwaiting for seed状態であることがオペレータで認識されるとトリガーされます。

レプリカ・セット内のすべての要素がwaiting for seed状態である場合のオペレータの動作を制御することもできます。これを行うには、TimesTenScaleoutオブジェクトの.spec.ttspec.replicaSetRecoveryデータ項目を使用し、このデータ項目に特定の値を設定します。指定可能な値を次に示します。

  • Restart: レプリカ・セット全体の障害が発生すると、オペレータによってデータベースが強制的にアンロードされリロードされます。これがデフォルトです。

  • Manual: レプリカ・セット全体の障害が発生すると、オペレータによってTimesTenScaleoutオブジェクトの状態がManualInterventionRequiredに変更されます。オペレータによってそれ以上の処理が行われてグリッドが修復されることはありません。管理者がそれを修復する必要があります。詳細は、「ManualInterventionRequired状態について」と「reexamineデータ項目の設定」を参照してください。

TimesTenScaleoutオブジェクトの.spec.ttspec.replicaSetRecoveryデータ項目の詳細は、「TimesTenScaleoutSpecSpec」を参照してください。