すべてのノードがUPしているかどうかを確認します。1つ以上のノードがDOWNの場合、下記コマンドを使用してすべてのノードをUPにします。リフレッシュが実行されていないプロジェクションがないかどうか確認します。f」となっている場合、次のいずれかを実行します。AHMが進んでいる場合、チェックリストは完了です。AHMが進んでいない場合、このチェックリストを再度開始して、別のパスを探します。AHMが進まない場合、Verticaテクニカルサポートまでお問い合わせください。WOS上にデータがないかどうか確認します。WOS上にデータがある場合、MOVEOUTを手動実行します。LGEが他のノードよりも古いノードを確認します。すべてのノードが同じLGEである場合、Verticaテクニカルサポートまでお問い合わせください。deleteで遅延していないことを確認します。このチェックリストは完了です。Moveoutが実行されていない場合、Verticaテクニカルサポートまでお問い合わせください。2018Verticaクラスターにノードを追加したり、クラスターからノードを削除したりすると、Verticaはすべてのノード上でデータのリバランスを実施します。リバランスに長時間を要する場合、これらの手順を参照して原因を調べます。リバランスを開始する前に、クラスターの正常なリバランスを確実に行うために、以下のステップを実行してください。ETLジョブと競合しない時間帯にリバランスをスケジューリングします。データベースをバックアップします。古い、あるいは、未使用のテーブルパーティションを削除します。ローカルセグメンテーションが無効であることを確認します。ローカルセグメンテーションが無効になっていない場合、このコマンドを実行して無効にします。vioperfとvnetperfを使用して、CPUとネットワークの帯域幅をそれぞれ確認します。使用可能な帯域幅が初期ベンチマークの値よりも小さい場合、システム管理者に連絡して、性能が低下している原因となる問題を見つけて修正してください。リバランスを実行するために、データベースのサイズの少なくとも40%のストレージが使用可能であるかどうかを確認します。ストレージの使用状況を確認するには、次のクエリを実行します。Linuxファイルシステムで使用可能なディスク容量を確認します。HOST_RESOURCESシステムテーブルから各ノードのスナップショットを取得します。ストレージが不足している場合、カタログサイズを縮小するための手順を実行してください。不要なデータ、一時的なデータ、ステージングデータを削除する。ログファイルをクリーンアップする。不要なテーブルまたはパーティションを削除する。新しいドライブを追加し、ストレージのロケーションを追加し、一部のカタログオブジェクトを新しいロケーションに移行する。リバランスの間に使用される一時スペース用の一時格納領域を追加する。ビルトインのREFRESHリソースプールの設定を確認します。必要に応じて、リバランス処理が滞りなく実行できるように、リソースプール設定を調整します。リバランス対象のテーブルに対するDML処理(COPY、INSERT、UPDATE、DELETE)を最小限に抑えます。リバランスがテーブルのロックを保持している場合、ロードは失敗します。ロードがテーブルをロックしている場合、リバランスは一時停止します。リバランスがETLジョブと競合していると考えられる場合、LockTimeout値を増やしてください。デフォルト値は、300秒(5分)です。説明にしたがって、DeleteされたデータをPurgeします。クラスターに追加するホストを構成します。ホストをクラスターに追加します。データベースにノードを追加します。リバランスを途切れることなく実行するには、DMLCancelTMパラメーターをfalseに設定して、リバランスプロセスを優先します。これで、リバランス処理を開始する準備が整いました。ここでは、リバランスを開始し、プロセスが正常に完了するのをモニタリングするための手順を示します。説明に従って、リバランスを開始します。Verticaがリバランスを実行しているテーブルをモニタリングします。このクエリは、Verticaがリバランス実行しているテーブルと、転送されたデータの量に関する情報を返します。DML処理またはDDL処理で特定のテーブルのリバランスが妨げられた場合、次のようなエラーメッセージが表示されます。このエラーが表示された場合、DML処理またはDDL処理を停止し、リバランスを再開してください。これらの処理が実行されない時間帯までリバランスを延期します。次のシステムテーブルをモニタリングして、個々のテーブルとプロジェクションの進捗状況を確認します。