How to fix CR_SERVER_LOST (2013): Lost connection to MySQL server during query in MySQL

MySQLINTERMEDIATEMEDIUMUpdated Dec 22, 2025· 321 views

CR_SERVER_LOST (2013) is thrown when the client loses the TCP session in the middle of a query. MySQL treats the connection as aborted and reports an "Aborted connection" entry, so the client never knows whether the statement finished. Timeouts, packet limits, network drops, and a restarted server are the usual suspects.

Quick fix

Fixes CR_SERVER_LOST (2013): Lost connection to MySQL server during query

SHOW VARIABLES LIKE 'log_error_verbosity';
SHOW STATUS LIKE 'Aborted_%';
SHOW GLOBAL STATUS LIKE 'Connection_errors_%';
  1. Inspect server logs and status counters around the failure window
  2. Tune MySQL timeouts to match your workload
  3. Raise packet and transfer limits for bulk operations
  4. Break large transactions and queries into smaller chunks
mysql — error
SHOW VARIABLES LIKE 'log_error_verbosity';
SHOW STATUS LIKE 'Aborted_%';
SHOW GLOBAL STATUS LIKE 'Connection_errors_%';
CR_SERVER_LOST (2013): Lost connection to MySQL server during query

What this error means

The C API and all MySQL connectors raise CR_SERVER_LOST when the back-and-forth round trip for a query breaks unexpectedly. The server logs an "Aborted connection" message and increments Aborted_clients/Connection_errors_% counters, while the client receives the 2013 error code before a result is delivered. The most common causes are server timeouts (wait_timeout/interactive_timeout/connect_timeout), max_allowed_packet or net_write_timeout limits, network/firewall devices that cut idle sessions, or the mysqld process restarting/crashing while it is processing the query. Because the client cannot determine whether the server committed the work, the application has to both prevent premature disconnections and be prepared to retry safely.

Typical symptoms

  • Application stacks trace "CR_SERVER_LOST (2013): Lost connection to MySQL server during query" while fetching or writing data
  • Errors happen consistently for queries that run after long idle periods or after submitting large BLOBs/bulk inserts
  • Result sets never arrive even though the application sees network traffic between requests
  • Connection pool entries drop silently and yield new error on next checkout
  • mysqld error log shows "Aborted connection" messages around the same time
  • SHOW GLOBAL STATUS LIKE "Aborted_clients" returns a growing count when the error occurs

Common causes

  1. wait_timeout, interactive_timeout, or connect_timeout expire while the client is idle or still building the query packet
  2. max_allowed_packet, net_write_timeout, or net_read_timeout is too low for the request and the server terminates the session
  3. network problems (flaky switch/hub, duplex mismatch, VPN drop) cause a TCP reset or timeout
  4. firewalls, load balancers, or cloud proxies drop idle connections sooner than mysqld expect
  5. mysqld crashes, is killed, or is restarted in the middle of handling a query
  6. Large transactions or bulk inserts exceed the server’s execution limits and trigger an implicit kill
  7. Using a single connection across forked workers causes one of them to hijack/close a socket under the others
  8. Client-side library bugs or mismatched protocol versions that corrupt packets

How to fix "CR_SERVER_LOST (2013): Lost connection to MySQL server during query"

1Inspect server logs and status counters around the failure window

Join the error log, general query log, and status variables to understand why the server ended the session:

sql
SHOW VARIABLES LIKE 'log_error_verbosity';
SHOW STATUS LIKE 'Aborted_%';
SHOW GLOBAL STATUS LIKE 'Connection_errors_%';

Outside the shell, run mysqladmin version to see uptime and mysqladmin variables | grep wait_timeout to check timeouts. Look for "Aborted connection" entries that mention the user/host and query ID. If you cannot reproduce the drop, briefly enable the general query log to capture the failing SQL.

2Tune MySQL timeouts to match your workload

Long-running queries or sleepy clients should not sit longer than the server's wait_timeout/interactive_timeout/connect_timeout. For example:

sql
SET GLOBAL wait_timeout = 86400;
SET GLOBAL interactive_timeout = 86400;
SET GLOBAL connect_timeout = 20;

