原因 症状 対策
分類1 分類2
クラスタ構成変更は無いが、レプリカ不足状態での部分運転や、一部のパーティションのデータサービス停止となる障害が発生する 現オーナ、バックアップ間の大きなレプリケーション遅延をクラスタが異常状態と判定してバックアップから除外した 【サーバ】:10011
【内容】(バックアップ異常検知)
【書式】(※マスタノードのみ)パーティション番号、オーナアドレス、オーナLSN, バックアップアドレス、バックアップLSN
 
レプリケーション遅延は特に非同期レプリケーションモードの際に発生しやすい傾向があります。発生が頻発するようでしたら、準同期レプリケーションモードに変更する(gs_cluster.jsonファイルの/transaction/replicationMode=1にする)か、gs_cluster.jsonファイルに/cluster/ownerBackupLsnGapを追記して値をデフォルト値(50000)より大きくしてください(*1)。
例:
"cluster":{
 "ownerBackupLsnGap":"100000",
    :
}
 
同期タイムアウト内に同期が完了しなかったため、(一部の)データサービスが、指定レプリカ数以下で部分運転が開始された 【サーバ】:10016
【内容】(同期タイムアウト検知)
【書式】(※オーナノードのみ)パーティション番号、部分運転開始時のオーナアドレス
アプリダウンタイムとのトレードオフになりますが、可用性を重視する場合は同期タイムアウト時間(gs_cluster.jsonファイルの/sync/timeoutInterval)を大きくしてください。この値は、ダウンタイムの最大値の目安になります。
あるパーティションの最新データを保持するノードがダウンして、継続させた場合にデータ不整合が発生するために、該当パーティションのデータサービスを停止させた 【サーバ】:10007
【内容】(データロスト検知によるデータサービス停止)
【書式】(※マスタノードのみ)パーティション番号、該当パーティションでダウンノードも含めた最新データのLSN、現在のクラスタにおける最大のLSN、最新データを保有していると推定されるノードアドレス
「クライアントフェイルオーバーに関するトラブル」も参照してく下さい。
また、レプリカ数を増やす、準同期レプリケーションに変更する(gs_cluster.jsonファイルの/transaction/replicationMode=1にする)ことで、発生確率を小さくすることができます。
クラスタ構成変更が必要となる障害が発生する マスタノードが、フォロワノードダウン、或いはノード状態がABNORMALへ遷移、或いはgs_leaveclusterが実行されたことを検知した 【サーバ】:10010
【内容】(フェイルオーバー開始)
【書式】(※マスタノードのみ)異常を検知したノード一覧、フェイルオーバ番号
それぞれの異常内容については、それぞれのノードのイベントログ、エラーコードを確認して下さい。
ネットワーク障害もしくは大きな遅延が発生したことによりハートビート異常を検知した 【サーバ】:10008, 10009
【内容】(ハートビートタイムアウト)
【書式】(※マスタノードのみ)異常を検知したノード、ハートビート限界時刻、最終ハートビート到着時刻
【外部ツール】ネットワーク帯域内か確認

断続的な切断でなく、定常的に発生するようでしたら、ハートビート間隔を長くして下さい。但し、ハートビート間隔を長くしすぎると、障害異常検知、及び復旧時間が遅くなるので、可用性とのトレードオフを考慮して設定してください。ネットワーク帯域による遅延であるならば、gs_cluster.jsonの各serviceAddress/servicePortを、それぞれ他ネットワークと別に設定することで発生確率を低下させることもできます。
ネットワーク以外のリソース高負荷によるハートビート異常が検知した 【サーバ】:10008, 10009
【内容】(ハートビートタイムアウト)
【書式】(※マスタノードのみ)異常を検知したノード、ハートビート限界時刻、最終ハートビート到着時刻
【外部ツール】リソース検視ツール

