Как проверить подключение к MySQL и не спутать доступность с правами

Сообщение сайта об ошибке базы данных не объясняет, на каком этапе возник отказ. Сервер может быть доступен по сети, но отклонять пользователя. Или вход проходит, а у аккаунта нет нужных разрешений. Проверять эти уровни следует отдельно и из той среды, где работает приложение.

Команды ниже предназначены для клиентов MySQL 8.x. Используйте согласованный диагностический аккаунт и фактические адрес и порт сервера. Имя diagnostic_user условное. Отдельный -p запросит пароль в терминале: не дописывайте его в команду и не включайте в переписку.

Введите имя или IP сервера, затем порт. При пустом ответе для порта пример использует 3306; если у приложения другое значение, укажите его:

Читайте код завершения сразу после команды: любой следующий запуск заменяет значение $?. Не используйте один код ping как проверку пароля.

Явный TCP помогает не спутать проверку сетевого соединения с подключением через локальный Unix-сокет. Если приложение использует сокет, его нужно проверять отдельно с соответствующими параметрами.

Поэтому читайте сообщение целиком. Отказ в аутентификации, отсутствие соединения и тайм-аут — разные результаты. Не объединяйте их в одно утверждение «база лежит» и не меняйте пароль, пока не установлено, какой аккаунт и способ подключения реально используются.

Для проверки аутентифицированного соединения:

Запрос не обращается к прикладной таблице. Его успех подтверждает вход и выполнение простого SQL, но не права на таблицы магазина. Для следующего этапа нужен заранее выбранный запрос чтения к нужной базе с минимальным набором разрешений.

Удалённое подключение должно использовать принятую в проекте защиту соединения. Если она предусматривает TLS и проверку имени по доверенному центру, сохраняйте эти параметры и в диагностике. Не ослабляйте проверку шифрования ради успешного теста.

До запуска стендового сервера клиент не смог установить TCP-соединение. Код mysql — 1:

ERROR 2003 означает, что клиент не подключился к указанному адресу и порту. В нашем опыте процесс ещё не работал. На другом сервере нужно различать отказ и тайм-аут, затем проверить адрес, порт, слушающий процесс и сетевые правила. Одно такое сообщение не доказывает, что потеряна база данных.

После запуска сервера мы ввели неправильный пароль. mysqladmin ping сообщил Access denied, но завершился с кодом 0. Та же попытка входа через mysql с SELECT 1 завершилась с кодом 1:

ERROR 1045 отделяет отказ в доступе от отсутствия сетевого ответа. В стенде причиной был намеренно неверный пароль; в реальной системе код сам по себе не доказывает именно ошибку пароля. Нужно сверить выбранный аккаунт, источник подключения и способ аутентификации, сохраняя параметры защиты соединения.

С правильным паролем SELECT 1 завершился с кодом 0 и вернул столбец 1 со значением 1. Это подтверждает аутентифицированное соединение и простой запрос. Прикладная таблица в этом тесте не читалась.

Этому же аккаунту разрешили чтение одной синтетической таблицы, а на другую разрешения не дали. Запрос к защищённой таблице:

mysql завершился с кодом 1, хотя вход и SELECT 1 уже были успешны. Запрос к разрешённой таблице readable_rows вернул id=1 и код 0. Для своего приложения выберите с администратором небольшой запрос чтения к нужной таблице: название diagnostic_lab относится только к нашему стенду.

После успешного входа выполните запросы в этой же сессии mysql. Они показывают версию сервера, аккаунт, выбранный при аутентификации, и назначенные ему разрешения:

Проверка с административного ноутбука может пройти, тогда как контейнер приложения не видит сервер. Сравните адрес, порт, DNS, сетевые ограничения и имя аккаунта. Отдельно учитывайте, что права MySQL зависят не только от имени пользователя, но и от источника подключения.

Пример: локальный тест работает через сокет, а сайт использует TCP на другом адресе. Эти результаты не противоречат друг другу. Нужно повторить именно способ приложения, сохранив его необходимые параметры безопасности и не раскрывая пароль.

