Mengira Aplikasi PHP Lama Tetap Bisa Konek Setelah Upgrade ke MySQL 8

Banyak yang berasumsi begini: selama username dan password database tidak diubah, aplikasi PHP lama pasti tetap bisa konek setelah server di-upgrade ke MySQL 8. Kenyataannya, setelah upgrade sering muncul error koneksi, padahal kredensial di wp-config.php atau file config aplikasi masih sama persis. Masalahnya bukan di password. Yang berubah adalah cara password itu dicocokkan antara client dan server.

Kenapa password yang sama tetap ditolak

Saat aplikasi PHP konek ke MySQL, ada proses jabat tangan (handshake). Server memberi tahu client metode autentikasi apa yang dipakai user tersebut, lalu client harus bisa menjalankan metode itu. Metode ini disebut authentication plugin, yaitu modul di MySQL yang menentukan bagaimana password disimpan dan diverifikasi. Kalau client tidak mengenal plugin yang diminta server, koneksi gagal sebelum password sempat dicek. Jadi dari sisi pengguna kelihatannya seperti salah password, padahal client bahkan tidak tahu cara mengirimkannya. Di PHP, gejalanya biasanya berupa pesan seperti ini:

TEXT

# contoh format output, bukan log asli
PDOException: SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client
mysqli_connect(): The server requested authentication method unknown to the client [caching_sha2_password]

Nama plugin di akhir pesan mysqli itu petunjuk paling jelas. Kalau tertulis caching_sha2_password, hampir pasti ini soal kompatibilitas client, bukan kredensial.

Apa yang sebenarnya berubah di MySQL 8

Di MySQL 5.7 dan sebelumnya, user umumnya dibuat dengan plugin mysql_native_password. Plugin ini sudah lama sekali ada, dan hampir semua driver database, termasuk ekstensi PHP versi lama, mendukungnya. MySQL 8 mengganti default-nya menjadi caching_sha2_password. Plugin ini memakai hashing SHA-256 yang lebih kuat, ditambah cache di memori server supaya login berikutnya tetap cepat. Dari sisi keamanan ini perubahan yang masuk akal. Dari sisi kompatibilitas, ini memutus client yang belum mengenal plugin baru. Di sinilah asumsi 'password tidak berubah' jadi menyesatkan. Ada beberapa situasi yang sering terjadi:

Server di-upgrade in-place dari 5.7 ke 8.0. User lama biasanya tetap memakai mysql_native_password, jadi aplikasi lama masih jalan. Masalah baru muncul saat ada user baru dibuat, atau password user lama di-reset. User itu otomatis ikut default baru.
Database dipindah ke server baru dengan MySQL 8 lewat dump dan restore, lalu user dibuat ulang. Password-nya sama, tapi plugin-nya sekarang caching_sha2_password.
User dibuat lewat panel kontrol atau script provisioning di server MySQL 8. Hasil plugin-nya tergantung bagaimana panel atau script itu menulis perintah CREATE USER.

Ketiga situasi ini terlihat sama dari luar: kredensial tidak berubah, tapi koneksi gagal. Itu sebabnya pertanyaan di tiket support biasanya berbunyi 'saya tidak ganti apa-apa', dan secara literal itu memang benar. Perlu dicatat juga, ini spesifik MySQL. MariaDB punya jalur plugin autentikasinya sendiri dan tidak memakai caching_sha2_password sebagai default, jadi jangan langsung menyamakan keduanya saat diagnosis.

Kenapa kadang jalan, kadang gagal

Ada satu pola yang sering bikin bingung: aplikasi bisa konek, lalu setelah MySQL di-restart tiba-tiba gagal. Atau aplikasi baru bisa konek setelah seseorang login manual lewat CLI mysql. Ini bukan kebetulan. caching_sha2_password punya dua jalur. Login pertama kali disebut full authentication. Di jalur ini password harus dikirim lewat koneksi yang aman, yaitu TLS, Unix socket, atau dienkripsi dengan RSA public key milik server. Setelah sukses, server menyimpan hash di cache, dan login berikutnya cukup lewat fast authentication yang lebih ringan. Cache itu hidup di memori. Restart MySQL, perubahan password, atau FLUSH PRIVILEGES bisa mengosongkannya. Begitu cache kosong, login berikutnya kembali ke full authentication. Akibatnya:

Client yang konek lewat TCP tanpa TLS, misalnya ke 127.0.0.1 atau ke server database terpisah, butuh pertukaran RSA key saat full authentication. Kalau client tidak bisa melakukannya, atau ekstensi OpenSSL di PHP tidak tersedia, login gagal.
Kalau sebelumnya ada client lain (misalnya CLI mysql lewat socket) yang sudah login dan mengisi cache, aplikasi bisa ikut lolos lewat fast authentication. Kelihatannya beres, padahal hanya menumpang cache.

Jadi kalau gejalanya intermiten dan berkaitan dengan restart, perhatikan juga cara aplikasi konek: lewat localhost (biasanya socket) atau 127.0.0.1 (TCP). Perbedaan kecil ini mengubah jalur autentikasi.

