🚨 MySQL Error: 'ERROR 1927 (HY000): Connection was killed' — Cause, Fix, and Troubleshooting Guide

Overview

ERROR 1927 (HY000) tells a client that its session was terminated by the server while it had work in progress:

ERROR 1927 (HY000): Connection was killed

Unlike ERROR 2013 (lost connection, a network/transport failure), 1927 is a deliberate termination: an administrator or an automated policy issued a KILL, a statement-timeout fired, a failover promoted a new primary, or the server was shutting down. The connection is gone; the app must reconnect and, usually, retry the transaction.

Symptoms

• A query returns 1927 mid-execution, then the next call reconnects fine.
• Bursts of 1927 coincide with failovers (Galera, Group Replication, Orchestrator) or a rolling restart.
• Long-running analytics queries die at a consistent elapsed time (a timeout).
• The error log shows KILL activity or a shutdown around the same timestamp.

Common Root Causes

1. An explicit KILL

An operator or a watchdog script killed a long/blocking query:

KILL 481523;   -- terminates that connection's thread

2. A statement or idle timeout policy

max_statement_time (MariaDB) / MAX_EXECUTION_TIME (MySQL) or a proxy’s timeout reaps queries that run too long.

SELECT @@max_statement_time;   -- MariaDB, seconds; 0 = off

3. Failover / cluster membership change

Promoting a new primary or evicting a node terminates in-flight sessions on the old node.

4. Server shutdown or OOM restart

A systemctl restart mysql or the OOM killer tears down connections; survivors see 1927/2013.

How to diagnose

Check the error and system logs around the failure time:

journalctl -u mysql --since "30 min ago" --no-pager | grep -iE "kill|shutdown|start"
dmesg | grep -i "killed process"   # OOM killer

Inspect timeout policies and any proxy limits:

SELECT @@max_statement_time, @@wait_timeout, @@interactive_timeout;

Look for orchestration events (failover) in your HA tool’s log and correlate timestamps.

Fixes

Make the application resilient: catch 1927/2013, reconnect, and retry idempotent transactions with backoff. This is mandatory for any HA/clustered deployment where failovers are routine.

If a timeout is killing legitimate long queries, raise the ceiling for that workload rather than globally:

-- MySQL: per-query optimizer hint (milliseconds)
SELECT /*+ MAX_EXECUTION_TIME(120000) */ ...;

-- MariaDB: per-session
SET SESSION max_statement_time = 120;

Persist sensible defaults where a global bump is warranted:

[mysqld]
# MariaDB example
max_statement_time = 60

For OOM-driven kills, right-size innodb_buffer_pool_size and per-connection buffers so the process is not reaped:

SELECT @@innodb_buffer_pool_size, @@sort_buffer_size, @@join_buffer_size;

What to watch out for

• Do not blanket-raise timeouts to silence 1927 — a runaway query holding locks may be exactly what the kill protected against. Fix the query first.
• Retries must be idempotent or transaction-wrapped; blindly re-running a non-transactional multi-statement batch can double-apply writes.
• During planned failovers, drain connections gracefully where the proxy supports it to reduce 1927 noise.
• Distinguish 1927 (killed on purpose) from 2013 (transport lost) in logs — they point at different root causes.

Related

• ERROR 2013: Lost connection to MySQL server during query — the transport-failure sibling that also needs retry logic.
• ERROR 2006: MySQL server has gone away — connection dropped between statements, often after a restart.
• ERROR 1205: Lock wait timeout exceeded — the kind of stuck query that operators frequently KILL.