Hitachi

インメモリデータグリッド uCosminexus Elastic Application Data store ユーザーズガイド


12.2.1 縮退状態が発生した場合

縮退状態が発生した場合の復旧までの流れを次の図に示します。

図12‒1 縮退状態が発生した場合の復旧までの流れ

[図データ]

注意事項

次の場合,ここで説明する手順では復旧できません。

  • クラスタの状態が,クラスタ動作不能(NOT_AVAILABLE)またはクラスタ一部稼働中(PARTIALLY_AVAILABLE)の場合

    なお,クラスタの状態がAVAILABLEでも,半数以上のEADsサーバが縮退している場合は,クラスタ動作不能(NOT_AVAILABLE)の場合と同様の対処が必要です。

  • オンライン性能の劣化が許容できない場合

  • 復旧するEADsサーバが,クラスタ定義に定義されていない場合

  • EADsサーバダウン時のクラスタ定義と,復旧時のクラスタ定義が異なる場合

クラスタの状態が,クラスタ動作不能(NOT_AVAILABLE)またはクラスタ一部稼働中(PARTIALLY_AVAILABLE)の場合の復旧手順は,「12.2.2 クラスタ動作不能(NOT_AVAILABLE)またはクラスタ一部稼働中(PARTIALLY_AVAILABLE)の場合」を参照してください。

システム運用管理者が行う各作業について説明します。

〈この項の構成〉

(1) 縮退状態または停止状態のEADsサーバを確認する

eztool statusコマンドで,縮退状態または停止状態のEADsサーバを確認します。

コマンド実行例

[図データ]

この例の場合,State欄にisolatedと表示されているEADsサーバが縮退状態になっています。このEADsサーバを停止する必要があります。

なお,この例の場合,停止状態のEADsサーバはありません。停止状態のEADsサーバがある場合は,State欄に***********と表示されます。

(2) 縮退状態のEADsサーバを停止する

縮退状態のEADsサーバがある場合,eztool isolate --stopコマンドで,縮退状態のEADsサーバを停止します。

縮退状態のEADsサーバがない場合は実行する必要はありません。

注意事項

eztool isolate --stopコマンドは,縮退状態のEADsサーバで実行してください。

(3) エラーメッセージを確認する

(2)で停止したEADsサーバのメッセージログに出力されているエラーメッセージを確認します。

(4) 障害情報を取得する

障害の原因調査の際に次に示す情報が必要になります。全EADsサーバで次に示す情報を取得してください。

なお,eztool snapshotコマンドを使用すると,ログと設定ファイルを一括して収集できます。

障害情報の取得方法については,「12.3 障害情報の取得方法」を参照してください。

縮退状態になった時刻を調べる方法

縮退状態になったEADsサーバのメッセージログに出力されているKDEA04783-IまたはKDEA04799-Eメッセージを参照してください。このメッセージが出力された時刻が縮退状態になった時刻です。

メッセージの出力例(KDEA04783-I)

[図データ]

この例では,2013年09月03日の11時59分25秒にEADsサーバIDが1であるEADsサーバが縮退状態になっています。

メッセージの出力例(KDEA04799-E)

[図データ]

この例では,2013年08月21日の11時55分46秒にEADsサーバIDが3であるEADsサーバが縮退状態になっています。

(5) 停止したEADsサーバを復旧する

障害対策後,次のどちらかのコマンドで,停止したEADsサーバを復旧します。

復旧処理では,データの整合性を回復するために,稼働中のEADsサーバが復旧対象のEADsサーバにデータを送信します。

そのため,次の点に留意してください。

ポイント

ディスクキャッシュ,および2Wayキャッシュを使用している場合は,次のどちらかの方法でEADsサーバを復旧してください。

復旧方法

復旧の手順

復旧時の動作

適用基準

キャッシュファイルを使用して復旧する

停止したEADsサーバのキャッシュファイルを削除しないで,ezstart -rコマンド,またはezserver -rコマンドで停止したEADsサーバを復旧します。

キャッシュファイルからデータを読み込んだあと,稼働中のEADsサーバとの間でデータの過不足を補うことで,復旧します。

データの更新頻度や削除頻度が低いキャッシュで,キャッシュファイルに有効なデータが多く残っている場合,キャッシュファイルを使用しないときに比べて,復旧に掛かる時間を短縮できる可能性があります。

キャッシュファイルを使用しないで復旧する

停止したEADsサーバを指定してdeleteecf -lコマンドを実行し,該当するキャッシュのキャッシュデータファイルを削除します。

そのあとで,ezstart -rコマンド,またはezserver -rコマンドを実行して,停止したEADsサーバを復旧します。

稼働中のEADsサーバからすべてのデータを取得することで,復旧します。

データの更新頻度や削除頻度が高いキャッシュで,キャッシュファイルに無効なデータが多く残っている場合,キャッシュファイルを使用するときに比べて,復旧に掛かる時間を短縮できる可能性があります。

データの復旧中にキャッシュデータファイルの容量不足が発生した場合,内部的にコンパクションが実行されます。その結果,容量不足が解消されると,復旧処理が継続されます。

なお,次のような理由で復旧に失敗したときは,問題のあるファイルが存在するキャッシュのキャッシュファイルを削除してから,ezstart -rコマンド,またはezserver -rコマンドを実行して,停止したEADsサーバを復旧してください。

  • キャッシュファイルが破損している。

  • キャッシュデータファイルの容量不足が発生した(内部的にコンパクションを実行したが解消できない)。

  • Javaヒープあふれが発生した。

  • 内部的に実行するコンパクションが失敗した。

(6) 再起動したEADsサーバがクラスタに参加していることを確認する

eztool statusコマンドで,再起動したEADsサーバがクラスタに復帰していることを確認します。

コマンド実行例

[図データ]

クラスタに参加している場合,Cluster欄にonlineが表示されます。

ほかにも縮退状態または停止状態のEADsサーバがあれば,「12.2.1(1) 縮退状態または停止状態のEADsサーバを確認する」から再実行してください。