Cara cek plugin yang dipakai tiap user

Langkah pertama selalu sama: lihat plugin apa yang menempel di user yang dipakai aplikasi. Login sebagai user dengan hak cukup (biasanya root) dan jalankan query read-only ini:

SQL

-- Lihat plugin autentikasi tiap user
SELECT user, host, plugin FROM mysql.user ORDER BY user;

-- Lihat default plugin di server ini
SHOW VARIABLES LIKE 'default_authentication_plugin';
SHOW VARIABLES LIKE 'authentication_policy';

-- Lihat plugin yang aktif dan statusnya
SELECT plugin_name, plugin_status FROM information_schema.plugins
WHERE plugin_name LIKE '%password%';

Dua hal yang perlu diperhatikan dari hasilnya. Pertama, pastikan kolom host cocok dengan cara aplikasi konek. User app@localhost dan [email protected] adalah dua user berbeda di MySQL, dan bisa saja punya plugin berbeda. Kedua, di versi MySQL yang lebih baru, variabel default plugin bisa berpindah ke authentication_policy, jadi salah satu dari dua query SHOW VARIABLES itu mungkin kosong. Itu normal. Setelah itu, cek versi PHP yang benar-benar dipakai situs. Hati-hati, PHP di CLI sering berbeda dengan PHP yang menjalankan website, terutama di server dengan beberapa versi PHP atau PHP-FPM per akun. Cara paling pasti adalah melihat pengaturan versi PHP di panel untuk domain itu, atau membuat file phpinfo() sementara lalu menghapusnya lagi setelah dicek. Yang dicari: versi PHP, apakah driver yang dipakai mysqlnd, dan apakah ekstensi OpenSSL aktif. Sebagai patokan umum, PHP 7.4 ke atas dengan mysqlnd sudah mendukung caching_sha2_password. Versi 7.x yang lebih tua dukungannya parsial dan tidak konsisten, sedangkan PHP 5.x tidak mendukung sama sekali.

Update client atau mengatur ulang user

Ada dua arah perbaikan, dan pilihannya tergantung seberapa lama aplikasi itu masih akan dipakai. Arah yang benar untuk jangka panjang adalah menaikkan versi PHP sampai client-nya mengenal caching_sha2_password. Ini sekaligus menutup masalah lain, karena PHP versi lama juga sudah tidak menerima patch keamanan. Kalau koneksinya lewat TCP ke server database terpisah, pertimbangkan juga mengaktifkan TLS di koneksi MySQL supaya full authentication tidak bergantung pada RSA key exchange. Masalahnya, aplikasi lama sering tidak bisa langsung jalan di PHP baru. Fungsi yang dihapus, ekstensi mysql_* yang sudah tidak ada sejak PHP 7, atau framework yang tidak di-maintain. Untuk kasus seperti ini, solusi sementara yang umum adalah mengatur user aplikasi tersebut agar kembali memakai mysql_native_password:

SQL

-- Hanya untuk user aplikasi lama yang belum bisa upgrade PHP.
-- Ganti nama user, host, dan password sesuai setup kamu.
ALTER USER 'app_lama'@'localhost'
  IDENTIFIED WITH mysql_native_password BY 'password_yang_sama';

-- Setelah PHP sudah diperbarui, kembalikan ke plugin default:
ALTER USER 'app_lama'@'localhost'
  IDENTIFIED WITH caching_sha2_password BY 'password_yang_sama';

Perintah ini mengubah cara password user disimpan, jadi password harus ditulis ulang di perintahnya. Pastikan kamu menulis password yang persis sama dengan yang ada di config aplikasi, karena kalau berbeda aplikasi langsung putus. Ubah satu user saja yang memang dipakai aplikasi lama, bukan semua user di server. Ada dua catatan penting untuk jalan pintas ini. Pertama, ini bukan solusi permanen. Di MySQL 8.4, mysql_native_password tidak lagi aktif secara default dan harus dinyalakan manual lewat konfigurasi server, sedangkan di seri 9.x plugin ini sudah dihapus. Artinya user yang diturunkan ke plugin lama akan bermasalah lagi di upgrade berikutnya. Kedua, jangan mengubah default plugin seluruh server hanya demi satu aplikasi. Mengatur per user jauh lebih terkontrol dan tidak menurunkan keamanan user lain. Dari sisi support, urutan pengecekan yang paling cepat biasanya: baca pesan error lengkapnya, cek kolom plugin dan host user yang dipakai aplikasi, lalu cek versi PHP yang menjalankan situs. Tiga hal ini hampir selalu cukup untuk membedakan masalah plugin dari masalah password sungguhan. Intinya, upgrade ke MySQL 8 bukan hanya soal data yang ikut pindah, tapi juga soal client yang masih bisa bicara dengan server. Sebelum upgrade atau migrasi, catat versi PHP tiap aplikasi dan cek plugin tiap user database. Kalau masih ada aplikasi yang terjebak di PHP lama, turunkan plugin hanya untuk user itu sebagai jembatan, sambil menjadwalkan upgrade PHP-nya sebelum kamu naik ke MySQL 8.4 atau lebih baru.