Halaman putih dengan satu baris kalimat adalah salah satu kerusakan paling menakutkan, karena ia menggantikan seluruh situs, bukan hanya sebagiannya. Kabar baiknya, daftar penyebabnya sangat pendek.
Hanya ada empat kemungkinan: kredensial di file konfigurasi sudah tidak benar, layanan database tidak berjalan, jumlah koneksi mentok di batas, atau datanya rusak. Yang perlu Anda lakukan pertama bukan memperbaiki, melainkan menentukan Anda di kelompok mana — karena keempat penanganannya sama sekali berbeda.
Mempersempit penyebab dalam dua menit
Sebelum menyentuh file apa pun, jawab satu pertanyaan: apakah layanan database-nya berjalan?
Kalau punya SSH, jalankan "systemctl status mysql" atau "systemctl status mariadb". Kalau memakai shared hosting, coba buka phpMyAdmin dari panel — kalau bisa masuk, layanannya hidup dan kredensial situs Anda yang bermasalah.
| Yang Anda amati | Penyebab yang hampir pasti |
|---|---|
| Layanan berhenti | RAM habis atau layanan crash — restart lalu baca log |
| Layanan jalan, phpMyAdmin bisa masuk | Kredensial di file konfigurasi salah |
| Error hanya muncul saat ramai | Mentok di max_connections |
| Satu tabel error, tabel lain normal | Tabel rusak — perlu diperbaiki |
| Baru terjadi setelah pindah hosting | Hostname salah atau user belum diberi hak akses |
Penyebab 1 — Kredensial salah
Ini penyebab paling umum tepat setelah pindah hosting, restore backup, atau mengganti password di panel.
Untuk WordPress, empat nilai di wp-config.php harus sama persis: DB_NAME, DB_USER, DB_PASSWORD, dan DB_HOST. Yang paling sering salah adalah DB_HOST — "localhost" benar di sebagian besar server, tapi beberapa penyedia memakai hostname khusus, dan nilai yang benar selalu ada di panel hosting.
Kesalahan kedua terbanyak adalah prefiks nama user dan nama database. Banyak panel menambahkan prefiks akun secara otomatis, sehingga database yang Anda beri nama "wordpress" sebenarnya bernama "user123_wordpress".
Uji cepat dengan menyambung sendiri: "mysql -u namauser -p -h localhost namadatabase". Kalau perintah ini berhasil sementara situs tetap error, kredensial bukan masalahnya dan Anda bisa lanjut ke bagian berikutnya.
Penyebab 2 — Layanan database mati
Ketika MySQL atau MariaDB tidak berjalan, semua situs di server itu menampilkan error yang sama. Restart biasanya langsung memulihkannya, tapi berhenti di situ berarti melewatkan bagian pentingnya.
Penyebabnya hampir selalu kehabisan memori. VPS kecil yang menjalankan web server, PHP, dan database sekaligus akan mentok RAM saat ramai, kernel memilih proses paling rakus memori untuk dibunuh, dan itu biasanya MySQL.
Jalankan "dmesg | grep -i oom" untuk melihat apakah kernel turun tangan. Kalau ya, restart hanya membeli waktu sampai kejadian berikutnya — penanganan sebenarnya adalah menambah swap, menurunkan pemakaian memori database, atau menambah RAM.
Penyebab kedua adalah disk penuh. Database yang tidak bisa menulis akan berhenti total. "df -h" memberi jawaban dalam sedetik, dan log serta backup lama adalah tempat pertama yang perlu dibersihkan.
Penyebab 3 — Koneksi habis, dan penyebab 4 — Tabel rusak
Kalau error hanya muncul saat jam ramai lalu hilang sendiri, Anda sedang mentok di max_connections. Setiap pengunjung memakai satu koneksi, dan ketika semuanya terpakai, pengunjung berikutnya mendapat pesan error ini.
Godaannya adalah menaikkan max_connections, tapi setiap koneksi memakan memori sehingga menaikkannya berlebihan hanya menukar error ini dengan error OOM. Penanganan yang lebih awet adalah mengaktifkan page cache agar sebagian besar kunjungan tidak menyentuh database, dan mencari query lambat yang menahan koneksi lebih lama dari seharusnya.
Tabel rusak punya gejala yang sangat berbeda: sebagian besar situs tetap jalan, hanya beberapa halaman atau satu fitur yang error. Penyebabnya biasanya listrik padam atau disk penuh saat proses penulisan.
Untuk WordPress, tambahkan define('WP_ALLOW_REPAIR', true); ke wp-config.php lalu buka /wp-admin/maint/repair.php untuk menjalankan alat perbaikan bawaan. Hapus baris itu segera setelah selesai, karena halaman tersebut tidak memerlukan login.
Di luar WordPress, "mysqlcheck --repair --all-databases" melakukan hal serupa. Apa pun caranya, buat backup sebelum memperbaiki — alat perbaikan tabel kadang harus membuang baris yang tidak bisa diselamatkan.
Mencegahnya terulang
- Tambahkan swap kalau VPS Anda ber-RAM kecil. Ini perubahan sekali jalan yang menghapus penyebab tersering dari insiden ini.
- Aktifkan page cache. Setiap kunjungan yang dilayani dari HTML statis adalah satu koneksi database yang tidak pernah dibuat.
- Pantau ruang disk dan pasang peringatan di angka 80%. Disk penuh menghentikan layanan sekaligus merusak tabel, jadi satu peringatan mencegah dua insiden.
- Backup otomatis harian dan uji pemulihannya. Backup yang belum pernah dicoba dipulihkan hanyalah sebuah asumsi.
- Simpan kredensial database di satu tempat. Insiden ini sangat sering terjadi setelah mengganti password di panel tapi lupa memperbarui file konfigurasi.
- Aktifkan slow query log. Query lambat adalah akar bersama dari kehabisan koneksi maupun kehabisan memori.
Butuh RAM dan kendali agar database tidak tumbang lagi?
Cloud VPS NVMe dengan sumber daya khusus dan akses root penuh — atur sendiri swap, cache, dan MySQL. Mulai ฿150/bulan.
Pertanyaan yang Sering Diajukan
Situs saya normal kemarin dan saya tidak mengubah apa pun. Kenapa hari ini error?
Hampir selalu layanan database yang mati, biasanya karena kehabisan RAM atau disk penuh. Jalankan "systemctl status mysql" untuk melihat statusnya, "dmesg | grep -i oom" untuk tahu apakah kernel membunuhnya, dan "df -h" untuk memeriksa disk. File konfigurasi tidak berubah sendiri, jadi curigai itu paling terakhir.
Saya sudah restart MySQL dan situsnya jalan lagi. Sudah selesai?
Belum. Restart menangani gejala, bukan penyebab, dan masalahnya akan kembali. Lihat log tepat sebelum waktu crash: kalau OOM, tambah swap atau turunkan pemakaian memori; kalau disk penuh, bersihkan dan pasang peringatan.
Apakah alat perbaikan tabel WordPress aman?
Aman, tapi backup database dulu — alat perbaikan kadang harus membuang baris yang tidak bisa diselamatkan. Dan hapus baris WP_ALLOW_REPAIR dari wp-config.php begitu selesai, karena halaman perbaikan itu bisa dibuka siapa saja tanpa login.
Kenapa errornya hanya muncul saat pengunjung ramai?
Karena Anda mentok di max_connections. Menaikkan batasnya bersifat sementara dan memakan RAM; yang lebih awet adalah mengaktifkan page cache agar sebagian besar kunjungan tidak butuh database, sambil mencari query lambat yang menahan koneksi lebih lama dari seharusnya.
GUIDES
Artikel terkait
Lanjut membaca topik serupa
500 Internal Server Error — Penyebab dan Cara Mengatasinya
500 adalah error paling tidak informatif di web: artinya "ada yang salah dan saya tidak akan bilang apa". Kabar baiknya, server hampir selalu menuliskan alasan sebenarnya ke sebuah file log. Panduan ini menunjukkan di mana log itu dan urutan pemeriksaan yang paling cepat menemukan biangnya.
Baca selengkapnya
503 Service Unavailable — Penyebab dan Cara Mengatasinya
503 berbeda dari semua error 5xx lainnya dalam satu hal: sering kali ia jawaban yang disengaja. Server tetap berjalan, tetap memahami permintaan, dan secara aktif mengatakan bahwa saat ini ia tidak menerima pekerjaan.
Baca selengkapnya
504 Gateway Timeout — Penyebab dan Cara Mengatasinya
504 bukan berarti backend mati, melainkan backend hidup tapi terlalu lambat. Itu mengubah tempat Anda mencari: bukan log crash, melainkan query atau panggilan eksternal yang berjalan lebih lama daripada kesabaran server.
Baca selengkapnya