MySQL and Database Errors

MySQL Server Has Gone Away

Intermediate Risk: medium

Last reviewed August 8, 2026

Hosting access may not be needed Database access often needed

Direct answer

“MySQL server has gone away” means the client lost its MySQL/MariaDB session mid-work—usually wait_timeout idle disconnect, a packet larger than max_allowed_packet, or a server restart/crash—so shrink or split the query/import, raise packet/timeout limits when appropriate, and confirm the database service stayed healthy.

WordPress sites hit this during large imports, backup restores, WooCommerce reports, or long-idle admin sessions. Logs may show CR_SERVER_GONE_ERROR / CR_SERVER_LOST, while the front end briefly shows a database connection error or a failed plugin job. This guide separates timeout and packet-size causes from true MySQL crashes so you fix the right limit—or restore after a crash—without guessing.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

MySQL documents “MySQL server has gone away” when the server closed the connection (commonly idle wait_timeout) or the client lost the session during a query. (MySQL — Gone Away)
MySQL documents that packets larger than max_allowed_packet can close the connection and surface as packet-too-large or lost-connection / gone-away style failures. (MySQL — Packet Too Large)
MySQL’s lost-connection guidance covers network, timeout, and oversized-packet cases that overlap with gone-away symptoms during long queries. (MySQL — Lost Connection)

What the error means

A PHP (or WP-CLI/mysql client) process opens a connection, then later tries to send or receive data and discovers the server already closed that session. MySQL documents the familiar “MySQL server has gone away” message for this class of failures. Common paths: the server’s wait_timeout (or interactive_timeout) expired while the app reused a stale handle; the statement or row was larger than max_allowed_packet; the administrator killed the thread; networking dropped; or mysqld itself crashed and restarted. Unlike “too many connections,” the pool may still have free slots—the specific session died. WordPress may surface this as a failed update/import, a plugin AJAX error, or a short “Error establishing a database connection” if bootstrap loses the link. Fixing it means matching packet and timeout budgets to the real workload and verifying the database did not crash underneath.

Common symptoms

PHP, WP-CLI, or plugin logs show “MySQL server has gone away” or “Lost connection to MySQL server during query”
Large SQL imports, backup restores, or migration plugins fail partway through
Long-running admin reports or WooCommerce exports die after several minutes
Intermittent database errors after idle periods in admin or cron
MySQL uptime reset or error-log crash/restart lines around the same timestamp
Small pages work while one heavy query or dump consistently fails
Retrying the same huge INSERT/UPDATE immediately fails again with packet or gone-away errors

Most likely causes

01 wait_timeout / interactive_timeout closed an idle connection the app tried to reuse
02 Query, dump, or BLOB/packet larger than max_allowed_packet on client or server
03 MySQL/MariaDB crash, OOM kill, or host restart mid-request
04 Network/firewall or proxy idle timeout between app server and remote database
05 Thread killed by an administrator, host monitor, or resource governor
06 Corrupt tables or storage issues that abort the server thread during the query
07 Import tools using browser uploads that stall until the DB session expires

What changed before the problem started

Database migration, staging sync, or all-in-one migration import
Backup/restore plugin run or host-side dump larger than before
MySQL/MariaDB version change or host maintenance window
New remote DB_HOST (managed database) with stricter idle or packet limits
Plugin update that runs bulk inserts, search-replace, or reporting queries
Disk-full or memory pressure events on the database server

Troubleshooting steps

01
Capture the exact gone-away context
Copy the full log line including whether it happened “during query,” during import, or on an idle admin AJAX call. Note file/plugin names and timestamps. Check MySQL error log for crash/restart vs clean timeout messaging. Success signal: you know if this is import/packet sized, idle timeout, or server death.
02
Verify the database service is healthy right now
Open phpMyAdmin or mysql CLI with the site credentials. Run a trivial query (SELECT 1). If you cannot connect at all, treat it as a service/credential outage first. Success signal: interactive DB access works and server uptime is stable.
03
Retry large work in smaller chunks
Split SQL dumps, run WP-CLI imports over SSH instead of browser upload, and pause plugins that try to move the whole catalog in one request. For search-replace, use tools that batch rows. Success signal: smaller batches complete without gone-away errors.
04
Raise max_allowed_packet for legitimate large packets
On hosting that allows it, increase max_allowed_packet on the server (and matching client/import flags) to clear ER_NET_PACKET_TOO_LARGE / gone-away during big rows. Managed hosts may expose this as a “max packet size” setting—use their documented control, then re-run the import. Success signal: the previously failing statement completes once.
05
Address idle timeouts for long jobs
For long backups or reports, prefer CLI jobs that keep the session active, raise wait_timeout only as far as the host allows for that workload, and disable connection reuse patterns that hold handles across multi-minute gaps. Success signal: the long job finishes with a continuous session or intentional reconnects that your tool supports.
06
Repair or restore if crashes corrupted tables
If the MySQL error log shows a crash, check table health and use host repair tools or WordPress repair.php only after a backup. When imports stopped halfway, restore a clean dump rather than leaving half-written rows. Success signal: tables check clean and the site boots without database fatals.

