myVertica  

Vertica Blog

ノードがSpreadに接続できなくなった場合の対処方法

ノードがSpreadに接続されていない場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 カタログフォルダ内のspread.confファイルが、クラスター内のすべてのノードで同一であるかどうかを確認します。 $ cat spread.conf spread.confファイルがすべてのノードで同一の場合、 Step 2 へ。 すべてのノードでspread.confファイルが同一でない場合、次の手順を実施します。 正しいspread.confファイルを確認します。ファイルには、すべてのクラスターノードのIPアドレスが含まれているはずです。 正しいspread.confファイルをscpを使用してすべてのノードにコピーします。 2 spreadのポート(デフォルトは4803)が次のいずれかを使用してリスニングしているかどうかを確認します。 $ netstat -ap | grep 4803 もしくは $ telnet <spread IP address> 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 ファイアウォールが有効になっていないことを確認します。 # iptables –L ファイアウォールが有効になっている場合、ファイアウォールを無効にするか、ネットワーク管理者にポートを開くように依頼してください。 4 /etc/hosts ファイルにクラスターのすべてのIPアドレスが含まれているかどうかを確認します。 ファイルがクラスターのすべてのIPアドレスを含んでいて正しい内容の場合、Step 5 へ。 ファイルが正しくない場合、クラスター内のすべてのノードを含めるように/etc/hostsファイルを修正し、Step 5 へ。 5 UDP受信パケットにエラーが含まれていないかどうかを確認します。 $ netstat […]

リバランス処理遅延の対処方法

Verticaクラスターにノードを追加したり、クラスターからノードを削除したりすると、Verticaはすべてのノード上でデータのリバランスを実施します。リバランスに長時間を要する場合、これらの手順を参照して原因を調べます。 前提条件 リバランスを開始する前に、クラスターの正常なリバランスを確実に行うために、以下のステップを実行してください。 1. ETLジョブと競合しない時間帯にリバランスをスケジューリングします。 2. データベースをバックアップします。 3. 古い、あるいは、未使用のテーブルパーティションを削除します。 4. ローカルセグメンテーションが無効であることを確認します。ローカルセグメンテーションが無効になっていない場合、このコマンドを実行して無効にします。 => SELECT DISABLE_LOCAL_SEGMENTS(); 5. vioperfとvnetperfを使用して、CPUとネットワークの帯域幅をそれぞれ確認します。 使用可能な帯域幅が初期ベンチマークの値よりも小さい場合、システム管理者に連絡して、性能が低下している原因となる問題を見つけて修正してください。 6. リバランスを実行するために、データベースのサイズの少なくとも40%のストレージが使用可能であるかどうかを確認します。ストレージの使用状況を確認するには、次のクエリを実行します。 => SELECT node_name, storage_path, disk_space_used_mb, disk_space_free_mb FROM DISK_STORAGE; Linuxファイルシステムで使用可能なディスク容量を確認します。 $ df -h HOST_RESOURCESシステムテーブルから各ノードのスナップショットを取得します。 => SELECT host_name, disk_space_used_mb, disk_space_total_mb FROM HOST_RESOURCES; ストレージが不足している場合、カタログサイズを縮小するための手順を実行してください。 不要なデータ、一時的なデータ、ステージングデータを削除する。 ログファイルをクリーンアップする。 不要なテーブルまたはパーティションを削除する。 新しいドライブを追加し、ストレージのロケーションを追加し、一部のカタログオブジェクトを新しいロケーションに移行する。 リバランスの間に使用される一時スペース用の一時格納領域を追加する。 ビルトインのREFRESHリソースプールの設定を確認します。 => SELECT name, is_internal, plannedconcurrency, maxmemorysize FROM RESOURCE_POOLS WHERE […]

ストレージにアクセスできずVerticaが起動できない場合の対処方法

データベースホストがまだ稼働中で、電源がオンの場合、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を実行します。 fsck /dev/sta2修復が必要でない場合、Step 5 へ。 5 もっと情報が必要ですか? 情報が必要な場合、 追加情報とエラーについては、/var/log/messagesを確認します。 製造元のディスクユーティリティ(ハードウェアコンソール)をチェックして、構成を検証し、エラーを確認します。 情報が必要でない場合、Step 6 へ。 6 ディスクエラーのためにディスクが「読み取り専用」でマウントされていますか? 該当する場合、システム上のデータ保護が有効化されています。Verticaは、読み取り専用のファイルシステムを持つホスト上では起動せず、失敗します。 ディスクを再マウントするか、読み取り専用のファイルシステムの原因となるエラーを修正してください。 該当しない場合、Verticaテクニカルサポートまでお問い合わせください。 関連詳細情報 Vertica Documentation の Restart Vertica on a Node をご参照ください。

Verticaホストが遅延している場合の対処方法

