Penyebab MySQL Sering Mati Sendiri dan Solusinya

MySQL yang sering mati sendiri hampir selalu punya penyebab yang bisa dilacak, dan yang paling umum adalah server kehabisan memori sehingga kernel mematikan proses database.

Ini penting karena setiap kali database mati, website ikut menampilkan error koneksi database, pesanan bisa gagal tersimpan, dan pekerjaan terjadwal berhenti di tengah jalan. Menambahkan skrip yang me-restart MySQL setiap kali mati memang membuat website cepat pulih, tapi penyebabnya tetap ada dan risikonya menumpuk. Langkah yang lebih baik adalah membaca jejaknya, lalu memperbaiki sumbernya.

Di mana jejak penyebabnya tersimpan?

Ada dua tempat yang harus dibuka, dan keduanya perlu dicocokkan waktunya.

Log error database. Lokasinya berbeda tergantung paket dan distribusi:

• MySQL di Ubuntu dan Debian: /var/log/mysql/error.log
• MySQL di AlmaLinux dan Rocky Linux: /var/log/mysql/mysqld.log atau /var/log/mysqld.log, tergantung sumber paketnya
• MariaDB di AlmaLinux dan Rocky Linux: /var/log/mariadb/mariadb.log
• MariaDB di Ubuntu dan Debian sering menulis ke journal: journalctl -u mariadb

Kalau tidak yakin, jalankan SHOW VARIABLES LIKE 'log_error'; dari klien MySQL saat database sedang hidup.

Log kernel. Bila log database berhenti mendadak tanpa pesan shutdown, kemungkinan besar prosesnya dibunuh dari luar. Cari dengan journalctl -k | grep -i "killed process".

Lima penyebab paling umum

1. Kehabisan memori (OOM killer)

Ini penyebab nomor satu di VPS kecil yang menjalankan web server, PHP, dan database sekaligus. Saat RAM dan swap habis, kernel memilih proses dengan pemakaian memori terbesar untuk dimatikan, dan itu hampir selalu mysqld. Penjelasan lengkap mekanismenya ada di artikel proses mati mendadak karena OOM killer.

Yang perlu dicek di sisi database:

• innodb_buffer_pool_size. Panduan untuk server database khusus sering menyarankan porsi besar dari RAM. Di server yang juga menjalankan aplikasi, angka itu harus jauh lebih kecil.
• max_connections. Setiap koneksi memakai memori sendiri untuk buffer sort, join, dan tabel sementara. Batas koneksi yang terlalu tinggi bisa membuat pemakaian memori melonjak saat trafik ramai.
• Penyebab di luar database. Jumlah worker PHP-FPM yang terlalu banyak bisa menghabiskan RAM, lalu MySQL yang menjadi korban.

Setelan yang paling berpengaruh beserta cara menghitungnya dibahas di artikel setelan MySQL dan MariaDB.

2. Disk penuh

Database perlu menulis log transaksi, file tabel sementara, dan binary log. Saat disk penuh, operasi tulis gagal dan database bisa berhenti atau macet. Cek dengan df -h, lalu cari folder yang membengkak. Tersangka yang sering ditemui adalah binary log yang tidak pernah dihapus, log aplikasi, dan file backup lama. Langkah membersihkannya ada di artikel disk server penuh. Bila binary log yang membengkak, atur masa simpannya dengan binlog_expire_logs_seconds di MySQL.

3. Konfigurasi yang baru diubah

Database yang langsung gagal start setelah file my.cnf diedit biasanya menolak baris yang salah tulis atau variabel yang tidak dikenal oleh versinya. Pesan errornya jelas di log. Kembalikan perubahan terakhir, lalu ubah lagi satu per satu.

Di MySQL 8.0 ke atas, kamu bisa menguji file konfigurasi sebelum me-restart dengan mysqld --validate-config. Perintah ini memeriksa apakah ada opsi yang tidak dikenal atau nilai yang tidak valid, tanpa benar-benar menjalankan server. Kebiasaan ini mencegah database mati lama hanya karena satu huruf yang salah ketik, terutama saat kamu mengubah konfigurasi di server produksi yang sedang melayani pengunjung.

4. Kerusakan data InnoDB

Mati listrik, disk bermasalah, atau OOM berulang kali bisa merusak file data, meskipun InnoDB dirancang untuk pulih dari mati mendadak. Gejalanya database crash berulang saat pemulihan dan log menampilkan pesan assertion.

Inilah alasan backup database rutin tidak bisa ditawar. Caranya dijelaskan di artikel backup database otomatis.

5. Izin file setelah memindah folder data

Memindahkan folder data ke disk lain tanpa memperbaiki pemilik file (mysql:mysql), konteks SELinux di AlmaLinux, atau profil AppArmor di Ubuntu membuat database tidak bisa membaca filenya sendiri. Log akan mencatat Permission denied pada path tertentu.

Bagaimana mencegahnya terulang?

Setelah penyebab utama ditemukan, ada beberapa kebiasaan yang membuat database lebih stabil:

• Hitung total kebutuhan memori semua layanan di server, bukan hanya database.
• Siapkan swap sebagai bantalan lonjakan, bukan pengganti RAM.
• Pasang pemantauan untuk memori available, sisa disk, dan status layanan database.
• Atur rotasi log dan masa simpan binary log.
• Pastikan backup berjalan dan pernah diuji dipulihkan.

Bila database sudah menjadi beban terbesar dan terus berebut memori dengan aplikasi, memisahkannya ke server atau layanan database tersendiri sering lebih masuk akal daripada terus mengecilkan setelannya.