Отделите ошибку приложения от базы
Сохраните точное сообщение и время. Проверьте, работает ли сервер базы и слушает ли ожидаемый адрес. Попытка соединения теми же реквизитами с узла приложения показывает, доступна ли сеть и проходит ли аутентификация.
Не публикуйте текст ошибки с паролем или внутренним адресом. Для диагностики достаточно кода, времени и обезличенных параметров соединения.
Проверьте ресурсы и ограничения
Посмотрите число активных и ожидающих соединений, память, диск, блокировки и журнал ошибок базы. Исчерпанный лимит соединений часто является следствием утечки в приложении или долгих запросов, а не слишком низкой настройки.
Если проблема возникла после изменения, сравните конфигурацию приложения, права пользователя, TLS и правила сети. Проверьте также разрешение имени: DNS может указывать на старый узел.
Восстановите устойчиво
После возврата соединения выполните ключевые операции чтения и записи. Оцените, не потерялись ли фоновые задачи и не накопилась ли очередь повторных запросов.
Добавьте мониторинг доступности, соединений, медленных запросов и места. В документации укажите адрес сервиса, владельца учётной записи и порядок переключения или восстановления.
Не создайте вторую аварию при восстановлении
Когда база снова доступна, приложение может одновременно повторить накопившиеся запросы. Следите за очередью, числом соединений и задержкой: резкий поток повторов способен немедленно вернуть систему в перегрузку. При необходимости открывайте трафик постепенно.
Не меняйте пароль и адрес базы сразу во всех местах без списка потребителей. Сайт, фоновые задачи, отчёты и резервное копирование могут использовать разные учётные записи. После изменения проверьте каждый процесс отдельно.
Разбираете похожую ситуацию? Расскажите о ней в форме ниже — обсудим, с чего начать именно в вашем случае.
