Что делать со статусом Inaccessible в Azure PostgreSQL Flexible Server: проверяем Resource Health, Activity Log, HA, DNS и соединение, не перезапуская сервис вслепую.
Снимите четыре состояния до действия
Зафиксируйте Overview status, Resource Health, HA health и результат одного подключения к обычному FQDN. Эти сигналы отвечают на разные вопросы: видит ли Resource Manager ресурс, считает ли платформа его доступным, готова ли HA-пара и принимает ли endpoint новые соединения. Сохраните UTC-время и correlation ID последних операций. Не нажимайте Restart до этого снимка: перезапуск создаёт новую management operation, может инициировать failover и стирает возможность понять исходную последовательность.
Прочитайте Activity Log как control plane
Azure Activity Log автоматически фиксирует create, update, delete, action и ошибки Resource Manager. Отфильтруйте один server resource и период перед появлением Inaccessible, затем выпишите operation, status, caller type и correlation ID, скрыв пользователя. Проверьте, не зависли ли scale, configuration, HA или restart. Отсутствие ошибки в Activity Log не доказывает здоровье SQL: data-plane запросы туда обычно не попадают. Но активная операция — причина остановить параллельные изменения.
Проверьте data plane без секретов
Разрешите DNS-имя с того же клиента, где работает приложение, затем проверьте TCP-доступность ожидаемого порта и одну короткую попытку подключения с безопасным timeout. Не публикуйте IP, FQDN, логин или connection string. Если DNS и TCP работают, сохраните SQLSTATE и серверное сообщение; если нет, сравните private endpoint, private DNS и firewall с последней известной конфигурацией. Не заменяйте FQDN постоянным IP: управляемый сервис может менять адрес при failover.
Оцените HA и транзиентность
Microsoft описывает HA states и автоматический failover, а также транзиентные разрывы, которые приложение должно переживать ограниченными ретраями. Сравните HA health и Resource Health с failed connection. Один повтор с exponential backoff допустим для чтения или идемпотентной операции, но не бесконечная запись. Если состояние продолжается дольше обычного транзиентного окна или control plane недоступен, не запускайте forced failover без плана: это уже случай для владельца сервиса.
Решите, когда нужен restart или support
Restart является документированной management operation, а в HA может включать planned или forced failover. Его выполняют после сохранения evidence, подтверждения отсутствия другой операции, оценки окна простоя и rollback приложения. Для поддержки подготовьте subscription и resource ID только в защищённом канале, регион, версию, HA mode, UTC-интервал, Resource Health, Activity Log correlation IDs, DNS/TCP/SQLSTATE и последние изменения. Критерий остановки — Inaccessible control plane или platform health event.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Azure; серверные имена, IP и строки подключения не использовались.
Источники и проверка
- Microsoft Learn — Activity Log Azure Monitor проверено 2026-07-29
- Microsoft Learn — transient connectivity PostgreSQL проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.