#Как проявляется проблема и где искать причину
После смены пароля MySQL приложение может продолжать использовать старый секрет из файла .env, системной службы, переменных окружения, сохранённого подключения или пула. Не меняйте пароль повторно, пока не определите, какой экземпляр сервера и пользователь задействованы.
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Остался старый секретНастройка веб-приложения и база не синхронизированы | Через клиент новый пароль работает, а приложение нет | Обновить секрет в источнике конфигурации |
| Другое подключениеУ приложения иной host, port или user | Ошибка возникает только в одном окружении | Сопоставить параметры с рабочим клиентом |
#Пошаговая диагностика и устранение
- 1. Определите конкретное подключение приложенияОткройте конфигурацию веб-приложения: .env, панель секретов, настройки контейнера либо переменные службы. Запишите только host, port, user и имя базы; значение пароля в отчёт не копируйте. Проверьте, не используется ли другой сервер при запуске по расписанию.
- 2. Уточните текст ошибкиОткройте ограниченный журнал приложения и посмотрите время отказа: Access denied отличается от connection refused и таймаута. Если это ошибка сети, смена пароля не поможет. Закройте журнал от посторонних.
- 3. Проверьте новую пару отдельноНа том же сервере или в той же тестовой сети, что приложение, откройте терминал. В команде замените host/user на реальные значения; mysql спросит пароль отдельно, не показывая его в списке процессов.Linux · Терминал (Bash)КомандаДля локального TCP; подставьте реальный host/port/user. Пароль вводится после приглашения.
mysql --host=127.0.0.1 --port=3306 --user=appuser --password
- 4. Разграничьте ошибки учётных данных и сетиЕсли клиент сообщает Access denied, проверьте точное имя учётной записи в MySQL, хостовую часть user@host, способ проверки подлинности и права на базу. Если клиент входит, пароль на сервере действителен: ищите старый секрет в приложении и его способе запуска.
- 5. Исправьте единственный источник секретаОбновите значение в менеджере секретов, защищённом файле конфигурации либо настройке развёртывания; соблюдайте права чтения только для служебной учётной записи. Если используется Docker Compose, убедитесь, что контейнер действительно пересоздаётся с новой переменной; обычный рестарт процесса может не заменить окружение.
- 6. Обновите пул соединений без потери данныхНа тестовом сервере перезапустите только приложение в согласованное окно, чтобы разорвать старые соединения и открыть новые. Не перезапускайте весь MySQL и не останавливайте незавершённые операции без оценки влияния.
- 7. Проверьте вход и рольЗапустите тестовый сценарий приложения: чтение данных и разрешённая запись в тестовую таблицу. Если отказ остался, посмотрите, какие параметры реально загрузились при старте (без самого секрета), и сравните их с проверенным CLI-подключением.
#Как проверить результат
Приложение создаёт новые соединения с изменённым паролем, разрешённые операции проходят, журналы больше не показывают отказ в доступе.
#Если исправление не помогло
Если смена пароля выполнялась автоматически, проверьте порядок ротации, срок жизни секретов и механизм перезапуска сервиса; не расширяйте права пользователя до root.