状況: 応答時間が遅い サーバーはCPU負荷が高く、プロセスが多すぎる ホストがハングしている可能性があり、接続できない、あるいは、接続がハングしている可能性がある 考えうる原因: 利用可能なメモリが少ない 実行中の同時実行プロセスが多すぎる サーバーがスワップ領域を積極的に使用している 次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Vertica以外のプロセスまたはアプリケーションが実行されているかどうかを確認します。 ホストの稼働時間を確認するか、Linuxコマンドを使用して、プロセス、メモリ使用量、およびCPU稼動のリストを表示します。 $ uptime 09:08:14 up 236 days, 8:58, 13 users, load average: 1.72, 2.09, 2.35uptimeの結果は、それぞれ直近の1分、5分、15分のシステムの平均負荷を表しています。 サーバーのアクティビティを表示するその他のコマンドは次の通りです。 top, vmstat, iostat, sar, netstat top コマンドは、詳細なリアルタイムCPUアクティビティ、メモリ使用量、および現在実行中のプロセスの詳細を表示します。 Vertica以外のプロセスまたはアプリケーションが実行されている場合、可能であれば、それらのプロセスを他のサーバーに移動してVerticaデータベースホストへの影響を減らします。 該当しない場合、Step 2 へ。 2 メモリが少なく、スワップ領域を積極的に使用しているかどうかを確認します。 2a. top コマンドを使用して、使用可能なメモリーとスワップ領域の使用状況を表示します。top コマンドの出力により、メモリの使用状況が、以下のように表示されます。 Mem: 16333388k total, 4355992k used, 11977396k free, 402180k buffers […]

Verticaホストが停止している場合の対処方法

このチェックリストでは、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 […]

Verticaホストのネットワーク接続に問題がある場合の対処方法

Verticaホストが物理的に利用できる状態で、オペレーティングシステムが稼動していてもVerticaクラスターへのネットワークにアクセスできない場合、外部からの接続ができないことが考えられます。クライアントソフトウェアの接続に失敗し、ユーザーはホストにsshできない状態で、ハードウェアのコンソール接続を確認すると、ホストがまだ稼動しているように見えるとします。 次のような問題が存在しないかどうかを確認します。 ステップ タスク 結果 1 NETWORK_USAGEシステムテーブルから初期情報を取得します。 => SELECT * FROM NETWORK_USAGE; NETWORK_USAGEシステムテーブルに関する情報を取得したら、Step 2 に進みます。 2 デフォルトのルートIPアドレス、あるいは、ルーターアドレスにpingする際に問題がありますか? 問題がある場合、ルーターはダウンしているか、または誤って構成されています。ルーターを再設定して再起動してください。該当システムのネットワーク管理者に相談してください。 問題がない場合、Step 3 へ。 3 ファイアウォールが有効になっていますか? 有効になっている場合、ファイアウォールを無効にして設定を確認し、Step 4 へ。 有効になっていない場合、設定を確認し、Step 4 へ。 4 ファイアウォール設定がVerticaが必要とするポートをブロックしていますか? デフォルト設定を使用し、Verticaが必要とするポートをブロックすると、ファイアウォールの問題が発生することがあります。 ポートをブロックしている場合、次のコマンドを実行してファイアウォールを無効にします。 $ service iptables save $ service iptables stop $ chkconfig iptables off $ service ip6tables save $ service ip6tables stop $ chkconfig ip6tables off ポートをブロックしていない場合、Step […]

クエリの性能が突然低下した場合の対処方法

以前は高速で実行されていたクエリの実行が遅くなり始めましたか? 次のチェックリストを使用し、以前は高速に実行されていたクエリの性能が突然低下した原因を調べます。 ステップ タスク 結果 1 次のコマンドを使用して、ホストのエラーメッセージを確認します。 $ cat /var/log/messages$ dmesg クラスターの状態が良好な場合、Step 2 へ。 クラスターの状態が良好でなく、エラーメッセージが表示された場合は、システム管理者に連絡してください。 サーバー上の問題が解決したら、このチェックリストの次に進みます。 2 次のコマンドを使用して、全ノードのクラスター設定を確認します。 $ /opt/vertica/oss/python/bin/python -m vertica.local_verify クラスターが正しく設定されていない場合、Verticaのドキュメントへのリンクを含むエラーのリストを表示します。リンク先の内容を確認し、エラーを解決してください。 エラーが表示されない場合、Step 3 へ。 3 クラスターの状態を確認する前にデータベースを停止します。 $ /opt/vertica/bin/admintools -t stop_db -d db-name データベースが正常に停止した場合、Step 4 へ。 それ以外の場合、検証スクリプトを実行し、Step 4 へ。 4 クラスターのネットワーク性能を確認します。 $ /opt/vertica/bin/vnetperf ディスクI/Oの性能を確認します。 $ /opt/vertica/bin/vioperf CPUの性能を確認します。 $ /opt/vertica/bin/vcpuperf ネットワーク、ディスクI/O、およびCPUのパフォーマンスの結果を調べ、Step 5 へ。 5 EXPLAINステートメント、あるいは、EXPLAIN LOCAL VERBOSEステートメントを実行し、出力結果を確認し、異常である可能性がある点を特定します。=> EXPLAIN <query> => […]

