Cara Mengatasi MySQL Table Is Marked as Crashed and Should Be Repaired di WordPress

The Last Digital
Update: ... minutes read

Di log MySQL atau di layar WordPress muncul pesan yang mengkhawatirkan: “Table './database/wp_posts' is marked as crashed and should be repaired.” Situs mungkin menampilkan error di halaman tertentu saja — misalnya hanya halaman yang membaca tabel itu. Kabar baiknya: untuk tabel MyISAM, pesan ini hampir selalu bisa diperbaiki dengan perintah repair, selama Anda melakukannya dalam urutan yang benar.

Jawaban Singkat

Pesan ini adalah error 1194 (ER_CRASHED_ON_USAGE) untuk tabel yang ditandai crashed — paling sering tabel MyISAM setelah shutdown tidak bersih, crash server, atau disk penuh. Urutannya: backup dulu (bila masih bisa dibaca), periksa dengan CHECK TABLE, perbaiki dengan REPAIR TABLE, verifikasi lagi dengan CHECK TABLE. Untuk tabel InnoDB, penanganannya berbeda: InnoDB umumnya pulih sendiri saat MySQL restart, jadi jangan memaksakan REPAIR TABLE pada InnoDB.

Kenapa Tabel Bisa Crash?

PenyebabPenjelasan
Shutdown tidak bersih / kill -9MySQL dimatikan paksa saat sedang menulis ke tabel
Crash server / mati listrikTulisan yang belum selesai tersimpan setengah jalan
Disk penuh saat menulisTabel tidak bisa ditulis lengkap; repair pun gagal bila disk tetap penuh
Kerusakan filesystem/hardwareLebih jarang, tetapi perlu diperiksa bila crash berulang

Persiapan — Jangan Lewati Langkah Ini

  • Periksa ruang disk dulu (df -h). Bila disk penuh, bebaskan ruang dulu — repair pada disk penuh akan gagal atau membuat tabel crash lagi.
  • Buat salinan file tabel (untuk MyISAM: file .MYD dan .MYI di /var/lib/mysql/nama-database/) atau mysqldump bila tabel masih bisa dibaca. Repair yang gagal tetap bisa merusak; cadangan adalah jaring pengaman Anda.
  • Catat nama database dan tabel persis dari pesan error.

Langkah 1: Periksa Dulu, Jangan Langsung Repair

mysql -u root -p
CHECK TABLE nama_database.wp_posts;

Hasilnya memberi tahu tingkat kerusakan: OK berarti tabel sehat (pesan error mungkin dari kondisi lama), sedangkan status corrupt/crashed mengonfirmasi perlunya repair. Untuk memeriksa seluruh database tanpa masuk ke prompt MySQL:

mysqlcheck --check nama_database -u root -p

Langkah 2: Perbaiki dengan REPAIR TABLE

REPAIR TABLE nama_database.wp_posts;
CHECK TABLE nama_database.wp_posts;

Bila repair standar belum cukup, ulangi dengan opsi extended yang lebih teliti (lebih lambat karena memeriksa setiap baris):

REPAIR TABLE nama_database.wp_posts EXTENDED;

Untuk banyak tabel sekaligus: REPAIR TABLE nama_database.tabel1, nama_database.tabel2; atau mysqlcheck --repair nama_database -u root -p. Hindari REPAIR TABLE ... USE_FRM kecuali sebagai jalan terakhir — opsi itu bisa kehilangan data karena membangun ulang tabel dari definisi .frm tanpa data indeks yang rusak.

Langkah 3: Bila Repair Online Gagal — Perbaiki Offline dengan myisamchk

Khusus tabel MyISAM, alat offline myisamchk bisa dipakai — tetapi hanya setelah MySQL dihentikan, agar tidak ada proses lain yang menulis ke tabel:

sudo systemctl stop mysql
sudo myisamchk -r /var/lib/mysql/nama_database/wp_posts.MYI
sudo systemctl start mysql

Bila masih gagal, ulangi dengan myisamchk -r --update-state /var/lib/mysql/nama_database/wp_posts.MYI agar MySQL menandai tabel sudah diperiksa, lalu restart MySQL dan uji lagi.

Langkah 4: Periksa dengan phpMyAdmin (Bila Tanpa SSH)

Buka phpMyAdmin > pilih database > centang tabel yang bermasalah > dari dropdown “With selected” pilih Check Table untuk konfirmasi, lalu pilih Repair Table. Setelah itu jalankan Check Table lagi untuk memastikan statusnya OK.

Verifikasi Hasil dan Pencegahan

Perbaikan berhasil bila CHECK TABLE mengembalikan OK, halaman WordPress yang sebelumnya error kini memuat normal, dan tidak ada lagi pesan crashed di log MySQL. Untuk mencegah terulang:

  • Matikan MySQL dengan benar (systemctl stop, bukan kill -9) setiap kali maintenance.
  • Pantau ruang disk dengan alarm sebelum penuh — disk penuh adalah penyebab crash yang paling bisa dicegah.
  • Pertimbangkan migrasi tabel MyISAM lama ke InnoDB untuk tabel yang sering ditulis, karena InnoDB memiliki crash recovery sendiri.
  • Jadwalkan pemeriksaan berkala (mysqlcheck --check) di luar jam sibuk, karena pemeriksaan mengunci tabel saat dibaca.

Troubleshooting Lanjutan

SituasiLangkah berikutnya
Repair OK tetapi error kembaliPeriksa disk, filesystem, dan kesehatan hardware; crash berulang bukan kebetulan
Tabel InnoDB yang errorJangan REPAIR TABLE; restart MySQL untuk crash recovery, lalu periksa log InnoDB
Repair gagal karena disk penuhBebaskan ruang dulu, baru ulangi repair
Data hilang setelah repairKembalikan dari cadangan; jangan mengulang repair pada tabel yang sama tanpa cadangan baru

FAQ

Apakah repair menghapus data saya?

Repair standar berusaha mempertahankan data. Namun repair pada tabel yang sudah rusak parah bisa kehilangan sebagian baris — itulah mengapa cadangan sebelum repair wajib.

Kenapa hanya satu halaman WordPress yang error?

Karena hanya tabel yang dipakai halaman itu yang crash. Halaman lain yang membaca tabel sehat tetap normal.

Apakah perlu menghentikan situs saat repair?

Untuk repair online (REPAIR TABLE), tidak harus — tetapi lakukan di luar jam sibuk. Untuk myisamchk offline, MySQL harus dihentikan sehingga situs akan down selama proses.

Kesimpulan

Tabel crashed bukan akhir dari database Anda: periksa dulu, perbaiki dengan REPAIR TABLE, verifikasi dengan CHECK TABLE, dan pakai myisamchk offline bila perlu. Yang membedakan perbaikan yang aman dengan yang berisiko hanyalah satu hal: cadangan sebelum repair, dan disk yang cukup untuk menyelesaikannya.

Referensi

Tags:

Related Posts

Memuat…
Cookie Consent