ノードのリカバリ処理遅延の対処方法

Posted June 18, 2018 by Soniya Shah, Information Developer

7.2.x以降を使用している場合、テーブルごとにリカバリを実行してください。詳細については、Vertica Documentation の Recovery By Table を参照ください。
7.1.xより前のVerticaバージョンを使用している場合、ETLジョブ等の更新処理を行う処理を停止してノードリカバリを再開してください。

ステップ タスク 結果
1 リカバリの進捗状況をモニターします。 => SELECT node_name, is_running FROM RECOVERY_STATUS;「is_running = f」 の場合、リカバリは完了しています。
このステートメントを繰り返し実行し、current_completedの値が増加しているかどうかを確認します。増加している場合、リカバリが進行中であることを意味します。
リカバリは進行中ですか?
リカバリが進行していない場合、Step 3 へ。

リカバリが進行している、あるいは、終了している場合、Step 2 へ。
2 ノードリカバリは正常に完了しましたか? 正常に完了している場合、チェックリストは完了です。
正常に完了しておらず、リカバリがエラーで終了している場合、Step 6 へ。
3 リカバリは予想よりも遅いですか? 遅くない場合、Step 4 へ。
遅い場合、次の内容を実施します。
  • iostatを使用し、ディスクI/Oをチェックします。問題がある場合、ディスクI/Oスケジューラをdeadline(HDDの場合)あるいはnoop(SSDの場合)に変更します。
  • 同時に実行されているクエリの数が最大数、あるいはそれに近いかどうかを確認します。=> SELECT node_name, pool_name, max_concurrency, running_query_count from RESOURCE_POOL_STATUS;
  • 「max_concurrency = running_query_count」の場合、クエリのロードが非常に高いと言えます。
  • a. MAXCONCURRENCY の増加
    b. リカバリの再開
    c. Step 1 へ
    4 リカバリは特定のテーブルでとまっているように見えますか? 特定のテーブルでとまっていない場合、Step 6 へ。
    特定のテーブルでとまっている場合、ノードがリカバリ中であるかどうか確認します。 => SELECT node_name, node_state from NODES;「node_state=RECOVERING」の場合、ノードリカバリが進行中であることが分かります。
    5 ノードがリカバリのHistoricalフェーズにあるかどうかを確認します。 => SELECT node_name, recovery_phase, historical_completed, historical_total FROM RECOVERY_STATUS;
  • 「historical_completed」の値が、「historical_total」の値よりも小さい場合、ノードはHistoricalフェーズにあるといえます。Verticaがストレージコンテナを隣接ノードからコピーしているフェーズとなります。
  • 「historical_complete = historical_total」の状態となるまで、左記のステートメントを繰り返し実行します。
  • VerticaがリカバリのHistoricalフェーズの状態である場合、完了するのを待つ必要があります。
    6 トランザクションが、replay deleteの処理で滞っていますか? Replay deleteの処理で滞っていない場合、Step 7 へ。 Replay deleteの処理で滞っている場合、データのサイズに応じて、次のいずれかの対応を実施します。
    データ量 < 1 TB の場合
  • ノードの停止
  • MAKE_AHM_NOW(true)の実行
  • ノードリカバリの再開
  • Step 2 へ

  • データ量 > 1 TB の場合
  • 新規テーブルの作成
  • 既存テーブルからデータをロード
  • 古いテーブルの削除
  • ノードリカバリの再開
  • Step 2 へ
  • 7 リカバリがロック待ちの状態であるかどうかを確認します。 => SELECT node_name, user_id, transaction_id, object_name, mode FROM DC_LOCK_REQUESTS; ロック待ちの状態でない場合、Step 6 へ。

    ロック待ちの状態の場合、
  • ユーザーにテーブルの解放の依頼
  • リカバリの再開
  • Step 1 へ
  • 8 ノードリカバリが失敗した場合、リカバリのエラーを確認します。 $ grep "Recovery Error" vertica.log エラーはロックのエラーでしょうか? ロックのエラーでない場合、Verticaテクニカルサポートまでお問い合わせください。 ロックのエラーである場合、
  • リカバリをロックしているトランザクションを確認します。
  • => SELECT node_name, user_id, transaction_id, object_name, mode FROM DC_LOCK_REQUESTS;
  • トランザクションがTuple Moverである場合、処理が完了するまで待ちます。
  • トランザクションがロードである場合、ロードを停止し、リカバリを再開し、Step 1 へ。
  • Vertica 7.2.x以降のバージョンの場合、テーブル毎にリカバリを実行します。Vertica documentationの Recovery by Table を参照ください。
  • それ以外の場合、Vertica 7.2.xより前のバージョンで実行している場合、Verticaテクニカルサポートまでお問い合わせください。
  • 関連詳細情報

    Vertica Documentation の NODE_STATES をご参照ください。