“MySQL server has gone away” sounds like the database stopped entirely. Sometimes it did. Sometimes the application simply tried to reuse an expired connection, or sent a statement beyond a packet limit. The same error text deserves more than one configuration recipe.
Client errors such as 2006 or 2013 in MySQL and MariaDB are starting points, not proof of a particular cause. Record when the failure occurs: on connection establishment, on the first query after an idle interval, or repeatedly at the same point in a large import.
Match the failure to the server timeline
Compare application and database logs for the same interval. A restarted server cannot keep the application's old sessions alive. Linux service names vary between mysql, mysqld and mariadb. This example targets MariaDB; change the service and time range to match your installation:
sudo journalctl -u mariadb --since "30 minutes ago" --no-pager
sudo journalctl -k --since "30 minutes ago" --no-pager
The second command reads kernel records, where an out-of-memory process termination may appear. Not every database installation sends its error log to the journal. An empty result is a reason to locate the configured error file or hosting-panel logs, not evidence that no failure occurred.
If a new administrative connection works, start with these read-only queries:
SELECT VERSION(), @@version_comment;
SHOW GLOBAL STATUS LIKE 'Uptime';
SHOW GLOBAL VARIABLES LIKE 'log_error';
SHOW GLOBAL VARIABLES
WHERE Variable_name IN ('wait_timeout', 'interactive_timeout', 'max_allowed_packet');
SHOW SESSION VARIABLES
WHERE Variable_name IN ('wait_timeout', 'max_allowed_packet');
Uptime reports server uptime in seconds. A low value relative to the failure supports the restart explanation, but does not identify why it restarted. GLOBAL reads the server-wide setting; SESSION reads the connection running the query. Do not assume a fresh administrator session has the same values as an older application connection.
The first query after an idle period fails
wait_timeout governs an idle connection, not the maximum execution time of a running query. A worker may open a connection, spend a long time doing unrelated work, then discover that the server closed it. A connection pool can also hand out a session that is no longer usable.
Inspect application connection lifetime and pool validation before increasing the server's allowance. Acquiring a valid connection at the start of a unit of work may fit the application better than keeping every connection open for hours. MariaDB's variable reference explains how the session value is initialized. Changing a global value does not simultaneously rewrite every existing session.
A large statement or import fails
max_allowed_packet concerns an individual communication packet, not the total size of a dump file. A file containing many small statements may import successfully while one large INSERT or BLOB exceeds the limit. Check client and server limits together. Increasing phpMyAdmin's upload allowance addresses a different layer.
If the import always stops at the same point, inspect the statement size and error log around that position. When the evidence identifies a packet limit, select an appropriate limit or split the data into suitable batches. A blanket 1 GB recommendation is not a substitute for measuring the workload. The MySQL packet reference and the large SQL import guide cover those separate limits.
A lost reply does not prove a failed write
The server may finish an operation and lose the connection before the client receives confirmation. Before repeating a payment, order or stock update, establish whether the original operation completed. An operation identifier and duplicate-safe application behavior matter more here than merely opening another connection.
When many users fail simultaneously, investigate restarts, network changes and resource pressure. When one long-lived worker fails repeatedly, its connection management deserves closer attention. Reaching the server's connection-count limit is a separate issue, explained in the MySQL 1040 guide.
Retest the original idle period or import after the fix. A successful SELECT 1 over a fresh connection does not prove that a worker surviving for hours now behaves correctly. The failure timestamp, session behavior and the possibilities in MySQL's troubleshooting reference should point to the same explanation before you settle on a configuration change.
Related Articles