Capture the exact gone-away context

Copy the full log line including whether it happened “during query,” during import, or on an idle admin AJAX call. Note file/plugin names and timestamps. Check MySQL error log for crash/restart vs clean timeout messaging. Success signal: you know if this is import/packet sized, idle timeout, or server death.

Verify the database service is healthy right now

Open phpMyAdmin or mysql CLI with the site credentials. Run a trivial query (SELECT 1). If you cannot connect at all, treat it as a service/credential outage first. Success signal: interactive DB access works and server uptime is stable.

Retry large work in smaller chunks

Split SQL dumps, run WP-CLI imports over SSH instead of browser upload, and pause plugins that try to move the whole catalog in one request. For search-replace, use tools that batch rows. Success signal: smaller batches complete without gone-away errors.

Raise max_allowed_packet for legitimate large packets

On hosting that allows it, increase max_allowed_packet on the server (and matching client/import flags) to clear ER_NET_PACKET_TOO_LARGE / gone-away during big rows. Managed hosts may expose this as a “max packet size” setting—use their documented control, then re-run the import. Success signal: the previously failing statement completes once.

Address idle timeouts for long jobs

For long backups or reports, prefer CLI jobs that keep the session active, raise wait_timeout only as far as the host allows for that workload, and disable connection reuse patterns that hold handles across multi-minute gaps. Success signal: the long job finishes with a continuous session or intentional reconnects that your tool supports.

Repair or restore if crashes corrupted tables

If the MySQL error log shows a crash, check table health and use host repair tools or WordPress repair.php only after a backup. When imports stopped halfway, restore a clean dump rather than leaving half-written rows. Success signal: tables check clean and the site boots without database fatals.

When to stop troubleshooting

Stop if MySQL keeps crashing under the same statement, you lack permission to change packet/timeout settings, a partial import left unknown data integrity, disk is full, or InnoDB recovery messages look severe. Escalate with the exact gone-away line, max_allowed_packet / wait_timeout values, and backup timestamps.

Information to collect before requesting help

01 Full “MySQL server has gone away” / lost-connection log line and surrounding stack
02 Whether failure happens on import, backup, report, cron, or normal page load
03 Hosting provider and whether the database is local, remote, or managed
04 Current max_allowed_packet and wait_timeout if visible
05 Size of the dump/query that fails and the tool used (phpMyAdmin, WP-CLI, plugin)
06 MySQL uptime and crash/restart lines from the database error log
07 Latest known-good database backup before re-import or repair

How a professional repairs the problem

We classify the incident as idle timeout, oversize packet, network drop, or server crash, then stabilize MySQL health before retrying data movement. We re-run imports in safe batches with appropriate packet/timeout settings, repair or restore if the crash damaged tables, and leave WordPress jobs sized so the next migration does not reopen the same gap. You receive a concise note of root cause and which limit or workflow changed.

Frequently asked questions

Is “gone away” the same as too many connections? +

No. Too many connections means the server rejected a new client because the pool was full. Gone away means an existing session was closed or lost while the client still needed it.

Why does a small site still see this on import? +

Even small sites can push multi‑megabyte SQL packets or idle out during slow browser uploads. The site size matters less than dump size, packet limits, and how long the session sits idle.

Will increasing wait_timeout hide a crash? +

It can mask idle disconnects, not crashes. If the error log shows mysqld restarting, fix stability and disk/memory first.

Can a plugin cause MySQL server has gone away? +

Yes—migration, backup, and bulk-edit plugins commonly send huge statements or hold connections across long steps. Update, reconfigure batch sizes, or run the job over SSH instead.

Does this mean my database is corrupt? +

Not always. Timeouts and packet limits are more common. Corruption becomes likely when the server crashed mid-write or a restore stopped halfway—verify with checks and a clean backup.

Should I change DB_HOST to fix gone away? +

Only if you also see connection failures from wrong host/socket values. Gone away during an already-open query is usually timeout, packet size, or crash—not a typo in DB_HOST.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.