メンテナンスのためにVerticaノード停止する場合の対処方法

Posted June 18, 2018 by Soniya Shah, Information Developer

メンテナンスのためにVerticaノードをシャットダウンする必要がある場合、このチェックリストが役立ちます。

ステップ タスク 結果
1 すべてのノードがUPであることを確認します。 $ /opt/vertica/bin/admintools -t view_cluster シャットダウン後の長時間にわたるノードリカバリを避けるには、1つ以上のノードが停止している場合、Restarting Vertica on a Host 内の説明にしたがって、なるべく早く検知し、再起動します。
2 ノードを再起動できない場合、
  • AHMが長い間進んでいないかどうか確認します。 => SELECT current_epoch, ahm_epoch, last_good_epoch FROM system;
  • デリートベクター数を確認します。 => SELECT COUNT(*) FROM delete_vectors;
  • AHMが長時間保持されていて、デリートベクター数が多く、また、複数のテーブルにまたがっている場合、ノードリカバリが遅延する可能性があります。 この場合、ノードリカバリのチェックリスト内の手順に従います。 次の内容があてはまるとします。
  • データの3%以上に影響を与える削除や更新を行っています。
  • ノードが長い間停止しています。
  • 多くの更新と削除を行うステージングテーブルがある場合、ノードをリカバリする前にテーブルを削除します。
  • 最後の選択肢は、次のコマンドでAHMを強制的に進めることです。 => SELECT MAKE_AHM_NOW(true); 続いて、停止ノードをリカバリすると、Verticaはバディーノードからデータをコピーすることによって、そのノードを初期状態からリカバリします。
    3 ノードの依存関係を確認します。 => SELECT GET_NODE_DEPENDENCIES(); 想定するノード依存関係の場合、(ノードの数 + 1)行をリストします。 ノードの依存関係が正しい場合、Step 4 へ。 ノードの依存関係が正しくない場合、クラスター内のデータをリバランスします。 => SELECT REBALANCE_CLUSTER(); クラスターで再度リバランスを実行してもノードの依存関係が正しくない場合、Verticaテクニカルサポートまでお問い合わせください。
    4 データの損失を避けるために、データベースをバックアップします。 $ vbr -t backup --config $FULLBAK_CONFIGより詳細な情報については、Backing Up the Database をご確認ください。Creating Hard-Link Local Backups に記載があるように、ハードリンクのバックアップを使用して、バックアップ処理をスピードアップすることを検討してください。 バックアップが成功した場合、Step 5 へ。 バックアップが完了しない場合、データベースが停止している場合は、コールドバックアップまたはオフラインバックアップを実行します。 これを行うには、カタログディレクトリとデータディレクトリを別の場所にコピーします。
    Vertica 7.2.xおよびそれ以前の場合: => SELECT name, catalogpath, bdbpath FROM vs_NODES; Vertica 8.0.x以降の場合: => SELECT name, catalogpath FROM vs_NODES;
    5 データベースをシャットダウンする準備をします。
    a. セッションの最大数の設定内容を表示します。 => SHOW CURRENT "MaxClientSessions"; 追加でユーザーがデータベースに接続できないようにするには、MaxClientSessionsを0に設定します。 => ALTER DATABASE <database_name>/< SET MaxClientSessions=0; 注意: MaxClientSessions = 0 としても、dbadminセッションを5つまでは許可します。
    b. シャットダウン処理は、Tuple Moverを実行します。ただし、シャットダウン処理をコントロールするために、Tuple Moverを手動で実行して、WOSからROSへすべてのプロジェクションのデータを移動します。 => SELECT DO_TM_TASK('moveout');テーブル名を省略した場合、Tuple MoverはWOS上のすべてのデータを移動します。
    c. RESOURCE_USAGEシステムテーブルを参照してWOSで使用されているバイトをチェックすることで、Tuple MoverですべてのWOS上のデータがROSへ移動されたことを確認します。 => SELECT node_name, SUM(memory_inuse_kb) FROM resource_pool_status WHERE pool_name = 'wosdata' GROUP BY 1 ORDER BY 1 ; node_name | sum --------------------+----- v_vmart_db_node0001 | 0 v_vmart_db_node0002 | 0 v_vmart_db_node0003 | 0 v_vmart_db_node0004 | 0 v_vmart_db_node0005 | 0
    d. Mergeoutが実行されていないことを確認します。Mergeoutが完了するまで、シャットダウンは実行できません。 => SELECT * FROM tuple_mover_operations WHERE is_executing; Mergeout処理が実行されている場合、完了するまで待つか、Step 5f の内容にしたがって、セッションをクローズしてmergeout処理をキャンセルします。
    e. SESSIONSシステムテーブルを参照して、まだ実行中のセッションを確認します。 => SELECT * FROM SESSIONS; オープン中のセッションが存在する場合、Step 5f へ。 オープン中のセッションが存在しない場合、Step 5g へ。
    f. オープン中のセッションをすべてクローズします。 => SELECT CLOSE_ALL_SESSIONS(); あるいは、特定のセッションをクローズします。 => SELECT CLOSE_SESSION(‘session_id’); Mergeoutのセッションをクローズするためには、TUPLE_MOVER_OPERATIONSシステムテーブルから「session_id」の値を確認します。
    g. すべてのセッションがクローズされていることを確認します。 => SELECT * FROM SESSIONS; まだオープン中のセッションが存在する場合、Step 5b へ戻り継続します。 それ以外の場合、Step 5h へ。
    h. ステップ5bから5gまでの実施に長い時間がかかると、新しいデータロード、あるいは、Tuple Mover処理が開始された可能性があります。この場合、Step 5b に戻ります。 $ /opt/vertica/bin/admintools -t view_cluster
    i. Ancient history mark(AHM)を進ませて、replay deleteを回避します。 => SELECT MAKE_AHM_NOW(); 注意:ノードが停止している場合、この手順は失敗します。 => SELECT MAKE_AHM_NOW(‘true’); 上記のクエリはAHMを進めますが、Step 2 で説明されているように、スクラッチからのリカバリを強制することになります。
    6 データベースをシャットダウンします。 => SELECT SHUTDOWN();
    7 各ノード上でVerticaプロセスが正しくシャットダウンされていることを確認します。 $ for host in `grep -P "^v_" /opt/vertica/config/admintools.conf|awk '{print $3}'|awk -F, '{print $1}'`;do echo ---- $host ---- ; ssh $host "ps -ef | grep /opt/vertica/bin/vertica"; done 各ノードでVerticaが正常にシャットダウンされている場合、Step 11 に進みます。 それ以外の場合、Step 8 へ。
    8 まだVerticaプロセスが実行中のノードに接続します。次のコマンドを実行して、Verticaプロセスの実行中の内容を確認します。 $ tail –f vertica.log vertica.logに何らかのアクティビティが出力されている場合、完了するまで待ちます。 プロセスが完了するのを待つことができない場合、vstack情報を収集しVerticaテクニカルサポートまでお問い合わせください。その際、シャットダウンプロセスが正常に完了しなかったことを知らせてください。 $ /opt/vertica/bin/vstack > /tmp/vstack_nodexx.log その後、Step 9 に進みます。
    9 シャットダウンプロセスを停止するには、admintoolsを起動し、「Advanced Menu」から「Kill Vertica Process on Host」を選択し、Verticaプロセスを停止します。 データベースが安全でなくなるように2つのバディーノードでVerticaプロセスをシャットダウンすると、Verticaは他のすべてのノード上でVerticaプロセスを自動的にシャットダウンします。
    10 Step 7 のコマンドを使用して、すべてのノードでVerticaプロセスが停止したことを確認します。
    11 必要なメンテナンスを実施後、Restart Vertica on a Node の手順に従って、データベースを再起動します。 チェックリストは完了です。