Soniya Shah

Verticaは、すべてのリリースで、新しい機能を追加し既存の機能を強化します。新機能あるいは改良された機能を使用するには、Verticaを最新リリースにアップグレードしてください。 前提条件 アップグレードする前に、次の手順を実行します。 データベースのフルバックアップを実行します。アップグレードが成功しなかった場合、フルバックアップで現在のバージョンにロールバックすることができます。ハードリンクでのバックアップの取得を検討可能です。ディスク障害が発生すると、バックアップが破損することに注意してください。 新しいバージョンのプラットフォーム要件を確認します。 カタログ用のストレージスペースを確認します。 HDFSコネクタをアンインストールします（Vertica 7.2.xより前のバージョンからアップグレードする場合のみ必要です）。 vertica-R-langなどのVerticaサーバーパッケージと依存関係のあるものについても、アンインストールを実施します。 最高のパフォーマンス結果を得るために、すぐに次のバージョンにアップグレードすることをご推奨します。 例：次の増分バージョンのVerticaにアップグレードします。たとえば、7.1から7.2または8.0から8.1にアップグレードします。詳細については、Vertica Documentation の Upgrade Paths を参照してください。 これらのタスクの完了後、データベースをシャットダウンし、次の手順を実行します。 ステップ タスク 結果 1 既存のデータベースの完全なローカルバックアップを取得し、データベースを停止します。 バックアップが成功した場合、Step 2 に進みます。 バックアップが失敗した場合、Vertica Documentation の Creating Full Backups を参照してください。 2 各ホストにインストールした追加のパッケージをアンインストールします。 この手順を省略し、追加のパッケージをアンインストールしない場合、次のステップでVerticaサーバーパッケージのインストールに失敗します。 アンインストールが成功した場合、Step 3 に進みます。 アンインストールが失敗した場合、エラーを確認し、Verticaテクニカルサポートまでお問い合わせください。 3 任意のホストに新しいVerticaサーバーパッケージをrootまたはsudoでインストールします。 1つのノードまたはすべてのノードにインストールできます。1つのノード上にインストールした場合、install_verticaスクリプトが他のノードに順番にインストールします。すべてのノード上に同時にインストールした場合、スクリプトがrpmをコピーする必要がないため、install_verticaスクリプトの実行が高速になります。 インストールが成功した場合、Step 4 に進みます。 インストールが失敗した場合、エラーを確認し、Verticaテクニカルサポートまでお問い合わせください。 4 次のサンプルコマンドのように、update_verticaスクリプトをrootまたはsudoで実行します。 更新が成功した場合、Step 5 に進みます。 5 データベースを起動します。 データベースが起動すると、Step 6...

より多くのストレージを必要としますか？追加のストレージが必要な場合、データベースにノードを追加することを検討してください。新しいノードは、すべて同時に追加することをご推奨します。 このチェックリストを使用して、ノードを追加することができます。これらは基本的なステップです。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...

メンテナンスのために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. セッションの最大数の設定内容を表示します。...

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...