断続的な切断でなく、定常的に発生するようでしたら、ハートビート間隔を長くして下さい。ネットワークと異なり、メモリ不足によるスワップ、ディスクI/O待ち、高負荷アプリケーション実行によりサーバがビジー状態、同一マシン内での別アプリ起動によるもの、等、様々な要因があります。gs_statだけでなく、該当マシン全体でのリソース状態も確認して下さい。
クラスタ構成を維持できない障害が発生する
半数以上のノードの異常検知、或いは離脱によりクラスタがリセットされた
【サーバ】:10014
【内容】(過半数ノード確保できないためのクラスタ解散)
【書式】(※マスタノードのみ)クラスタ維持に必要なノード数、有効ノード数
直前にはハートビート異常検知も記録される
【サーバ】:10008, 10009
【内容】(ハートビートタイムアウト)
【書式】(※マスタノードのみ)異常を検知したノード、ハートビート限界時刻、最終ハートビート到着時刻
障害が発生してダウンしまったノードを復旧させてください。もし、復旧不可能な場合は、別途新たなノードを起動して、構成ノード数のノードとなるようにクラスタを復元させてください。但し、ダウンしているノード内に、最新データが保持されている可能性もあるので、追加の際は”gs_partition --loss"等で確認して下さい。
稼働中クラスタにおいてネットワーク分断が発生し、その後、クラスタ再構成を行おうとするが、どの部分クラスタも過半数ノードを確保できなかった
【サーバ】:10014
【内容】(過半数ノード確保できないためのクラスタ解散)
【書式】(※マスタノードのみ)クラスタ維持に必要なノード数、アクティブノード数
直前にはハートビート異常検知も記録される
【サーバ】:10008, 10009
【内容】(ハートビートタイムアウト)
【書式】(※マスタノードのみ)異常を検知したノード、ハートビート限界時刻、最終ハートビート到着時刻
ネットワーク分断の場合、分断が復旧された時点で自動的にクラスタが再開されますが、もし、分断復帰の見込みが無い場合、手動で構成台数を減らしてクラスタを再構成する必要があります。但し、分散先ノード内に、最新データが保持されている可能性もあるので、追加の際は”gs_partition --loss"等で確認して下さい。
リバランス(レプリカ不足ノードに対するレプリカ作成およびノード間の均等配分)に失敗する
チェックポイント競合などが発生し、実行中のリバランス処理を継続できなかった 【サーバ】:10012
【内容】(リバランス失敗)
【書式】失敗が発生したパーティション番号、バーティショングループ番号、チェックポイント番号、失敗原因

リバランス実行中に、チェックポイントが実行された場合、データファイルが更新され、更にログファイル削除される場合があり、この場合、実行中のリバランス処理は途中で打ち切られます。但し、もし、打ち切られたとしても、定期的にチェックしてリトライされます。但し、時間ロスが発生するため、チェックポイント時間を大きくすることと、ログ保持個数を予め大きくしておくことで発生確率を下げることができます。
リバランスタイムアウト期間内にリバランスが完了できなかった 【サーバ】:10014
【内容】(リバランスタイムアウト)
【書式】(※マスタノードのみ)タイムアウト検知したパーティション番号、タイムアウト時間
リバランスタイムアウト時間を長く設定してください。
クラスタノードで継続不可能な障害が発生した
プラットフォームエラーによるノード停止(ノード状態がABNORMAL) 【サーバ】:各プラットフォームエラー番号
【内容】プラットフォームエラー
ノード状態がABNORMALとなっている場合、プラットフォームエラーにより、継続不可能な障害が発生している場合があります。詳しくは、下記項目を参照ください。必要な情報を採取し、原因を取り除いた上で、ノードの強制停止(gs_stopnode --forceなど)、ノードの再起動(gs_startnodeなど)、クラスタ参加(gs_joinclusterなど)を実行してください。
ディスクフルによるノード停止 【サーバ】:各プラットフォームエラー番号
【内容】プラットフォームエラー(ディスクフル)
【外部ツール】df, duで確認
不要なファイルを削除してディスク領域を確保するか、ディスク増設を行うか、新たなディスク領域が確保できる新規ノードを用意して下さい。
ディスクI/O障害によるノード停止 【サーバ】:各プラットフォームエラー番号
【内容】プラットフォームエラー(ディスクI/O)
物理的なディスク障害や、リソース枯渇によるファイル書き込み失敗などのケースと、誤って必要ファイルを手動で削除してしまった等、幾つかのケースが考えられます。後者は、「リカバリ処理に関するトラブル」を参照してください。
メモリ障害によるノード停止 【サーバ】:各プラットフォームエラー番号
【内容】プラットフォームエラー(メモリアロケート)
【外部ツール】vmstat, top
【コマンド確認】gs_stat : /performance/processMemory

物理メモリに対して、メモリ上限(storeMemoryLimit)を大きくしすぎていないかをまず確認して下さい(gs_stat)。また、processMemoryが肥大化している場合は、要求処理が滞留している可能性もあるので、--memoryDetailオプション付きでgs_statを実行することで出力される、通信メッセージの総確保量(/performance/memoryDetail/work.transactionMessageTotal)を確認して下さい。
storeMemoryLimitおよびprocessMemoryは、"gs_stat"で確認してください。storeMemoryLimitは、gs_node.jsonを編集および"gs_paramconf"より変更できます。
(*1)
gs_cluster.jsonファイルの/cluster/ownerBackupLsnGap:パーティションのバックアップの異常判定、およびオーナ(パーティションのマスタ)への昇格判定のためのLSN閾値
将来、本パラメータは名前の変更や削除される可能性があります。