Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article7 min readViews10

How to Check MySQL Connectivity Without Confusing Availability with Permissions

We test connection, login, and table reading separately. A real MySQL 8.0.46 testbed demonstrates the differences between errors 2003, 1045, and 1142, as well as a successful ping.

Comments 0

Connecting the network cable to the server
In this article

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.

Clarify connection parameters

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 -r MYSQL_HOST

read -r MYSQL_PORT

MYSQL_PORT=${MYSQL_PORT:-3306}

mysqladmin --protocol=TCP --connect-timeout=5 -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u diagnostic_user -p ping

printf 'exit=%s\n' "$?"

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.

Why you must explicitly select TCP and a port is explained in the MySQL documentation on connection parameters. On Unix, the name localhost without an explicit protocol typically selects a socket, even when a port is specified.

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.

A key feature of ping

With mysqladmin ping, a successful exit code is possible even when the response indicates access denial: the server responded, so the availability check reached its goal. This does not mean the password is correct or that the application gained access to the database.

This behavior is explicitly described in the mysqladmin guide: when access is denied, ping may complete with code 0. Proceed to verify the login via mysql.

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.

Check login and a simple query

To verify an authenticated connection:

mysql --protocol=TCP --connect-timeout=5 -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u diagnostic_user -p --batch --raw -e 'SELECT 1;'

printf 'exit=%s\n' "$?"

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.

Four results on a real testbed

On October 2, 2026, we reproduced the checks on a separate Linux staging environment: a server, mysql, and mysqladmin version 8.0.46-0ubuntu0.24.04.3. Only fictional data were used, TCP on 127.0.0.1, and a temporary port. The connection to the running server was encrypted. This is an example of diagnostics, not a measurement of a live site's availability; the MySQL 8.4 branch was verified against documentation, but it was not launched in this experiment.

Server does not accept TCP connections

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

ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1:58345' (111)

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.

Server responds, but access is denied

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 (28000): Access denied for user 'diagnostic_user'@'127.0.0.1' (using password: YES)

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.

Login and simple query succeed

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.

Login successful, but table read is forbidden

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

SELECT id FROM diagnostic_lab.protected_rows LIMIT 1;

ERROR 1142 (42000) at line 1: SELECT command denied to user 'diagnostic_user'@'127.0.0.1' for table 'protected_rows'

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.

The differences between a login failure and an operation denial are provided in the MySQL server error reference. When encountering ERROR 1142, check the specific action and object, rather than changing the password or granting all privileges just to get a green test result.

Which account did the server accept

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:

SELECT VERSION() AS server_version, CURRENT_USER() AS authenticated_account;

SHOW GRANTS;

On the staging environment, the server returned version 8.0.46-0ubuntu0.24.04.3 and diagnostic_user@127.0.0.1. SHOW GRANTS showed SELECT only on diagnostic_lab.readable_rows. Therefore, the failure to read protected_rows was expected. In your system, compare the result with the application account; a diagnostic user with different permissions does not replace this check.

For your account, SHOW GRANTS does not require a separate SELECT on the mysql system schema. If privileges are granted via roles, consider the active roles of the current session. The list of assignments does not replace executing the required authorized query.

Compare the environment with the application

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.

Quick verification card

Check

What confirms success

What to check separately

mysqladmin ping

The server responds to the connection attempt

Authentication and privileges

SELECT 1

Login and execution of a simple query

Access to application tables

Read request to the required database

Specific allowed read scenario

Application operations and its environment

What to provide to the responsible specialist

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.

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.