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