Достаточно времени, точки проверки, протокола, обезличенного аккаунта и точного класса ошибки. Не прикладывайте конфигурационный файл с паролем. Если вход успешен, укажите отдельно результат простого запроса и проверки нужной базы.

После исправления выполните тот же тест из окружения приложения и проверьте пользовательский сценарий сайта. Наличие ответа сервера, успешный вход и корректная работа магазина — три разных подтверждения. Такая последовательность помогает найти нужный уровень ошибки без случайного изменения прав и настроек сети.

A database error message on the website does not explain at which stage the failure occurred. The server may be reachable over the network but reject the user. Or the login may succeed, but the account lacks the necessary permissions. These levels must be checked separately from the environment where the application runs.

The commands below are intended for MySQL 8.x clients. Use a consistent diagnostic account and the actual server address and port. The name diagnostic_user is conditional. The separate -p flag prompts for a password in the terminal: do not append it to the command or include it in correspondence.

Enter the server name or IP address, then the port. If the response is empty, the example uses 3306 for the port; if the application uses a different value, specify it:

Read the exit code immediately after the command: any subsequent execution overwrites the $? value. Do not use a single ping code as a password check.

Explicit TCP helps distinguish a network connection check from a connection via a local Unix socket. If the application uses a socket, it must be checked separately with the appropriate parameters.

Therefore, read the entire message. Authentication failure, no connection, and timeout are different results. Do not lump them into a single statement like "the database is down" and do not change the password until you confirm which account and connection method are actually in use.

To verify an authenticated connection:

The query does not access the application table. Its success confirms login and execution of a simple SQL statement, but not permissions for the store tables. For the next stage, you need a pre-selected read query against the target database with the minimal set of required permissions.

Remote connections must use the connection protection adopted in the project. If it includes TLS and name verification by a trusted certificate authority, preserve these parameters in diagnostics as well. Do not weaken encryption verification just to pass a test.

Before the test server started, the client could not establish a TCP connection. The mysql error code is 1:

ERROR 2003 means the client failed to connect to the specified address and port. In our experience, the process was not yet running. On another server, distinguish between a refusal and a timeout, then check the address, port, listening process, and network rules. A single such message does not prove that the database is lost.

After starting the server, we entered an incorrect password. mysqladmin ping reported Access denied but exited with code 0. The same login attempt via mysql with SELECT 1 exited with code 1:

ERROR 1045 separates access denial from lack of network response. In the test environment, the cause was an intentionally incorrect password; in a real system, the code alone does not prove a password error. Verify the selected account, connection source, and authentication method while preserving connection security parameters.

With the correct password, SELECT 1 exited with code 0 and returned a column 1 with value 1. This confirms an authenticated connection and a simple query. The application table was not read in this test.

Read access was granted to one synthetic table for this account, but not to the other. Query to the protected table:

mysql exited with code 1, even though login and SELECT 1 were successful. The query to the allowed table readable_rows returned id=1 and code 0. For your application, choose a small read query for the required table together with the administrator: the name diagnostic_lab applies only to our test stand.

After a successful login, run queries in the same mysql session. They show the server version, the account selected during authentication, and the permissions assigned to it:

A check from an administrative laptop may succeed, while the application container cannot see the server. Compare the address, port, DNS, network restrictions, and account name. Note separately that MySQL permissions depend not only on the username but also on the connection source.

Example: a local test works via socket, while the site uses TCP on a different address. These results do not contradict each other. You must replicate the application's method exactly, preserving its necessary security parameters without exposing the password.

Sufficient time, verification points, a protocol, an anonymized account, and the exact error class. Do not attach a configuration file containing a password. If the login is successful, separately report the result of a simple request and the database check.

After the fix, run the same test from the application environment and verify the website user scenario. A server response, a successful login, and correct store operation are three distinct confirmations. This sequence helps identify the precise error level without accidentally changing permissions or network settings.