ノードがSpreadに接続されていない場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 カタログフォルダ内のspread.confファイルが、クラスター内のすべてのノードで同一であるかどうかを確認します。 spread.confファイルがすべてのノードで同一の場合、 Step 2 へ。 すべてのノードでspread.confファイルが同一でない場合、次の手順を実施します。 正しいspread.confファイルを確認します。ファイルには、すべてのクラスターノードのIPアドレスが含まれているはずです。 正しいspread.confファイルをscpを使用してすべてのノードにコピーします。 2 spreadのポート（デフォルトは4803）が次のいずれかを使用してリスニングしているかどうかを確認します。 もしくは クラスター内の各ノードには、それぞれのspreadのポートがあります。クラスター内のspreadによって使用されるポートを確認するには、次の手順を実行します。 /database_catalog_directory/spread.conf 内で確認する。 「Spread_Segment 192.168.40.255:4803」のようなSpread_Segmentの行のIPの後の内容（この場合、4803）を確認する。 spreadがリスニングしていない場合、Step 3 へ。 spreadがリスニングしている場合、Step 4 へ。 3 ファイアウォールが有効になっていないことを確認します。 ファイアウォールが有効になっている場合、ファイアウォールを無効にするか、ネットワーク管理者にポートを開くように依頼してください。 4 /etc/hosts ファイルにクラスターのすべてのIPアドレスが含まれているかどうかを確認します。 ファイルがクラスターのすべてのIPアドレスを含んでいて正しい内容の場合、Step 5 へ。 ファイルが正しくない場合、クラスター内のすべてのノードを含めるように/etc/hostsファイルを修正し、Step 5 へ。 5 UDP受信パケットにエラーが含まれていないかどうかを確認します。 UDP受信パケットにエラーが含まれる場合、該当システムのシステム管理者に相談して問題を解決してください。 UDP受信パケットにエラーが含まれていない場合、Step 6 へ。 6 spuserを使用して、spreadのグループが形成されているかどうかを確認します。 a. クラスター内のすべてのノード上で次のコマンドを実行します。 b. 次のコマンドを実行します。 c. 前の手順で見つかったメンバーの数がノードの数と一致することを確認します。 ノードの数が一致する場合、spreadは接続されているはずであり、チェックリストは完了です。 ノードの数が一致しない場合、このチェックリストを再度たどって、別のパスを探します。 メンバーの数が継続してノードの数と一致しない場合、Verticaテクニカルサポートまでお問い合わせください。 関連詳細情報 Vertica Documentationの Spread や、Vertica Knowledge Baseの Spread Debugging で詳細情報が確認できます。

Verticaクラスターにノードを追加したり、クラスターからノードを削除したりすると、Verticaはすべてのノード上でデータのリバランスを実施します。リバランスに長時間を要する場合、これらの手順を参照して原因を調べます。 前提条件 リバランスを開始する前に、クラスターの正常なリバランスを確実に行うために、以下のステップを実行してください。 1. ETLジョブと競合しない時間帯にリバランスをスケジューリングします。 2. データベースをバックアップします。 3. 古い、あるいは、未使用のテーブルパーティションを削除します。 4. ローカルセグメンテーションが無効であることを確認します。ローカルセグメンテーションが無効になっていない場合、このコマンドを実行して無効にします。 5. vioperfとvnetperfを使用して、CPUとネットワークの帯域幅をそれぞれ確認します。 使用可能な帯域幅が初期ベンチマークの値よりも小さい場合、システム管理者に連絡して、性能が低下している原因となる問題を見つけて修正してください。 6. リバランスを実行するために、データベースのサイズの少なくとも40％のストレージが使用可能であるかどうかを確認します。ストレージの使用状況を確認するには、次のクエリを実行します。 Linuxファイルシステムで使用可能なディスク容量を確認します。 HOST_RESOURCESシステムテーブルから各ノードのスナップショットを取得します。 ストレージが不足している場合、カタログサイズを縮小するための手順を実行してください。 不要なデータ、一時的なデータ、ステージングデータを削除する。 ログファイルをクリーンアップする。 不要なテーブルまたはパーティションを削除する。 新しいドライブを追加し、ストレージのロケーションを追加し、一部のカタログオブジェクトを新しいロケーションに移行する。 リバランスの間に使用される一時スペース用の一時格納領域を追加する。 ビルトインのREFRESHリソースプールの設定を確認します。 必要に応じて、リバランス処理が滞りなく実行できるように、リソースプール設定を調整します。 7. リバランス対象のテーブルに対するDML処理（COPY、INSERT、UPDATE、DELETE）を最小限に抑えます。リバランスがテーブルのロックを保持している場合、ロードは失敗します。ロードがテーブルをロックしている場合、リバランスは一時停止します。 リバランスがETLジョブと競合していると考えられる場合、LockTimeout値を増やしてください。デフォルト値は、300秒（5分）です。 8. Purging Deleted Data の説明にしたがって、DeleteされたデータをPurgeします。 9. クラスターに追加するホストを構成します。 10. ホストをクラスターに追加します。 11. データベースにノードを追加します。 注意：詳細については、Managing the Database を参照してください。 12. リバランスを途切れることなく実行するには、DMLCancelTMパラメーターをfalseに設定して、リバランスプロセスを優先します。 これで、リバランス処理を開始する準備が整いました。ここでは、リバランスを開始し、プロセスが正常に完了するのをモニタリングするための手順を示します。 Rebalancing Data Using SQL Functions の説明に従って、リバランスを開始します。 ステップ タスク 結果 1...