データベースの性能が劣化した場合の対処方法

データベースの性能が劣化した場合に、次のチェックリストを使用してトラブルシューティングを行います。 次のような問題が存在しないかどうか確認します。 ステップ タスク 結果 1 特定のクエリの性能が遅いですか? 特定のクエリの性能が遅い場合、クエリの性能が突然低下した場合の対処方法チェックリストを参照します。 特定のクエリの性能が遅くない場合、 Step 2 へ。 2 データベース全体が遅いですか? データベース全体が遅い場合、 Step 3 へ。 データベース全体が遅くない場合、このチェックリストは完了です。 3 全ノードが起動しているかどうか確認します。 => SELECT node_name, node_address, node_state FROM nodes WHERE node_state != ‘UP’; 任意のノードがDOWNしている場合、 ノードが停止している理由について調査を行うために、 データベースノードが停止した場合の対処方法チェックリストを確認します。 ノードを再起動します。 $ admintools –t restart_nodes –d <database> -s <nodes_address> ノードが再起動し、性能が向上した場合、このチェックリストは完了です。 ノードが再起動したが、性能がまだ遅い場合、 Step 4 へ。 ノードが再起動しない場合、 データベースノードが停止した場合の対処方法チェックリストへ。 4 大量のデリートベクターが存在していないかどうか確認します。 => SELECT count(*) FROM delete vectors; 1000以上のデリートベクターが存在する場合、デリートベクターの対処方法チェックリストを参照します。 それほど多くのデリートベクターが存在しない場合、Step 5 へ。 5 […]

カタログサイズ肥大化の対処方法

カタログのサイズが10 GBを超えるか、あるいは、カタログが1日あたり5%を超えて増えている場合、カタログサイズが大きいといえます。 このチェックリストには、データベースカタログのサイズをモニタリング、および、削減するための提案事項と推奨事項が記載されています。 データベースカタログには、テーブル、プロジェクション、ユーザー、ノード、ROSなどのメタデータが含まれています。 カタログには2種類のオブジェクトがあります。 グローバルオブジェクトはノード固有ではありません。グローバルオブジェクトには、テーブル、ユーザー、およびノードが含まれます。 どのノードもクエリのイニシエーター(実行開始ノード)として機能するため、グローバルオブジェクトは全ノード上に完全に複製されます。 ローカルオブジェクトはノード固有です。ローカルオブジェクトには、ROS、WOS、および依存関係が含まれます。ストレージレイアウトはノードによって異なる可能性があるため、ローカルオブジェクトは複製されません。各ノード上で、独立してストレージレイアウト情報を保持します。 ノード起動時に、カタログはメモリ上にキャッシュされます。 ステップ タスク 結果 1 全ノード上のカタログサイズを確認します。 => SELECT DATE_TRUNC(‘day’,ts) date, node_name, MAX(catalog_size_in_MB)::int as END_CATLOG_SIZE_MEM_MB FROM ( SELECT node_name, TRUNC((dc_allocation_pool_statistics_by_second.”time”) ::TIMESTAMP,’SS’::VARCHAR(2)) AS ts, SUM((dc_allocation_pool_statistics_by_second. total_memory_max_value – dc_allocation_pool_statistics_by_second. free_memory_min_value))/ (1024*1024) AS catalog_size_in_MB FROM dc_allocation_pool_statistics_by_second GROUP BY 1, TRUNC((dc_allocation_pool_statistics_by_second.”time”) ::TIMESTAMP,’SS’::VARCHAR(2)) ) foo GROUP BY 1,2 ORDER BY 1 DESC, 2; […]

デリートベクターの対処方法

デリートベクターを手動で削除するか、または自動的に削除されないためにトラブルシューティングをする場合、このチェックリストが役立ちます。 ステップ タスク 結果 1 プロジェクションでデリートベクターが多すぎるかどうか(100以上を目安)を確認します。 =>SELECT node_name, schema_name, projection_name, COUNT(*) num_dv, SUM(deleted_row_count) del_cnt, SUM(used_bytes) ubytes, MIN(start_epoch) min_epoch, MAX(start_epoch) max_epoch FROM delete_vectors GROUP BY 1,2,3 ORDER BY 4 DESC; num_dvで確認できるデリートベクターの数が多すぎる(通常、100以上が目安)場合、Step 2 へ。 2 AHMやLGEが進んでいるかどうかを確認します。 =>SELECT current_epoch,ahm_epoch,last_good_epoch FROM system; AHMやLGEが進んでいる場合、Step 3 へ。 AHMやLGEが進んでいない場合、AHM(Ancient History Mark)が進まない場合の対処方法チェックリストを参照してください。 3 Step 1 で確認したエポックの番号が、Step 2 で確認したAHMよりも古いかどうかを確認します。 Step 1 のクエリの結果により、デリートされた行がAHMより新しいエポックの場合、Step 4 へ。 4 下記のコマンドでAHMを進めます。 =>SELECT make_ahm_now(); 次のいずれかを実行します。 […]