--- title: "Penyebab MySQL Sering Mati Sendiri dan Solusinya" description: "MySQL atau MariaDB sering mati sendiri? Kenali penyebab umumnya, dari RAM habis, disk penuh, sampai konfigurasi salah, dan cara memastikannya dari log." url: "https://nivelva.com/insight/penyebab-mysql-sering-mati-sendiri-solusinya" category: "Server \u0026 Infrastruktur" tags: ["mysql","mariadb","database","oom killer","troubleshooting"] author: "Theresia Candiawan" published: "2026-11-07T10:39:00+07:00" updated: "2026-11-07T10:39:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Penyebab MySQL Sering Mati Sendiri dan Solusinya > **Jawaban singkat:** MySQL yang sering mati sendiri paling sering disebabkan OOM killer karena RAM server habis, disk penuh, konfigurasi memori yang terlalu besar, atau kerusakan tabel InnoDB. Log error database dan log kernel hampir selalu menunjukkan penyebab mana yang terjadi. 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 | Penyebab | Jejak di log | Arah perbaikan | |:--|:--|:--| | OOM killer | Log kernel: `Out of memory: Killed process ... (mysqld)` | Kurangi pemakaian memori, tambah swap atau RAM | | Disk penuh | Log database: pesan disk full atau gagal menulis file | Bersihkan disk, pindahkan atau rotasi log | | Konfigurasi salah | Gagal start setelah mengubah my.cnf, ada pesan unknown variable | Perbaiki atau kembalikan baris yang diubah | | Kerusakan data InnoDB | Pesan assertion atau crash berulang saat pemulihan | Pulihkan dari backup, cadangkan data dulu | | Izin file atau keamanan | Permission denied setelah memindah folder data | Perbaiki pemilik file, konteks SELinux, atau AppArmor | ### 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](https://nivelva.com/insight/penyebab-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](https://nivelva.com/insight/optimasi-mysql-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](https://nivelva.com/insight/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. > **Hati-hati dengan innodb_force_recovery:** > > Pengaturan `innodb_force_recovery` hanya dimaksudkan untuk menyalakan database sementara agar data bisa diekspor. Dokumentasi MySQL memperingatkan bahwa nilai yang tinggi bisa merusak data secara permanen. Salin seluruh folder data sebelum mencobanya, mulai dari nilai terkecil, dan siapkan pemulihan dari backup. Inilah alasan backup database rutin tidak bisa ditawar. Caranya dijelaskan di artikel [backup database otomatis](https://nivelva.com/insight/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. ## Pertanyaan yang sering diajukan ### Apakah aman memakai skrip untuk me-restart MySQL otomatis saat mati? Sebagai pengaman sementara boleh, dan systemd sudah bisa melakukannya dengan Restart=on-failure. Namun restart otomatis tidak menyelesaikan penyebabnya, dan crash berulang tetap berisiko bagi data. ### Kenapa MySQL mati hanya pada jam tertentu? Biasanya bersamaan dengan pekerjaan terjadwal yang berat, misalnya backup, laporan, atau cron yang menjalankan banyak proses sekaligus. Cocokkan jam kejadian di log dengan jadwal cron dan timer systemd. ### Apakah pindah dari MySQL ke MariaDB menyelesaikan masalah ini? Umumnya tidak. Penyebab seperti RAM habis, disk penuh, atau setelan yang terlalu besar akan tetap terjadi di MariaDB. Perbaiki sumber masalahnya dulu sebelum mempertimbangkan pindah. ## Sumber - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/penyebab-mysql-sering-mati-sendiri-solusinya Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com