データベースホストがまだ稼働中で、電源がオンの場合、Verticaストレージにアクセスできなくなることがあります。Verticaが停止している可能性があり、データやカタログのディスクボリュームが使用できません。 次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 ホストが再起動した際に、ファイルシステムの自動マウントに問題はありましたか？ 問題があった場合、 手動でそれらをマウントします。 /etc/fstabにエントリーを追加して、次のサーバーのブート時に自動マウントするようにします。 Linuxのログで、ディスクの障害やエラーの可能性があるかどうかを確認します 問題がなかった場合、Step 2 へ。 2 ハードウェアまたはディスクの障害のために、1つあるいは複数のディスクがオフラインになっていますか？ 該当する場合、RAIDセットとハードウェアコントローラーでエラーとメッセージを確認してください。複数のディスク障害がないかチェックします。 該当しない場合、Step 3 へ。 3 ハードウェアのRAID保護の設定、たとえば、RAID 0となっているなど、設定が間違っていないですか？ 間違っている場合、ハードウェアRAID保護の設定、RAID 1+0またはRAID 5を使用してRAIDセットを再構築します。 障害が発生したホストのデータは、K-safetyがデータベースに設定されている場合にのみ、別のVerticaホストから復元できます。 間違っていない場合、Step 4 へ。 4 ディスクボリュームの修復が必要ですか？ 修復が必要な場合、fsckを実行します。 修復が必要でない場合、Step 5 へ。 5 もっと情報が必要ですか？ 情報が必要な場合、 追加情報とエラーについては、/var/log/messagesを確認します。 製造元のディスクユーティリティ（ハードウェアコンソール）をチェックして、構成を検証し、エラーを確認します。 情報が必要でない場合、Step 6 へ。 6 ディスクエラーのためにディスクが「読み取り専用」でマウントされていますか？ 該当する場合、システム上のデータ保護が有効化されています。Verticaは、読み取り専用のファイルシステムを持つホスト上では起動せず、失敗します。 ディスクを再マウントするか、読み取り専用のファイルシステムの原因となるエラーを修正してください。 該当しない場合、Verticaテクニカルサポートまでお問い合わせください。 関連詳細情報 Vertica Documentation の Restart Vertica on a Node をご参照ください。

