各ノードの障害検知と復旧方法

各ノードの障害検知と復旧方法

次は障害検知と復旧手順になります。基本的に障害の検知はokuyamaが内部で自動的に行っているため、人手で検知してフェイルオーバーなどを行う必要は特にありません。人手で行うことは、障害を起こしているノードを発見し再起動することです。

まず、ダウンしているノードの発見ですが、MasterNodeとDataNodeで方法が異なります。MasterNodeは起動しているノード全てにOkuyamaClientで接続を行い、接続エラーが発生するかどうかで障害を知ることができます。全てのMasterNodeの状態を一度に知る方法は現在存在しないため、少しプログラムを組むなどの必要はあります。

図2:MasterNodeチェックの実装例(Java言語での実装を一部抜粋)

上記のような方法でエラーが確認できた際は、該当MasterNodeを再起動することで復旧できます。MasterNodeは設定ファイルの情報のみで起動できるため、特に復旧処理などは存在しません。

次にDataNodeですが、こちらはまとめて確認可能です。確認方法ですが、MainMasterNodeの稼働しているサーバにログインし、okuyamaが出力しているログファイルの、KeyNodeWatchHelper.logを確認してください(logの場所はlog4j.propertiesに定義されています)。以下のように稼働中のサーバの生存確認を行っているログが出力されているはずです。

図3:KeyNodeWatchHelper.log

このログファイルは現在の各DataNodeの状態を表しています。上から順に以下のような意味になります。

"192.168.1.2:5553 Node Check Start"
=>192.168.1.2:5553として設定されているDataNodeの生存確認を開始
"192.168.1.2:5553 Node Check Arrival"
=>192.168.1.2:5553の生存を確認
"192.168.1.2:5553 Server Status [JVM MaxMemory Size =[954];・・・・Save Data Size=[all=295]]"
=>192.168.1.2:5553の現在のメモリの利用状態と保存しているデータ数および、データのサイズ(バイト)等の情報"192.168.1.2:5553 Node Check End"
=>192.168.1.2:5553の生存確認を完了
"192.168.1.2:5554 Node Check Start"
=>192.168.1.2:5554として設定されているDataNodeの生存確認を開始
"Node Ping Chekc Error Node Name = [192.168.1.2] Port [5554]"
=>生存確認時にエラーが発生
"java.net.SocketException: Connection reset"
=>発生したエラー内容
=>以下2回は同様の生存確認を繰り返し
"192.168.1.2:5554 Node Check Dead"
=>192.168.1.2:5554の停止を確認
"192.168.1.2:5554 Node Check End"
=>192.168.1.2:5554の生存確認を完了

以上のような内容の監視ログが常に出力されていますので、このファイルをトレースすることでDataNodeの状態を知ることが可能です。そしてこのログファイルで障害が確認できた場合は、該当DataNodeを再起動します。その際レプリケーション先が設定されている場合はデータのリカバリが行われます。図4がリカバリ処理の経過を示したログになります。

図4:KeyNodeWatchHelper.log

復旧処理を行っている経過は上から順に以下のようになります。

"192.168.1.2:5554 Node Check Start"
=>192.168.1.2:5554として設定されているDataNodeを生存を確認
"Node Name [192.168.1.2:5554] Reboot"
=>192.168.1.2:5554として設定されているDataNodeが再起動したことを確認
"Node Name [192.168.1.2:5554] Use Wait 1-1 Start"
=>データリカバリの準備を開始
"192.168.1.2:5554 - Recover Start"
=>データリカバリを開始
"Data Recover Schedule [192.168.1.3:5554 => 192.168.1.2:5554]"
=>192.168.1.3:5554として設定されているDataNodeからデータをリカバリすることを決定
"Recover Step - 1"
=>リカバリの経過を表示
=>"Recover Step - 18"まで到達するとリカバリ完了
"192.168.1.2:5554 - Recover Success"
=>リカバリが成功。なんだかの理由により失敗した場合はエラーの表記が出力されます。
"192.168.1.2:5554 - Recover End"
=>リカバリ処理が終了
"192.168.1.2:5554 Node Check End"
=>生存確認が終了

以上がリカバリ処理の経過となります。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30