バージョン7より以前のScrutinizerのパケットロスの共通すこととその原因はデータベーステーブルがクラッシュすることです。それは、テクニカルサポートチームへの電話の課題でもあります。ネットフローコレクターによって受信される大量のネットフローデータのために、破損したデータベーステーブルは短期間に大量のパケットロスを起こします。

データロスとサポートタイムを最小限にするには破損したデータベーステーブルの修復が必要です。ネットフローとSフローアナライザーバージョン7に, 自己回復データベースを紹介しています。

 MySQL データベースチェックと修復は定期的に計画された基盤で一時間ごとに実行されています。データベースチェックが破損したあらゆるデータベーステーブルを見つけたら、修復しようと試みます。修復が有効でないと、破損したテーブルに警告するためScrutinizerにアラームが作成されます。
また、the Server Health LED (画面右上の4システムLEDの中の一番右端)はデータベース破損が検出されると赤に変化します。 別のServer Health LEDに関する注意– サーバディスクスペースが2ギガバイト低下するか使用可能メモリーが128メガバイトより少なくなると、このLEDは黄色に変わります。

Server Health LEDが赤い時に、LEDをクリックすると、どのデータベー破損が存在しているか表示できます。例えば下のイメージで、plixer.fa_threats と plixer.task_results データベース修復が失敗しました。しかしplixer.fa_topdomainresolve データベーステーブルの修復は成功しました。

破損したデータベーステーブルの修復を無効にした時にも、アラームが発生します。そして、アラームタブに行き、ドロップダウンリストからDatabase Health selectionを選択し、サーチボタンをクリックすると見ることができます。Admin→Settings→Syslog サーバに設定されたSyslog サーバを持っていたら,データベース修復が失敗したときに警告を出すようSyslog サーバを設定することができます。このようにデータロースを最小化しています。

 

このブログにある例の中で, 自動修復が初めは失敗しました。 しかしながらマニュアルチェックと修復を実行できたときまでは、自動修復はデータベーステーブル修復を成功させました。言いかえれば, マニュアル介入を必要とするデータベース破損はいくつかのケースがあるということです。破損が続くようならtechnical supportに連絡して下さい。

Scrutinizerｖ７ネットフローとSフローAnalyzeへアップグレードしていないなら私たちがお助けしますのでご連絡下さい。ネットワーク分析ツールバージョン７に紹介している新しいたくさんの機能を役立たせることが可能です。