状況： 応答時間が遅い サーバーはCPU負荷が高く、プロセスが多すぎる ホストがハングしている可能性があり、接続できない、あるいは、接続がハングしている可能性がある 考えうる原因： 利用可能なメモリが少ない 実行中の同時実行プロセスが多すぎる サーバーがスワップ領域を積極的に使用している 次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Vertica以外のプロセスまたはアプリケーションが実行されているかどうかを確認します。 ホストの稼働時間を確認するか、Linuxコマンドを使用して、プロセス、メモリ使用量、およびCPU稼動のリストを表示します。 uptimeの結果は、それぞれ直近の1分、5分、15分のシステムの平均負荷を表しています。 サーバーのアクティビティを表示するその他のコマンドは次の通りです。 top コマンドは、詳細なリアルタイムCPUアクティビティ、メモリ使用量、および現在実行中のプロセスの詳細を表示します。 Vertica以外のプロセスまたはアプリケーションが実行されている場合、可能であれば、それらのプロセスを他のサーバーに移動してVerticaデータベースホストへの影響を減らします。 該当しない場合、Step 2 へ。 2 メモリが少なく、スワップ領域を積極的に使用しているかどうかを確認します。 2a. top コマンドを使用して、使用可能なメモリーとスワップ領域の使用状況を表示します。top コマンドの出力により、メモリの使用状況が、以下のように表示されます。 2b. 認識されている総メモリ（16,333,388k）と使用メモリ量（4,355,992k）を確認できます。 スワップの使用領域は、例のように0である必要があります。 スワップの使用領域の値が0以外の場合、スワップ動作を意味し、ホストの低速応答の考えうる原因の1つとなりえます。 個々のプロセスの場合、top コマンドは各プロセスのメモリ使用量を返します。 この内容が、誤って構成されたアプリケーションを識別するのに役立ちます。 スワップの使用領域が0の場合、 このホスト上で実行中のワークロードを評価し、同じクラスター内の他のVerticaホストと比較します。 ワークロードとユーザー接続のバランスを取ります。 ハードウェア構成とメモリサイズを確認します。 他のアプリケーションがVerticaホスト上でメモリを消費していないか確認します。それらを他のサーバーに移動することを検討してください。 2c. 各Verticaホストで、vm.swappiness の値を1に設定します。 デフォルト値は60です。というのも、システムがスワップディスク上のスペースを容易に使用するためです。 値が1の場合、ディスクへのスワップを最小限におさえます。 rootで、値を1に変更します。 vm.swappiness の値が1の場合、Step 3 へ。 2d. 設定を確認します。 3 セキュリティおよびオペレーティングシステムのパッチが最新のものかどうかを確認します。オペレーティングシステムのパッチは、yum コマンドを使用してインストールできます。 3a. 最新のパッチをダウンロードしてインストールするには、次のコマンドを実行します。...

このチェックリストでは、Verticaクラスターの各メンバーをホストと呼びます。 Verticaプロセスは、クラスター内の他のVerticaノードと通信します。ノードは、Verticaデータベースソフトウェアを参照します。 ホストが停止している場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Verticaホストが物理的に電源オフになっています。サーバーの前面に、ステータスのライトがありません。 電源まわりで問題はありますか？ チェックすべき項目： サーバーの電源障害 UPSバッテリー サイトの停電 ラックの電源障害 問題がある場合、各コンポーネントの障害のためにホストの電源がオフになっていることが考えられます。 Step 2 に進み、停電の原因を特定し、解決します。 2 次のようなハードウェアのいずれかが原因でホストがクラッシュしましたか？ ディスク、あるいは、ディスクコントローラー CPU メモリ ネットワークアダプター 該当する場合、問題を解決してください。その後、Step 6 へ。 該当しない場合、Step 3 へ。 3 次のいずれかが原因の温度過熱の問題はありますか？ 十分な冷却が足りておらず、その結果、高温状態でシャットダウンが発生 データセンターの冷却問題 ラック内の通気不足 換気の遮断 問題がある場合、該当する問題を解決してください。その後、Step 6 へ。 問題がない場合、Step 4 へ。 4 既知のクラッシュまたは障害の時刻を記録します。 Step 5で記録された障害の発生時刻を使用して、クラッシュの根本原因を特定します。 5 Step 4の障害発生時刻を使用して、次のログファイルで障害とその原因を確認します。 ブートログ：/var/log/boot.log Linuxログ（通常のシャットダウン、電源オフ、ハードウェア障害）：/var/log/messages ハードウェアコンソールログ。コンソールマネージャーからログを確認 これらのログファイルの情報は、障害の原因を特定するのに役立ちます。 将来の障害を防ぐために、問題解決にあたります。 問題を解決するために必要に応じてVerticaテクニカルサポートまでお問い合わせください。 6...