原因 症状 対策
分類1 分類2
リソース異常に起因するエラー クライアント・クラスタ間でネットワークに障害が発生した 【サーバ】130008
【内容】ネットワーク接続エラー
【書式】通信失敗原因

障害が一時的なものであれば、フェイルオーバータイムアウト期間に収まるように、タイムアウトを設定してください。定常的なものであれば、ネットワークの二重化なども検討してください。
タイムアウト設定に起因するエラー サーバの負荷が非常に高いか、該当トランザクション自体の負荷が高い 【サーバ】50000, 50001
【クライアント】70000
【内容】トランザクションタイムアウト
【書式】タイムアウト経過期間、パーティション番号、接続アドレス、失敗原因

実行対象のアプリケーションの1ステートメント実行が、トランザクションタイムアウト期間内に収まるかどうかを確認して、適切な値を設定してください。本現象は、サーバ全体として負荷が一時的に高くなっている場合でも発生します。--memoryDetailオプション付きでgs_statを実行することで、通信メッセージの総確保量(/performance/memoryDetail/work.transactionMessageTotal)が出力されますので、定常的に大きくなっていないかを確認して下さい。特に非同期レプリケーションの際、バックアップ側は、処理が一時的に集中し、負荷が高くなる可能性があります。もし、これらが原因でタイムアウトになる場合は、準同期レプリケーションモードに変更してください。
アプリケーションにおいて、デッドロック、或いは、長期間ロックを保有している 【サーバ】50000, 50001
【クライアント】70000
【内容】トランザクションタイムアウト
【書式】タイムアウト経過期間、パーティション番号、接続アドレス、失敗原因

--memoryDetailオプション付きでgs_statを実行することで、通信メッセージの総確保量(/performance/memoryDetail/work.transactionMessageTotal)が出力されますので、値を確認して下さい。これが定常的に減らない場合はデッドロック、或いは、ロック待ち状態が発生しています。アプリケーションを見直して、必要ならば終了させてください。無制限にした場合はサーバ側で自動でロック解放することはしませんので、適切な対応を取ってください。
フェイルオーバータイムアウトが発生した 【クライアント】70000
【内容】クライアントフェイルオーバータイムアウト
【書式】タイムアウト経過期間、パーティション番号、接続アドレス、失敗原因

クラスタフェイルオーバーに時間を要するような大規模データ、特に、BLOB等一つのロウが非常に大きい場合は、フェイルオーバー(実行時の同期処理)に時間を要する場合がありますので、フェイルオーバータイムアウトを長く設定しておいてください。また、障害検知はハートビート間隔で行っていますので、ハートビート間隔が大きい場合は、検知までの時間を要するため、その場合もフェイルオーバー時間が長くなります。
レプリケーション失敗に起因するエラー レプリケーション処理が正常に完了しない状態で、フェイルオーバー処理が開始された 【サーバ】50002
【内容】更新操作連続性チェックエラー
【書式】パーティション番号、接続アドレス、失敗原因
レプリケーション処理におけるメッセージ送受信と、ノード障害のタイミングにより、バックアップへのデータが欠損することで本症状が発生する場合があります。特に非同期レプリケーションの場合に発生する確率が高いため、可用性を重視するなら、性能とのトレードオフを考慮した上で準同期レプリケーションのクラスタでの運用を推奨します。
フェイルオーバー先のデータサービスが停止状態に起因するエラー フェイルオーバー開始時点で有効であったクラスタ状態がフェイルオーバー中にリセットされ、SUB_CLUSTER状態になっている 【サーバ】10010
【内容】クラスタ非構成時のアクセス
【書式】パーティション番号、接続アドレス、失敗原因
クラスタ障害が発生した原因については、「クラスタ障害に関するトラブル」を参照してください。もし、半数以上のノードがダウンしたことによりクラスタ構成がリセットされた場合は、新たにノードを用意して、構成ノード数のノードが確保できる状態までクラスタを戻してください。
gs_cluster.jsonで設定したレプリカ数以上のノードで同時にノード障害が発生した
【サーバ】10007
【内容】(データロスト検知によるデータサービス停止)
【書式】(※マスタノードのみ)パーティション番号、該当パーティションでダウンノードも含めた最新データのLSN(Log Sequence Number)、現在のクラスタにおける最大のLSN、最新データを保有していると推定されるノードアドレス(但し、確実性は保証しない)
【コマンド確認】gs_partition --lossで上記エラー内容と同じ情報を取得できる
継続させることによりデータ一貫性が崩れることをクラスタが検知したため、該当パーティションに対するデータサービスを停止させた状態です。可用性と性能とのトレードオフになりますが、可用性を重視するならば、gs_cluster.jsonのレプリカ数を想定される同時ダウン数以上に設定してください。
gs_cluster.jsonで設定したレプリカ数以下のノードでの同時障害であったが、発生時点で、レプリカが一時的に不足状態していたパーティションが存在していた
【サーバ】:10007
【内容】(データロスト検知によるデータサービス停止)
【書式】(※マスタノードのみ)パーティション番号、該当パーティションでダウンノードも含めた最新データのLSN、現在のクラスタにおける最大のLSN、最新データを保有していると推定されるノードアドレス
【コマンド確認】
発生後は、gs_partition --lossで確認。レプリカ不足状態で稼働している場合は、gs_stat /cluster/partitionStatusで、REPLICA_LOSSと表示されているので、現在の可用性を確認する。個別のパーティション状態を知りたい場合は、gs_partitionを用いて、パーティションごとのレプリカ数を確認する
GridDBではフェイルオーバー時のダウンタイムを小さくするために、あるパーティションに対する同期実行で、ある程度時間を要する(適用するログが大きいかどうかで判定)とクラスタが判定した場合、先に短期間で同期可能なノード集合だけで同期を実行して、データサービスを部分的に開始します。この場合、バックグラウンドの非同期実行で不足分のレプリカを作成しますが、復元されるまでは可用性が低下した状態になります。よって、仮にgs_cluster.jsonでレプリカ数を十分に設定していたとしても、バックグラウンドのレプリカ復元が間に合わなければこの状態になることに注意してください。
ハートビートが安定しないなど、クラスタが定常的に構成異常を検知して、フェイルオーバーが繰り返される 【サーバ】:50003
【内容】(クラスタ非構成時のアクセス)
【書式】パーティション番号、接続アドレス、失敗原因
【サーバ】:50004
【内容】(クラスタ構成中のアクセス)
【書式】パーティション番号、接続アドレス、失敗原因
クラスタ障害が定常的に発生しており不安定となっています。「クラスタ障害に関するトラブル」を参照してください。
ネットワーク分断が発生後、過半数以上のノードが確保できるクラスタが存在したため、継続稼働したが、分散先に最新データがある場合 【サーバ】:10007
【内容】(データロスト検知によるデータサービス停止)
【書式】(※マスタノードのみ)パーティション番号、該当パーティションでダウンノードも含めた最新データのLSN、現在のクラスタにおける最大のLSN、最新データを保有していると推定されるノードアドレス
ネットワーク分断は、分断されたノードがダウンとしたのと同じ症状になります。分断先に最新データが有る場合は、該当パーティションのデータサービスは一時的に停止されますが、分断されたネットワークが元に戻った時点で、自動的に停止させていたデータサービスが再開されます。