答えはありませんが、なぜこのようなことが起こるのかを説明できます。これは基本的に、定期的なハートビートを送信しない TCP 上のプロトコルで発生します。
TCP には、データを送信せずにリモート エンドが閉じていることを検出する方法がありません。また、リモート エンドの障害を検出するのにかなりの時間がかかる場合があります。
理想的な世界では、サーバーはダウンしたときに TCP FIN パケットを送信しますが、誰かがネットワーク ケーブルを引き抜いたり、サーバーが激しくクラッシュしたり、NAT ゲートウェイ/ファイアウォールの中間でサイレントに接続が切断されたりすると、これは発生しません。これにより、クライアントはサーバーがなくなったことを認識せず、何かを送信し、サーバーがなくなったと想定する必要があります。妥当な時間内に応答を受信しないか、エラーが発生します (通常、最初の数回の送信() サーバーが静かに消えた後の呼び出しはエラーになりません)。
したがって、DB 接続が正常であることを確認したい場合は、select 1
;` クエリを発行します。一部の下位レベルの DB API には、同じ目的で使用できる ping()/isAlive() または類似のメソッドがある場合があります。