Database inaccessible or throwing errors: diagnosis and recovery
When the database stops responding, the whole application goes down with it: site in error, API returning 500s, unusable back office. The messages vary ("Connection refused", "Too many connections", "Access denied", "Table is marked as crashed", "could not connect to server") and each points to a different cause.
The most frequent causes are a MySQL, MariaDB or PostgreSQL service that stopped or was killed for lack of memory, a full disk, a connection limit saturated by an application that does not release them, changed credentials, a table corrupted after a hard stop, or a network or firewall configuration blocking access.
This page gives you, for MySQL/MariaDB and PostgreSQL, the checks to run in order, the fixes matching each error message and the precautions to take so that an outage does not turn into data loss.
Typical symptoms
- "Error establishing a database connection", "SQLSTATE[HY000] [2002] Connection refused" or "could not connect to server: Connection refused".
- "Too many connections" (MySQL) or "FATAL: sorry, too many clients already" (PostgreSQL) during busy hours.
- "Access denied for user" or "password authentication failed" after a migration, a password change or an update.
- "Table './db/table' is marked as crashed and should be repaired" or InnoDB errors in the log after a hard stop.
- Extremely slow queries, locks (lock wait timeout, deadlock) and an application that freezes intermittently.
- The system log shows that mysqld or postgres was killed by the OOM killer, or that the data disk is full.
Possible causes
Service stopped or killed
The database process stopped after a crash, an update, a server reboot without the service enabled at boot, or was killed by the kernel for lack of memory (OOM killer).
Full disk
No space left on the data or log partition: MySQL and PostgreSQL refuse to write, then to respond. Binary logs, temporary query files or local backups are often to blame.
Saturated connections
The application opens more connections than max_connections allows (MySQL or PostgreSQL): no pool, connection leaks, too many PHP-FPM workers or pods, slow queries hogging connections.
Wrong credentials or privileges
Password changed without updating the application configuration, user created for localhost while the application connects through an IP, pg_hba.conf rules not updated, database or user deleted.
Corrupted tables
Power loss, kill -9, failing disk or disk filling up during a write: MyISAM tables marked as crashed, invalid InnoDB pages, inconsistent PostgreSQL indexes.
Network or firewall
Port 3306 or 5432 blocked by a security group, bind-address limited to 127.0.0.1 while the application is on another machine, changed IP address of the managed database.
Locks and blocking queries
A schema migration, a backup or a long query locks tables and makes every other query wait until it times out.
Checks to perform
- 1
Read the exact error message
In the application logs (Laravel, Symfony, WordPress debug.log, Node or Java logs): "Connection refused" means a stopped service or blocked port; "Access denied" credentials; "Too many connections" saturation; "Unknown database" missing database.
- 2
Check the service status
systemctl status mysql (or mariadb, postgresql) shows whether the service is running and since when. journalctl -u mysql -n 100 or journalctl -u postgresql shows the latest errors at start-up or shutdown.
- 3
Check disk and memory
df -h and df -i on the data partition (/var/lib/mysql, /var/lib/postgresql), free -m, then dmesg -T | grep -i 'killed process' to find out whether the process was killed by the OOM killer.
- 4
Test the connection manually
mysql -u user -p -h host database or psql -U user -h host -d database from the application server. If the local connection works but the remote one does not, the problem is network, bind-address or pg_hba.conf.
- 5
Measure connections
MySQL: SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections'; SHOW PROCESSLIST;. PostgreSQL: SELECT count(*) FROM pg_stat_activity; and SHOW max_connections;. Large numbers of queries in Sleep or idle state reveal a connection leak.
- 6
Check table integrity
MySQL: CHECK TABLE table_name; or mysqlcheck --all-databases. PostgreSQL: look in the log for "invalid page" or "could not read block" messages and run VACUUM and REINDEX on suspect tables.
- 7
Identify locks
MySQL: SHOW ENGINE INNODB STATUS; and the information_schema.innodb_trx table. PostgreSQL: SELECT * FROM pg_stat_activity WHERE wait_event_type = 'Lock'; and pg_locks to find the blocking transaction.
Solutions
Restart and stabilise the service
systemctl start mysql or postgresql, then systemctl enable for automatic start-up. If the service was killed for lack of memory, reduce innodb_buffer_pool_size or shared_buffers, or increase the server memory.
Free up disk space
Purge binary logs (PURGE BINARY LOGS), application logs, old local backups and temporary files, then move the data to a larger volume if necessary.
Deal with connection saturation
Fix leaks on the application side, set up a connection pool (PgBouncer for PostgreSQL, application pool on the Java or Node side), adjust max_connections and wait_timeout consistently with the number of workers.
Restore access
Recreate or update the user and its privileges (GRANT, ALTER USER), align credentials in the application configuration, fix bind-address or pg_hba.conf, open the port in the firewall or security group.
Repair corrupted tables
MySQL: REPAIR TABLE for MyISAM, innodb_force_recovery in stages then export and reimport for InnoDB. PostgreSQL: REINDEX, restore from backup for unreadable blocks. Always back up the data files first.
Restore a backup
If the data is unrecoverable, restore the last consistent backup (mysqldump, xtrabackup, pg_dump, pg_basebackup) and replay the logs if archiving was in place (binlog, WAL).
When should you call a professional?
- The database holds production data and you do not want to attempt a repair without being sure of the procedure.
- The logs report InnoDB corruption or unreadable PostgreSQL blocks.
- The outage keeps coming back (saturated connections, OOM) and the cause lies in the application or the sizing.
- You have no recent backup or you do not know whether it can be restored.
- The database is managed (RDS, Cloud SQL, Azure Database) and you need to understand the metrics or open a well-argued support ticket.
How Agencei can help
- 1
Safety backup
Copy of the data files and logs in their current state before any change, to guarantee a point of return.
- 2
Diagnosis
Analysis of database and system logs, disk and memory usage, connections and locks, identification of the precise cause.
- 3
Return to service
Service restart, resource clean-up, access fix, table repair or targeted restore, with data integrity verification.
- 4
Structural fix
MySQL, MariaDB or PostgreSQL tuning, connection pool set-up, application leak fixes, optimisation of blocking queries.
- 5
Backups and monitoring
Tested automatic backups, log archiving for point-in-time recovery, alerts on disk, memory, connections and replication.
Frequently asked questions
What does "Too many connections" mean and how do I avoid it?
The application opened more connections than the database accepts. Raising max_connections relieves the symptom temporarily, but the lasting fix is a properly sized connection pool and fixing leaks or overly long queries.
Can I repair a corrupted table myself?
For a MyISAM table, REPAIR TABLE is generally safe. For InnoDB or PostgreSQL, forced recovery procedures can make the damage worse if misapplied. Back up the raw files before any attempt.
The database was available yesterday, why not today?
The most frequent sudden causes are a full disk, a process killed for lack of memory, a server reboot without the service starting automatically, a password change or a connection spike.
Is my data lost?
Rarely. A stopped service, a full disk or invalid credentials destroy nothing. Real corruption is less common and is handled by repair or backup restore.
How do I know whether my backup is usable?
By restoring it regularly on a test server. A backup that has never been restored is not a guarantee. We automate this test as part of a maintenance plan.
Related services
Database services
Design, optimization, administration and backups for your PostgreSQL, MySQL, MongoDB and Redis databases.
See this servicePostgreSQL expertise
Schema design, optimization, replication, version upgrades and migration to PostgreSQL.
See this serviceIT Support
Application and server support, incident handling and clear service commitments.
See this serviceData migration
Migration between databases, engines, versions or systems, with ETL, validation and zero-downtime cutover.
See this serviceIT Maintenance
Monitoring, updates, backups and continuous improvement of your applications in production.
See this serviceTell us about your project
Describe your need in a few lines: we come back to you with a first analysis and the next steps.