MySQL or MariaDB stopped, and applications can no longer connect?
A database outage can affect one website or every application on the server. We investigate the database service and the Linux environment around it to find why it stopped and how to restore it safely.
Common symptoms
The visible website error doesn’t reveal the cause. The database may have stopped due to insufficient memory, disk exhaustion, corrupted tables, filesystem problems, a failed update, too many connections, heavy queries, damaged files, server overload or storage I/O problems.
MySQL or MariaDB refusing to come back up
Disk full, damaged InnoDB files, corrupted tables, invalid configuration, insufficient memory, permission problems, a failed package update, filesystem errors or port conflicts. Error logs matter here — repeatedly restarting without reviewing the failure reason can make things worse and, in some cases, risk further data damage.
Not always a WordPress credentials problem
We check both WordPress and the database server underneath it.
The DB may stop, refuse writes, fail to restart, throw table errors, or leave temp files incomplete — affecting every website on it. We check DB growth, binary/slow-query/general logs, backups and temp files. Files aren’t deleted randomly just to free space.
Linux can kill the database under memory pressure — visible as an OOM event in the logs. We check RAM, swap, InnoDB buffer pool, connection limits and what else is competing for memory (PHP-FPM, Redis). Not automatically a “buy more RAM” problem.
High traffic, app bugs, slow queries, unclosed connections, or bots. Simply raising max_connections can spike memory usage without fixing the actual cause — we find why the limit was hit first.
Long-running queries, locks, missing indexes, unusual traffic, or a buffer pool sized wrong for the server. Database memory is considered alongside PHP-FPM, NGINX/Apache, Redis and mail services — not in isolation.
Failed startup, corrupted tables, damaged data files or transaction log issues. Aggressive recovery settings can help export data but aren’t a normal operating mode — we back up valuable data before any potentially destructive repair.
Often follows an unexpected shutdown, filesystem problem, storage failure or disk-full situation. Recovery may mean table checks, repair, export, or restoring from backup — the safest path depends on the engine and the specific error.
MySQL/MariaDB update, distro upgrade, package or config changes, storage migration. We review package history, logs and upgrade requirements to find what changed before making more changes.
An invalid parameter, duplicate config, unsupported option, wrong path or permissions, or a port conflict can be enough to prevent startup — validated against the installed version.
Database Performance Emergency
Pages taking tens of seconds, PHP timeouts, 504 Gateway Timeout, growing web server queues, checkout or admin pages unusable. We look at running and slow queries, locks, connection count, CPU, disk I/O, memory and configuration.
Frontend, wp-admin, checkout — all depend on the database
WooCommerce especially can generate far more activity — large option tables, scheduled actions, order data, sessions and slow queries. We review both database activity and the PHP/server resources around it.
The service is running — but everything hangs
Blocked queries can make an application look offline even though the database is up. We check active transactions, locked queries and long-running processes — terminating queries blindly can cause errors or incomplete operations, so impact is assessed first.
Protect what’s recoverable before repairing anything
A dump, table export, filesystem copy or provider snapshot — depending on whether the database is still running and the data files are consistent.
We preserve the current state before overwriting anything — even a partially damaged database can hold more recent data than the last backup.
Not automatically total data loss — individual tables, readable data or filesystem-level files may still be recoverable, depending on the damage.
Disk full stopping MySQL, high load hitting MySQL and PHP together, memory exhaustion killing the DB, RAID problems affecting storage — database troubleshooting isn’t limited to the DB process alone. We review the Linux environment underneath it too.
Bind address, firewall (provider or Linux), MySQL permissions and users, DNS, private networking or TLS — we check both the database server and the network path to the application.
HestiaCP, DirectAdmin, cPanel & WHM, VestaCP — we check the actual database service, not just what the panel reports. After a migration: version mismatches, missing users, permissions, character sets, socket paths or incomplete data transfer. MySQL and MariaDB aren’t automatically interchangeable across every version — a version change deserves planning, not a simple package swap.
Storage failure, disk errors, RAID problems or virtualisation issues can be the real cause. If the underlying storage looks unhealthy, continuing to write data raises the risk of corruption — provider intervention or migration may be needed.
A restart without a cause is just postponing the next outage
- configuration tuning
- disk capacity planning
- memory allocation
- slow query review
- connection limits
- database maintenance
- backup configuration
- monitoring
Faster diagnosis starts with the right details
A production database outage normally qualifies as Emergency Support
Emergency Support, for critical database and server incidents.
Out-of-Hours Emergency Support — evenings, weekends, holidays.
Both subject to administrator availability — no guaranteed 24/7 coverage unless separately agreed. Full pricing →
Exact errors, hostname, log excerpts, timestamps
Written technical detail helps us understand a database incident more accurately than a first phone call.
help@direktsupport.euPhone support is primarily for customers with an active monthly management plan.
More than 22 years of practical experience with Linux servers, hosting infrastructure, MySQL, MariaDB, WordPress, backups and production environments. When a database goes down, the priority isn’t simply to restart it.
We identify why it stopped, protect the available data, and restore the service as safely as possible.