Berita TeknologiBerita
MySQL 8.0 Sudah Habis Dukungan, Saatnya Pindah ke 8.4
MySQL 8.0 mencapai akhir masa pakai April 2026. Langkah upgrade ke MySQL 8.4 LTS, termasuk jebakan mysql_native_password dan perintah replikasi lama.
Jawaban singkat
Per 11 November 2026, catatan rilis resmi menyebut MySQL 8.0 mencapai akhir masa pakai pada April 2026 dengan versi terakhir 8.0.46. Pindah ke MySQL 8.4 LTS bisa langsung, asal akun mysql_native_password, perintah replikasi lama, dan opsi konfigurasi yang dihapus dibereskan dulu.
Daftar isi
Masih memakai MySQL 8.0 di server produksi? Per 11 November 2026, catatan rilis resmi MySQL menyatakan bahwa sejak April 2026, dengan versi 8.0.46 yang dirilis 21 April 2026, MySQL 8.0 mencapai akhir masa pakai (End of Life). Halaman pengumuman EOL di mysql.com menambahkan bahwa sejak 21 April 2026 versi ini masuk Oracle Sustaining Support, dan pengguna dianjurkan pindah ke MySQL 8.4 LTS atau 9.7 LTS.
Bagi pengguna edisi Community, artinya sederhana: tidak ada lagi rilis perbaikan bug maupun keamanan untuk 8.0. Kabar baiknya, upgrade dari 8.0 ke 8.4 didukung langsung, dan kebanyakan aplikasi web berjalan tanpa perubahan kode. Yang perlu disiapkan justru akun pengguna dan konfigurasi server.
Kenapa 8.4, bukan langsung 9.x?
Sejak 2023, MySQL memakai dua jalur rilis: Innovation (fitur baru, masa dukungan pendek) dan LTS (stabil, masa dukungan panjang). Menurut manual MySQL 8.4, seri LTS mengikuti Oracle Lifetime Support Policy dengan 5 tahun dukungan utama dan 3 tahun dukungan diperpanjang. MySQL 8.4 dirilis April 2024, sehingga masih punya waktu panjang.
Upgrade resmi didukung dari satu seri LTS ke seri LTS berikutnya, misalnya 8.4 ke 9.7. Untuk server yang masih di 8.0, lompatan ke 8.4 adalah langkah terkecil dan paling aman. Pindah ke 9.7 bisa dipertimbangkan nanti dari 8.4.
Langkah upgrade MySQL 8.0 ke 8.4
- Pastikan sudah di 8.0 terbaru. Cek dengan
SELECT VERSION();. Bila belum 8.0.46, naikkan dulu ke versi minor terakhir agar perbaikan terakhir ikut terpasang. - Ambil backup penuh dan uji restore. Downgrade di tempat dari 8.4 ke 8.0 tidak didukung. Jalan kembali yang paling bisa diandalkan adalah memulihkan cadangan yang diambil sebelum upgrade, jadi pastikan cadangan itu benar-benar bisa dipakai.
- Jalankan Upgrade Checker dari MySQL Shell. Perintahnya
mysqlsh -- util checkForServerUpgrade root@localhost:3306 --target-version=8.4.0. Alat ini memeriksa skema, akun, dan konfigurasi yang akan bermasalah di 8.4, lalu memberi daftar error dan peringatan. - Periksa akun yang memakai mysql_native_password. Jalankan
SELECT user, host, plugin FROM mysql.user;. Akun dengan plugin ini tidak bisa login setelah upgrade bila plugin tidak diaktifkan (lihat bagian berikut). - Bersihkan file konfigurasi. Hapus atau ganti opsi yang sudah dihapus di 8.4 dari
my.cnf, misalnyadefault_authentication_plugindanexpire_logs_days. Server bisa gagal menyala bila opsi yang tidak dikenal masih tertulis. - Ganti perintah replikasi lama di skrip. Perintah seperti
SHOW SLAVE STATUSdanCHANGE MASTER TOsudah dihapus dan menghasilkan syntax error. Perbarui skrip pemantauan dan otomasi. - Upgrade di server uji dulu. Jalankan aplikasi terhadap salinan database di 8.4, termasuk tugas terjadwal dan laporan berat.
- Upgrade produksi dan pantau. Perhatikan log error, waktu respons query, dan pemakaian memori selama beberapa hari pertama.
Jebakan paling sering: mysql_native_password
Di MySQL 8.4, plugin autentikasi mysql_native_password sudah usang dan tidak lagi aktif secara bawaan. Aplikasi lama yang membuat akun database dengan plugin ini akan tiba-tiba gagal terhubung setelah upgrade, padahal kata sandinya benar.
Ada dua jalan keluar. Yang dianjurkan: ubah akun ke caching_sha2_password, misalnya ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'kata-sandi-baru';, lalu pastikan driver aplikasi mendukungnya. Sebagai jalan sementara, plugin lama bisa diaktifkan lagi dengan menambahkan mysql_native_password=ON di bagian [mysqld] pada file konfigurasi. Jangan jadikan ini solusi permanen, karena plugin itu sudah ditandai untuk dihapus.
Perubahan bawaan yang memengaruhi performa
MySQL 8.4 mengubah sejumlah nilai bawaan InnoDB. Contohnya innodb_adaptive_hash_index kini mati secara bawaan, innodb_change_buffering menjadi none, dan innodb_io_capacity naik menjadi 10000. Bila kamu tidak pernah menyetel nilai ini secara eksplisit, server akan otomatis memakai nilai baru. Biasanya ini baik untuk server dengan SSD, tapi ukur dulu di server uji. Pembahasan menyetel MySQL secara umum ada di optimasi MySQL dan MariaDB.
Satu lagi: opsi restrict_fk_on_non_standard_key aktif secara bawaan, sehingga foreign key baru yang merujuk ke kunci tidak unik atau parsial ditolak. Database lama tetap bisa di-upgrade, tapi server akan menulis peringatan untuk foreign key semacam itu.
Ringkasan perubahan penting
| Hal | MySQL 8.0 | MySQL 8.4 | Yang perlu dilakukan |
|---|---|---|---|
mysql_native_password | Aktif | Tidak aktif secara bawaan | Pindahkan akun ke caching_sha2_password |
default_authentication_plugin | Ada (usang) | Dihapus | Pakai authentication_policy |
CHANGE MASTER TO, START SLAVE | Masih jalan | Dihapus | Pakai CHANGE REPLICATION SOURCE TO, START REPLICA |
expire_logs_days | Ada (usang) | Dihapus | Pakai binlog_expire_logs_seconds |
mysql_upgrade, mysqlpump | Ada | Dihapus | Upgrade dilakukan server otomatis, pakai mysqldump atau MySQL Shell |
innodb_io_capacity bawaan | 200 | 10000 | Uji performa, setel bila perlu |
Server yang memakai replikasi perlu perhatian ekstra. Urutan yang umum adalah meng-upgrade replika lebih dulu, baru sumber. Dasar replikasinya dijelaskan di replikasi database MySQL.
Pertanyaan yang sering diajukan
Apakah MySQL 8.0 langsung berhenti bekerja?
Tidak. Server tetap berjalan, tapi Oracle tidak lagi merilis perbaikan untuk edisi Community. Celah keamanan yang ditemukan setelah April 2026 tidak akan ditambal.
Apakah WordPress dan Laravel berjalan di MySQL 8.4?
Umumnya ya, karena driver PHP modern sudah mendukung caching_sha2_password. Tetap uji di server staging, terutama plugin yang menjalankan query mentah.
Bagaimana dengan database terkelola di cloud?
Penyedia cloud punya jadwal sendiri dan beberapa menawarkan dukungan tambahan berbayar untuk 8.0. Ikuti pengumuman penyedia yang kamu pakai.
Lebih baik pindah ke MariaDB atau PostgreSQL saja?
Bisa, tapi itu proyek migrasi, bukan upgrade. Bila aplikasimu sudah berjalan baik di MySQL, upgrade ke 8.4 jauh lebih sedikit risikonya.
Apakah upgrade bisa dibatalkan?
Tidak bisa secara di tempat. Menurut manual MySQL 8.4, kembali ke 8.0 hanya didukung lewat dump dan load logis atau replikasi, dan hanya untuk keperluan rollback sebelum fitur baru 8.4 dipakai. Karena itu backup sebelum upgrade tetap wajib.
Checklist sebelum upgrade:
- Versi 8.0 sudah minor terakhir (8.0.46)
- Backup penuh sudah diuji restore
- Upgrade Checker bersih dari error
- Tidak ada akun aplikasi yang masih memakai
mysql_native_password my.cnfbebas opsi yang dihapus- Skrip replikasi dan pemantauan memakai perintah baru
- Aplikasi sudah diuji di server 8.4
