Is MySQL Down? How to Diagnose & Fix MySQL Outages in 2026

MySQL is the world's most widely deployed open-source relational database, powering everything from WordPress blogs to enterprise e-commerce platforms. When MySQL goes down, your entire application stack typically fails — APIs return 500 errors, logins stop working, and data becomes inaccessible. Unlike stateless services, database downtime has compounding effects: connection pools saturate, queues back up, and recovery requires careful sequencing.

MySQL Down: First Response Checklist

Work through this in order — stop at the first positive finding:

1. Check if MySQL Process is Running

# Linux (systemd)
sudo systemctl status mysql
sudo systemctl status mysqld  # RHEL/CentOS

# Check process directly
ps aux | grep mysqld | grep -v grep

# Check if port 3306 is open
ss -tlnp | grep 3306

2. Test Database Connectivity

# Local connection test
mysql -u root -p -e "SELECT 1 AS test;"

# Remote connection test
mysql -h your-db-host -P 3306 -u your-user -p -e "SELECT 1;"

# Quick admin check
mysqladmin -u root -p status
# Returns: Uptime: 123456  Threads: 5  Questions: 99...

3. Read the MySQL Error Log

# Ubuntu/Debian
sudo tail -50 /var/log/mysql/error.log

# RHEL/CentOS
sudo tail -50 /var/log/mysqld.log

# Find log location from config
mysql -u root -p -e "SHOW VARIABLES LIKE 'log_error';"

# Common critical patterns to grep for:
grep -E "ERROR|FATAL|Shutdown|InnoDB" /var/log/mysql/error.log | tail -20

4. Check System Resources

# Check OOM killer activity (did Linux kill MySQL?)
dmesg | grep -i "oom|killed|mysql" | tail -20

# Check disk space (MySQL stops writing when disk is full)
df -h

# Check RAM
free -h

Common MySQL Failure Modes & Fixes

Failure 1: OOM Killer Killed mysqld

The Linux OOM (Out of Memory) killer terminates MySQL when RAM is exhausted. Signs: MySQL is missing from process list, dmesg shows "killed process mysqld".

# Confirm OOM kill
dmesg | grep -E "oom_kill|mysqld" | tail -10

# Restart MySQL
sudo systemctl start mysql

# Prevention: tune innodb_buffer_pool_size to 70% of available RAM
# In /etc/mysql/mysql.conf.d/mysqld.cnf:
# innodb_buffer_pool_size = 6G  # for 8GB RAM server

Failure 2: Connection Refused (Error 2002/2003)

Most common error. Check these in order:

# 1. Start MySQL if it's not running
sudo systemctl start mysql

# 2. Check bind-address (remote connections fail if bound to 127.0.0.1)
grep bind-address /etc/mysql/mysql.conf.d/mysqld.cnf
# Change to 0.0.0.0 for remote access (secure with firewall rules)

# 3. Check firewall
sudo ufw status | grep 3306
sudo iptables -L -n | grep 3306

# 4. Check max_connections
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"
mysql -u root -p -e "SHOW STATUS LIKE 'Max_used_connections';"
# If close to limit, increase: SET GLOBAL max_connections = 500;

Failure 3: InnoDB Crash Recovery

After an unclean shutdown (server crash, power loss), InnoDB runs automatic crash recovery on the next start. This is normal and safe. If MySQL fails to start due to corrupted InnoDB:

# Enable recovery mode in my.cnf (temporary)
# Add to [mysqld] section:
# innodb_force_recovery = 1
# (Try 1-6, increase until MySQL starts. Lower = safer)

# After starting in recovery mode, export data immediately:
mysqldump -u root -p --all-databases > emergency_backup.sql

# Then remove innodb_force_recovery and restart clean

Failure 4: Too Many Connections

# Check current connections
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';

# Kill idle connections (emergency)
SELECT CONCAT('KILL ', id, ';') FROM information_schema.PROCESSLIST
WHERE Command = 'Sleep' AND Time > 60;

# Increase connection limit temporarily
SET GLOBAL max_connections = 500;

Managed MySQL Services: Status Pages

MySQL Production Monitoring: What to Track

MySQL failures are often predictable — slow query accumulation, connection pool growth, and disk space reduction all precede outages. Production monitoring should track:

• Connection availability — test a lightweight SELECT 1 every 30 seconds
• Connected threads — alert when >80% of max_connections is used
• Disk usage — alert at 75% of disk to prevent write failures
• Replication lag — replica lag >30 seconds affects read scalability
• Slow query rate — sudden increase indicates query plan changes or missing indexes
• InnoDB buffer pool hit rate — should be >99%; lower means I/O bottleneck