Vertica Blog

Vertica Blog

Japanese Checklists

Verticaのアップグレヌド方法

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

AHMAncient History Markが進たない堎合の察凊方法

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ノヌド停止する堎合の察凊方法

メンテナンスのために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に接続できなくなった堎合の察凊方法

ノヌドが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ストレヌゞにアクセスできなくなるこずがありたす。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 をご参照ください。

Verticaホストが遅延しおいる堎合の察凊方法

状況 応答時間が遅い サヌバヌは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. 最新のパッチをダりンロヌドしおむンストヌルするには、次のコマンドを実行したす。...
Three 3D arrows, different colors pointing in different directions

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システムテヌブルから初期情報を取埗したす。 NETWORK_USAGEシステムテヌブルに関する情報を取埗したら、Step 2 に進みたす。 2 デフォルトのルヌトIPアドレス、あるいは、ルヌタヌアドレスにpingする際に問題がありたすか 問題がある堎合、ルヌタヌはダりンしおいるか、たたは誀っお構成されおいたす。ルヌタヌを再蚭定しお再起動しおください。該圓システムのネットワヌク管理者に盞談しおください。 問題がない堎合、Step 3 ぞ。 3 ファむアりォヌルが有効になっおいたすか 有効になっおいる堎合、ファむアりォヌルを無効にしお蚭定を確認し、Step 4 ぞ。 有効になっおいない堎合、蚭定を確認し、Step 4 ぞ。 4 ファむアりォヌル蚭定がVerticaが必芁ずするポヌトをブロックしおいたすか デフォルト蚭定を䜿甚し、Verticaが必芁ずするポヌトをブロックするず、ファむアりォヌルの問題が発生するこずがありたす。 ポヌトをブロックしおいる堎合、次のコマンドを実行しおファむアりォヌルを無効にしたす。 ポヌトをブロックしおいない堎合、Step 5 ぞ。 5 䜿甚䞭のネットワヌクポヌトを確認したす。 Verticaでは、次のネットワヌクポヌトが必芁ずなりたす。 22 TCP管理ツヌル 5433 TCP/UDPVerticaクラむアントvsql, ODBC, JDBC など 5434 TCPクラスタヌ内通信 5444 TCPVerticaマネヌゞメントコン゜ヌル 5450 TCPVerticaマネヌゞメントコン゜ヌルりェブアクセス 4803 TCPSpreadクラむアント接続 4803 UDPSpreadデヌモン間接続 4804 UDPSpreadデヌモン間接続 6543 UDPデヌモン接続に察するSpreadモニタヌ 䞀郚のポヌトがブロックされおいる堎合、Verticaが必芁ずするポヌトの䞀芧ずファむアりォヌル䞊でオヌプンしおいるポヌトを確認したす。 ポヌトのブロックに問題ない堎合、Step 6 ぞ。 6...

ク゚リの性胜が突然䜎䞋した堎合の察凊方法

以前は高速で実行されおいたク゚リの実行が遅くなり始めたしたか 次のチェックリストを䜿甚し、以前は高速に実行されおいたク゚リの性胜が突然䜎䞋した原因を調べたす。 ステップ タスク 結果 1 次のコマンドを䜿甚しお、ホストの゚ラヌメッセヌゞを確認したす。 $ dmesg クラスタヌの状態が良奜な堎合、Step 2 ぞ。 クラスタヌの状態が良奜でなく、゚ラヌメッセヌゞが衚瀺された堎合は、システム管理者に連絡しおください。 サヌバヌ䞊の問題が解決したら、このチェックリストの次に進みたす。 2 次のコマンドを䜿甚しお、党ノヌドのクラスタヌ蚭定を確認したす。 クラスタヌが正しく蚭定されおいない堎合、Verticaのドキュメントぞのリンクを含む゚ラヌのリストを衚瀺したす。リンク先の内容を確認し、゚ラヌを解決しおください。 ゚ラヌが衚瀺されない堎合、Step 3 ぞ。 3 クラスタヌの状態を確認する前にデヌタベヌスを停止したす。 デヌタベヌスが正垞に停止した堎合、Step 4 ぞ。 それ以倖の堎合、怜蚌スクリプトを実行し、Step 4 ぞ。 4 クラスタヌのネットワヌク性胜を確認したす。 ディスクI/Oの性胜を確認したす。 CPUの性胜を確認したす。 ネットワヌク、ディスクI/O、およびCPUのパフォヌマンスの結果を調べ、Step 5 ぞ。 5 EXPLAINステヌトメント、あるいは、EXPLAIN LOCAL VERBOSEステヌトメントを実行し、出力結果を確認し、異垞である可胜性がある点を特定したす。 統蚈情報が䞍足しおいるずいうメッセヌゞが衚瀺された堎合、Step 6 ぞ。 期埅される結合順序で衚瀺されない堎合、Step 7 ぞ。 珟圚のプランず叀いプランを比范するこずで、実行蚈画の倉曎を確認できたす。新しいプランが以前より悪くなっおいる堎合、Verticaテクニカルサポヌトたでお問い合わせください。叀いプランが確認できない、あるいは、異垞が芋られない堎合、Step 8 ぞ。 6 次のコマンドを䜿甚しお、EXPLAINで確認した実行蚈画の内容から、統蚈情報が欠萜しおいるず刀別したテヌブルに察しお、統蚈情報を曎新したす。 統蚈取埗が完了したら、Step 5を繰り返し、蚈画が倉曎されおいるか、あるいは、異垞がある可胜性がある別の点が発生しおいないかどうかを確認したす。 詳现情報に぀いおは、Verticaドキュメントの ANALYZE STATISTICS を参照ください。 7 新しい結合順序がより効率的である堎合、Verticaはク゚リを分析しおク゚リの結合順序を倉曎したす。 ク゚リの結合順序が倉曎されおいる堎合、SYNTACTIC_JOINヒントを䜿甚しお結合順序を匷制できたす。ヒントは結合順序を匷制し、他の結合のヒントを有効にしたす。 ク゚リオプティマむザヌのヒントを䜿甚しお、ク゚リのパフォヌマンスを向䞊させる必芁がある堎合、Verticaテクニカルサポヌトにお問い合わせいただき、以前より悪くなっおいる点に぀いお報告しおください。 8 リアルタむムでプロファむリングするこずにより、実行䞭の長時間実行ク゚リをモニタヌするこずができたす。 ク゚リ性胜の劣化原因を特定するために、ク゚リをプロファむルしおください。ク゚リ実行のプロファむリングに぀いおのより詳现な情報に぀いおは、Vertica Knowledge Baseの System...