Reload your connection pool so it opens new connections more frequently than the lowest timeout, and enable connection testing (e.g., SELECT 1) before handing the socket to the application. Avoid letting pooled connections sit idle past the server's limit.

3Raise packet and transfer limits for bulk operations

If the server kills the connection while you stream large rows or BLOBs, bump the relevant limits:

sql
SHOW VARIABLES LIKE 'max_allowed_packet';
SET GLOBAL max_allowed_packet = 67108864;
SET GLOBAL net_write_timeout = 120;
SET GLOBAL net_read_timeout = 120;

Mirror the client-side settings in your connector (under [mysql] or connection attributes) so both sides allow the same packet size.

4Break large transactions and queries into smaller chunks

Oversized INSERT/UPDATE/LOAD DATA statements may be aborted because the query packet grows too large or the server abandons the connection. Split bulk work into smaller batches and commit between them:

sql
INSERT INTO big_table (cols) VALUES (...), (...);
-- keep each batch to a few thousand rows or less than 64MB payload
COMMIT;

Use streaming APIs (e.g., mysql.connector.cursor.execute with executemany) so the client sends manageable packets.

5Validate the network path and intermediary timeouts

Firewalls, routers, or cloud load balancers sometimes drop idle connections faster than mysqld or the connector. Coordinate timeouts across all layers:

- Lower proxy idle timeout to match or exceed MySQL timeouts, or add keepalive probes.
- Verify security groups/iptables allow traffic to the MySQL port throughout long-running exchanges.
- Check for duplex/MTU issues by copying a large file over the same network path.

If you run in containers, ensure Kubernetes services or sidecars do not restart pods while a query is running.

6Implement client retries and connection health checks

Before running heavy queries, ping the connection and reconnect if necessary. Wrap statements in retry logic that distinguishes between transient CR_SERVER_LOST errors and hard failures:

ts
// pseudo-code
try {
  connection.ping({ reconnect: true });
  result = await connection.query(sql);
} catch (err) {
  if (isTransient(err, 2013)) {
    await delay(backoff(attempt));
    continue;
  }
  throw err;
}

Combine retries with idempotency (use unique request IDs) to avoid duplicate commits.

Advanced notes

To dig deeper, raise log_error_verbosity to 3 so mysqld writes disconnection details to the error log and inspect the slow_query_log for crashes triggered by specific statements. For proxies (ProxySQL, HAProxy, cloud SQL), ensure their idle timeout, health checks, and rewrites respect MySQL's maximum packet sizes. In Kubernetes or other orchestrated environments, check that liveness/readiness probes and pod lifecycle hooks do not drop sockets while background jobs are running. Finally, verify you are running matching client/server versions, because protocol bugs can generate garbled packets that the server treats as connection loss.

Frequently asked questions

What does "CR_SERVER_LOST (2013): Lost connection to MySQL server during query" mean?
The C API and all MySQL connectors raise CR_SERVER_LOST when the back-and-forth round trip for a query breaks unexpectedly. The server logs an "Aborted connection" message and increments Aborted_clients/Connection_errors_% counters, while the client receives the 2013 error code before a result is delivered. The most common causes are server timeouts (wait_timeout/interactive_timeout/connect_timeout), max_allowed_packet or net_write_timeout limits, network/firewall devices that cut idle sessions, or the mysqld process restarting/crashing while it is processing the query.
How do I fix "CR_SERVER_LOST (2013): Lost connection to MySQL server during query"?
CR_SERVER_LOST (2013) is thrown when the client loses the TCP session in the middle of a query. MySQL treats the connection as aborted and reports an "Aborted connection" entry, so the client never knows whether the statement finished. Timeouts, packet limits, network drops, and a restarted server are the usual suspects.
What causes "CR_SERVER_LOST (2013): Lost connection to MySQL server during query"?
wait_timeout, interactive_timeout, or connect_timeout expire while the client is idle or still building the query packet max_allowed_packet, net_write_timeout, or net_read_timeout is too low for the request and the server terminates the session network problems (flaky switch/hub, duplex mismatch, VPN drop) cause a TCP reset or timeout
Is the "CR_SERVER_LOST (2013): Lost connection to MySQL server during query" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading