Error 504 dan Gagal Update Percona Mysql 5.7 Hiks

بِسْمِ اللهِ الرَّحْمٰنِ الرَّحِيْمِ

Ceritanya ketika 2 hari website ndak bisa di akses, panik?? ga juga si. wkwkwkwk…. Sudah terlatih untuk tidak panik dalam setiap keadaan, tenang dan berpikir untuk mencari solusinya (Makasih kak Wid sudah mengajarkan banyak hal 😄) selalu teringat perkataannya jangan pernah panik kalo ada masalah hahaha….

Okey lanjut kepermasalahan ini, setalah di kontak pak Boss Chainloader katanya tolong liatin server karena muncul error 504. Setelah saya cakcek cakcek dan cari wangsit ke mbah gugel, setelah banyak cara kucoba, sempat berpikir apa karena config NGINX ya?? lalu otak atik NGINX, PHP-FPM, sampe baca dokumentasi NGINX dan PHP-FPM, baca fungsi dari setiap baris config, hasilnya? GAGAL..!!! 😭, cari lagi, coba, dan GAGAL lagi, hari sabtu ini saya habiskan untuk mempelajari lebih dalam tentang NGINX dan PHP-FPM, seharian full sampe lupa ternyata terakhir makan jum’at sore kemarin, ngahaha…

Terus berpikir dan belajar kenapa ini…??? konfig nginx dan php-fpm sudah bener semua, SELinux juga udh bener, firewall juga aman-aman aja. Apa DB-nya yaaa…. hmmm dan cobalah saya connect ke db, lho kok ga nyaut, coba update dengan perintah :

sudo yum update -y

lhooo kok ada error gini

The GPG keys listed for the “Percona-Release YUM repository - x86_64” repository are already installed but they are not correct for this package.

Check that the correct key URLs are configured for this repository.

Tanya lagi ke gugel cari wangsing, dan ketemu dengan artikel ini. Ternyata per 20 Desember 2018 percona mengubah enkripsi baru untuk update produknya. Solusinya tinggal jalankan perintah seperti berikut:

sudo yum update percona-release -y

Lalu update seperti biasa

sudo yum update --skip-broken

yeayy bisa juga update, btw kenapa saya pilih langsung update sistem karena sudah mentok semua config dan tweaking nginx php-fpm sudah bener semua tapi masih muncul Error 504, eh malah nemu case baru kalo GPG percona ganti, yudah deh langsung sikaat (ini di server WebApp ya). Setelah update system dan reboot coba lagi akses dan hasilnya sama aja.

Coba cek DB server dan coba update sama seperti yang saya lakukan di WebApp server muncul error baru

OSError: [Errno 28] No space left on device

wah wah jackpot ni dapet banyak case, dan akhirnya nemu di artikel yang ini katanya coba liat partisi / pasti habis, dan kucek dengan perintah :

sudo du -h

dan benar saja disk 1,3 TB habis, sadis gaa tuh…. cakcek cakcek lagi tenyata space harddisk abis dimakan Binary Logs mysql, cari lagi solusi di gugel nemu artikel yang ini nih, baca baca baca ohh ternyata binary logs itu tempat untuk nyimpen log query mysql dan informasi lainnya yang tidak berjalan seperti seharusnya atau dengan kata lain nyimpenin informasi error dari query, biasanya logs ini berlokasi di var/lib/mysql/, setelah dicek benar saja 1 file binary log sekita 1.1G dan itu ada puluhan atau ratusan, terpikir untuk hapus manual pake perintah rm -f <filenya> tapi ragu, baca baca lagi cari literatur lain dan tepat sekali ada orang diluar sana yang tidak merekomdasikan hal itu, hmmm….

Akhirnya nemu caranya yaitu dengan mengedit file my.cnf kepunyaan mysql, file ini berfungsi untuk mengopimalkan service mysql. Dan walaaaa file ini kubuat tahun 2018 kmren yang pada saat itu diri ini masih noob (sekarang juga masih si, huehehee… 🙏), kusalah config dan tweaking yang akhirnya mengakibatkan besarnya file binary log, pada saat itu aku buat confinya gini :

...

innodb-log-file-size           = 4GB
# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

...

config diatas membuat mysql memiliki file log yang guede banget sampe harddisk 1,3 TeraByte habiss…. dan akhirnya saya edit jadi gini :

...

innodb-log-file-size           = 64M
# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 2
sync-binlog                    = 1

...

lalu

sudo systemctl restart mysql

dan yeayyy berhasil, free spacenya jadi normal lagi, akhirnya bisa kembali diakses website-websitenya.

Dengan semua case yang kutemukan kali ini artinya banyak query pada aplikasi yang belum optimal sehingga tercatat di binary logs, hmmm PR baru yang kali ini masuk ranah aplikasi, ah sudahlah itu kita lanjutkan sambil jalan saja, setidaknya penyakit sudah ter-diaknosa, ahahahaha. Dan sudah ada penanganan pertama pada website yang tidak bisa dibuka.

Tidak sia-sia pelajaran hari ini, seharian berdiam di kos menatap syahdu layar laptop, banyak ilmu yang didapat, yang tadinya hanya paham 70% nambah jadi 85% (misal lho ini… 😝), dan pasti banyak ilmu lainnya yang belum kuketahui, makanya keep learning, belajar setiap saat, berpikir dan menelaah setiap hal baru, fokus berkarya dan berusaha bermanfaat.

Sudah terlalu panjang curhat malam ini, kita cukupkan sampai sini dulu, mon maap kalo bahasanya masih berantakan ahahaha, maklum masih anak baru. 😘😘


10 Maret 2019
00:10 WIB
Banguntapan, Bantul
Yogyakarta

comments powered by Disqus