適用対象:
Azure Database for PostgreSQL - フレキシブル サーバー
この記事では、Azure Database for PostgreSQL フレキシブル サーバーへの接続時の一時的なエラーへの対処方法について説明します。
一時的なエラー
一時的なエラー (一時的な障害とも呼ばれます) は、それ自体を解決するエラーです。 これらのエラーは、データベース サーバーへの接続が切断される症状として現れるのが最も典型的です。 また、サーバーへの新しい接続を開くことができないこともあります。 ハードウェアやネットワークの障害が発生した場合など、一時的なエラーが発生する可能性があります。 もう 1 つの理由は、ロールアウト中の PaaS サービスの新しいバージョンである可能性があります。システムは、これらのイベントの大部分を 60 秒未満で自動的に軽減します。 クラウドのアプリケーションを設計および開発するベスト プラクティスでは、一時的なエラーを想定します。 どのコンポーネントでも常に起こりうると想定し、そうした状況に対処するための適切なロジックを設けるのです。
一時的エラーの処理
一時的なエラーは、再試行ロジックを使用して処理する必要があります。 考慮に入れるべき状況は以下のとおりです:
- 接続を開こうとするときにエラーが発生する
- アイドル状態の接続がサーバー側で切断される。 コマンドを発行しようとしても実行できない
- 現在コマンドを実行しているアクティブな接続が切断される。
1 つ目と 2 つ目は、かなり対処しやすいケースです。 もう一度接続を開いてみてください。 システムが一時的なエラーを軽減したら、接続に成功します。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスを再使用できます。 接続を再試行する前に待ち時間を設けることをお勧めします。 初回再試行に失敗した場合は、いったん後退します。 そうすることで、システムは利用可能なすべてのリソースを使用してエラー状態を克服することができます。 推奨されるパターンを次に示します:
- 初回再試行の前には 5 秒間待機します。
- 以降再試行するたびに、60 秒を上限として、待ち時間を指数関数的に増やします。
- 操作が失敗したとアプリケーションで見なされる最大再試行回数を設定します。
アクティブなトランザクションとの接続が失敗した場合、復旧を正しく処理することはより困難になります。 2 つのケースがあります。トランザクションが本質的に読み取り専用であった場合は、接続を再度開き、トランザクションを再試行しても安全です。 一方、データベースへの書き込みも伴うトランザクションの場合は、そのトランザクションがロールバックされたかどうかや、一時的なエラーが発生する前に成功したかどうかを判断しなければなりません。 その場合、データベース サーバーからコミット確認を受信していない可能性があります。
その判断を行う 1 つの方法として、すべての再試行に使用される一意の ID をクライアントで生成することが考えられます。 この一意の ID をトランザクションの一環としてサーバーに渡し、一意制約のある列に格納します。 こうすることで、トランザクションを安全に再試行することができます。 前のトランザクションがロールバックされ、クライアントによって生成された一意の ID がまだシステムに存在しない場合、成功します。 一意の ID が既に格納されている場合は、前回のトランザクションが正常に完了していることになるので、再試行は失敗し、キーが重複している旨の違反が表示されます。
ご使用のプログラムがサード パーティのミドルウェアを介して Azure Database for PostgreSQL フレキシブル サーバーと通信している場合、そのミドルウェアに一時エラーに対応した再試行ロジックがあるかどうかをベンダーに確認してください。
再試行ロジックは必ずテストしてください。 たとえば、Azure Database for PostgreSQL フレキシブル サーバー インスタンスのコンピューティング リソースをスケールアップまたはダウンしているときに、コードを実行してください。 この操作中に発生した短時間のダウンタイムには、アプリケーションで問題なく対処する必要があります。