この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

Azure Database for MySQL にてソケットエラーが発生し、接続が出来ない症状の一因について、リコンフィグレーションが発生したことによる事例が多数報告されています。

Azure Database for MySQLは、データセンター内において複数ノードで構成されており、クライアントはプライマリーノードに処理を行っています。
プライマリーノードに書き込まれた処理はセカンダリノードにも同期されており、仮にプライマリーノードにメンテナンスや障害が発生したとしても、セカンダリノードと役割の変更を自動的に行うことで最小限のダウンタイムに抑えることが可能です。
上記役割変更の動作をリコンフィグレーションと呼びます。

リコンフィグレーションが発生するとノードの役割変更に伴い、既存のセッションが切断され、ロールの変更が完了するまでの数秒から数 10 秒間、該当データベースへのアクセスが一時的に出来なくなります。
ただし、これらの動作は長期間のシステムダウンを防ぐことが目的であり、数秒程度にて再度アクセスすることが可能になります。
上記の通り、リコンフィグレーションは高可用性を維持する為に必要な動作となる為、一般的にはアプリケーション側でリトライ処理を実施頂くことが対処法となります。
確認されている事例では上記のリコンフィグレーションにより一時的にダウンタイム、接続できない時間帯が発生していました。

尚、現段階ではユーザー側にてリコンフィグレーションの発生をユーザー側で明確に調査する方法はありませｎが、
「Azure Resource Health」と「Service Health」をご利用頂く事である程度特定する事ができます。

「Azure Resource Health」は、Azure Database for MySQL側でダウンタイムが発生した事を事後確認する機能です。
メンテナンスによるダウンタイムも検知し使用不可の状態をAzureポータル上に表示します。

しかしながら、監視サーバーと該当のAzure Database for MySQL間の通信で瞬断などが発生し一時的に疎通が取れない場合でも、Azure Database for MySQLに異常が発生した可能性があると判断され、Azure Database for MySQLが正常であるにも関わらず使用不可の状態を示す既知の問題があります。
また、正常にAzure Database for MySQLのダウンタイムを検知した場合も発生時間と期間に数分の誤差が生じます。

[Azure Resource Health の概要]
https://docs.microsoft.com/ja-jp/azure/service-health/resource-health-overview

「Service Health」は、計画メンテナンスを事前に通知する事ができます。
しかしながら、「Service Health」の計画メンテナンスの事前通知機能は現段階ではプレビュー版です。

計画メンテナンスが発生したにも関わらず、事前に通知がない場合や、事前に通知があったにも関わらず、通知された時間帯には発生せず別の時間帯に発生する事があります。つまりは計画メンテナンスのスケジュール変更までは通知しない場合がございます。

また、プラットフォームレベルのメンテナンスや計画外のメンテナンスも通知されません。
「Service Health」機能のリリース日は未定で、現在リリースに向け精度を向上させている段階となります。
上記を踏まえたうえで、リコンフィグレーションの対策方法の1つとして、としてご検討頂けますようお願い申し上げます。

[サービス正常性]
https://docs.microsoft.com/ja-jp/azure/service-health/service-health-overview