Introduction

A MySQL server has gone away error means the application lost its database connection before the query path finished. The break can happen because the server restarted, the connection sat idle too long, the query sent too much data, or network conditions dropped the session. The real fix is to find why the connection disappears, not just to reconnect and hope it stops happening.

Symptoms

  • Database-backed pages fail intermittently with MySQL server has gone away
  • Large imports, exports, or long-running operations fail more often than small requests
  • The issue appears after traffic spikes, config changes, or database maintenance
  • Application logs show dropped database connections or retries
  • The database host stays reachable, but specific workloads lose their session

Common Causes

  • Database wait timeout settings close idle connections before the app reuses them
  • max_allowed_packet is too low for large queries or payloads
  • The MySQL server restarts or crashes under resource pressure
  • Network interruptions drop long-lived database sessions
  • The application holds connections open too long without proper retry or reconnect behavior

Step-by-Step Fix

  1. Capture the exact workload that triggers the error, including query size, runtime, and whether it happens after idle periods.
  2. Check database logs and host monitoring to see whether the server restarted, crashed, or hit resource pressure during failures.
  3. Review timeout settings on both the app and database sides so reused connections are not silently closed underneath the application.
  4. Inspect max_allowed_packet and related payload limits if the failures happen during larger writes, imports, or generated queries.
  5. Check network path stability between the app and database hosts, especially if they run in different zones, containers, or providers.
  6. Verify that the application's database client handles reconnects and stale pooled connections appropriately for your runtime.
  7. Retest the failing workload after each targeted fix instead of only checking a simple homepage query.
  8. Monitor connection counts, restart events, timeout metrics, and slow queries to confirm the issue is actually resolved.
  9. Keep database timeout and payload expectations documented so environment changes do not recreate the same disconnect pattern.