See More Japanese Checklists Posts
View All Vertica Blog Posts
新規ノードをクラスターに追加する場合の対処方法
Soniya Shah, Information Developer
June 18, 2018
より多くのストレージを必要としますか?追加のストレージが必要な場合、データベースにノードを追加することを検討してください。新しいノードは、すべて同時に追加することをご推奨します。 このチェックリストを使用して、ノードを追加することができます。これらは基本的なステップです。Vertica Documentation には、追加のオプションが掲載されています。 ステップ タスク 結果 1 既存のデータベースの完全なローカルバックアップを取得します。 デフォルトでは、進行状況バー以外の出力は表示されません。追加の進行状況情報を含めるには、1-3の間の値が指定可能な「--debugオプション」を使用します。 バックアップユーティリティを実行している際にconfigファイルを指定します。 ファイルが存在しない場合、バックアップはエラーで失敗します。エラーを解決し、Step 2 に進みます。 2 古い、あるいは、未使用のテーブルパーティションを削除します。 テーブルパーティションが削除された場合、Step 3 に進みます。 テーブルパーティションが削除されていない場合、テーブル名とパーティションの値を確認して、もう一度やり直してください。 3 ローカルセグメンテーションが無効であることを確認します。無効になっていない場合、無効にします。 ローカルセグメンテーションが無効になっていることを確認後、Step 4 に進みます。 4 クラスターのネットワーク帯域幅とCPUパフォーマンスを確認します。 ノード間のネットワークのレイテンシとスループットを測定し、ハードドライブの速度を測定します。 レイテンシとスループットが初期ベンチマークよりも低い場合、システム管理者に連絡し、性能劣化の問題を解決してください。 5 リバランスを実行するのに十分なストレージ(データベースのサイズの少なくとも40%)があるかどうかを確認します。 各ノードのスナップショットを取得するには、HOST_RESOURCESシステムテーブルの次のフィールドを確認します。 各ノードのディスクストレージの容量がリバランスを実行するのに十分であることを確認します。十分である場合、Step 6に進みます。 ストレージがない場合、カタログサイズを縮小してください。詳細については、リバランス処理遅延の対処方法チェックリストを参照してください。 6 リバランス対象のテーブルのDML処理を最小限に抑えます。リバランスがテーブルをロックしている場合、ロードは失敗します。 リバランスがETLジョブと競合する可能性がある場合、構成パラメーターLockTimeoutの値を増やします。 進行中のDML処理を対処後、Step 7に進みます。 デフォルト値は300秒(5分)です。 7 データベースを停止します。 データベース停止後、Step 8に進みます。 8 update_verticaスクリプトを使用して、ホストを構成し、ホストをクラスターに追加します。 a. update_verticaスクリプトを使用して、ホストを追加します。 b. データベースにノードを追加します。 「-sオプション」を使用すると、追加するノードの順序を指定できます。 ノードをデータベースに追加後、Verticaは更新された構成ファイルをクラスタ内ーの他のノードに自動的に分配し、クラスター内のデータのリバランスプロセスを開始します。 ホストとノードの追加後、Step 9 に進みます。 9 個々のテーブルのリバランスの進捗状況をモニタリングできます。 モニタリング実施後、Step...
AHM(Ancient History Mark)が進まない場合の対処方法
Soniya Shah, Information Developer
June 18, 2018
AHMが進んでいない場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Last Good Epoch(LGE)が進んでいるかどうかを確認します。 LGEが進んでいる場合、Step 2 へ。 LGEが進んでいない場合、Step 5 へ。 2 すべてのノードがUPしているかどうかを確認します。 すべてのノードがUPの場合、Step 3 へ。 1つ以上のノードがDOWNの場合、下記コマンドを使用してすべてのノードをUPにします。 すべてのノードがUPになった後、Step 4 へ。 3 リフレッシュが実行されていないプロジェクションがないかどうか確認します。 1つ以上のプロジェクションが「IS_UP_TO_DATE = f」となっている場合、次のいずれかを実行します。 プロジェクションの削除 プロジェクションのリフレッシュ 4 AHMは進みましたか? AHMが進んでいる場合、チェックリストは完了です。 AHMが進んでいない場合、このチェックリストを再度開始して、別のパスを探します。AHMが進まない場合、Verticaテクニカルサポートまでお問い合わせください。 5 WOS上にデータがないかどうか確認します。 WOS上にデータがある場合、MOVEOUTを手動実行します。 WOS上にデータがない場合、Step 6 へ。 6 LGEが他のノードよりも古いノードを確認します。 任意のノードのLGEが別のノードのLGEよりも古い場合、Step 7 へ。 すべてのノードが同じLGEである場合、Verticaテクニカルサポートまでお問い合わせください。 7 Moveoutが実行中で、moveout処理がreplay deleteで遅延していないことを確認します。 Moveoutが実行され、AHMが進んでいる場合、 このチェックリストは完了です。Moveoutが実行されていない場合、Verticaテクニカルサポートまでお問い合わせください。 関連詳細情報 Vertica Documentation の Epochs をご参照ください。
メンテナンスのためにVerticaノード停止する場合の対処方法
Soniya Shah, Information Developer
June 18, 2018
メンテナンスのためにVerticaノードをシャットダウンする必要がある場合、このチェックリストが役立ちます。 ステップ タスク 結果 1 すべてのノードがUPであることを確認します。 シャットダウン後の長時間にわたるノードリカバリを避けるには、1つ以上のノードが停止している場合、Restarting Vertica on a Host 内の説明にしたがって、なるべく早く検知し、再起動します。 2 ノードを再起動できない場合、 AHMが長い間進んでいないかどうか確認します。 デリートベクター数を確認します。 AHMが長時間保持されていて、デリートベクター数が多く、また、複数のテーブルにまたがっている場合、ノードリカバリが遅延する可能性があります。 この場合、ノードリカバリのチェックリスト内の手順に従います。 次の内容があてはまるとします。 データの3%以上に影響を与える削除や更新を行っています。 ノードが長い間停止しています。 多くの更新と削除を行うステージングテーブルがある場合、ノードをリカバリする前にテーブルを削除します。 最後の選択肢は、次のコマンドでAHMを強制的に進めることです。 続いて、停止ノードをリカバリすると、Verticaはバディーノードからデータをコピーすることによって、そのノードを初期状態からリカバリします。 3 ノードの依存関係を確認します。 想定するノード依存関係の場合、(ノードの数 + 1)行をリストします。 ノードの依存関係が正しい場合、Step 4 へ。 ノードの依存関係が正しくない場合、クラスター内のデータをリバランスします。 クラスターで再度リバランスを実行してもノードの依存関係が正しくない場合、Verticaテクニカルサポートまでお問い合わせください。 4 データの損失を避けるために、データベースをバックアップします。 より詳細な情報については、Backing Up the Database をご確認ください。Creating Hard-Link Local Backups に記載があるように、ハードリンクのバックアップを使用して、バックアップ処理をスピードアップすることを検討してください。 バックアップが成功した場合、Step 5 へ。 バックアップが完了しない場合、データベースが停止している場合は、コールドバックアップまたはオフラインバックアップを実行します。 これを行うには、カタログディレクトリとデータディレクトリを別の場所にコピーします。 Vertica 7.2.xおよびそれ以前の場合: Vertica 8.0.x以降の場合: 5 データベースをシャットダウンする準備をします。 a. セッションの最大数の設定内容を表示します。...
ノードのリカバリ処理遅延の対処方法
Soniya Shah, Information Developer
June 18, 2018
7.2.x以降を使用している場合、テーブルごとにリカバリを実行してください。詳細については、Vertica Documentation の Recovery By Table を参照ください。 7.1.xより前のVerticaバージョンを使用している場合、ETLジョブ等の更新処理を行う処理を停止してノードリカバリを再開してください。 ステップ タスク 結果 1 リカバリの進捗状況をモニターします。 「is_running = f」 の場合、リカバリは完了しています。 このステートメントを繰り返し実行し、current_completedの値が増加しているかどうかを確認します。増加している場合、リカバリが進行中であることを意味します。 リカバリは進行中ですか? リカバリが進行していない場合、Step 3 へ。 リカバリが進行している、あるいは、終了している場合、Step 2 へ。 2 ノードリカバリは正常に完了しましたか? 正常に完了している場合、チェックリストは完了です。 正常に完了しておらず、リカバリがエラーで終了している場合、Step 6 へ。 3 リカバリは予想よりも遅いですか? 遅くない場合、Step 4 へ。 遅い場合、次の内容を実施します。 iostatを使用し、ディスクI/Oをチェックします。問題がある場合、ディスクI/Oスケジューラをdeadline(HDDの場合)あるいはnoop(SSDの場合)に変更します。 同時に実行されているクエリの数が最大数、あるいはそれに近いかどうかを確認します。 「max_concurrency = running_query_count」の場合、クエリのロードが非常に高いと言えます。 a. MAXCONCURRENCY の増加 b. リカバリの再開 c. Step 1 へ 4 リカバリは特定のテーブルでとまっているように見えますか? 特定のテーブルでとまっていない場合、Step 6 へ。 特定のテーブルでとまっている場合、ノードがリカバリ中であるかどうか確認します。 「node_state=RECOVERING」の場合、ノードリカバリが進行中であることが分かります。 5 ノードがリカバリのHistoricalフェーズにあるかどうかを確認します。 「historical_completed」の値が、「historical_total」の値よりも小さい場合、ノードはHistoricalフェーズにあるといえます。Verticaがストレージコンテナを隣接ノードからコピーしているフェーズとなります。 「historical_complete...