satu lagi problem yg bisa terjadi saat pakai db migration adalah script "down" nya ga sesuai sama "up" nya. Mungkin karena buru buru terus asal copas script sebelumnya dan function down nya lupa disesuaikan. Alhasil tabel yg di drop ga sesuai. Tapi itu ga masalah kalo masih di local sih. Ga kebayang stress nya kalo harus ngalamin masalah itu di prod, amit amit.
kasus begini akan selalu menjadi legenda dan obrolan senior to junior atau new comer dikantor dengan pengantar awal... "lo pernah dengar kisah legend gk????"
padahal hampir semua framework atau microframework memberikan peringatan ketika akan running migration di live (production). harus buat sekenario ketika akan naik ke live ya temen2pertama kali belajar windows 95, guru saya selalu bilang "baca peringatannya walaupun di bluescreen"...
ini cerita real banget, semua developer berpotensi melakukan kesalahan yang serupa, gw pernah ngedevelop web di laravel, dan bisa akses ke database production, waktu itu gw lagi mau migrate database untuk keperluan tambah relasi struktur database dan lupa untuk ubah env nya, trus gw jalanin aja itu php artisan migrate:fresh, beruntungnya itu akses database production butuh aktifkan vpn perusahaan jadinya migrate nya gagal dan baru sadar setelah di check di env (tangan dan lutut lemes seketika). semoga developer2 lain terhindar dari hal yang serupa.
Pelajaran penting dr incident2 report semacam ini, trims mas eko utk sharing nya, sy pribadi ketika mau eksekusi cmd yg kira2 ber impact perubahan data, selalu memastikan pointing env nya dulu berkali2 🙏🙏🙏
Dikantor sekarang juga sama ga dapet akses production, awalnya aga terhalang mau bikin ini itu ga bisa tp bisa dapet manfaatnya sekarang takutnya ada hal2 kyk gini. apalagi kalau mau ubah2 atau apa2 terkait database itu harus lewat DBA/DBE , dan script migration di code selalu di comment (walau jatohnya jadi membuat manual db/table/collection sih) tapi jadi aman. thanks pak insight nya
mantap sekali mas, saya senang sekali dengan video di channelnya mas eko. sampai hari inipun channel mas eko masih menjadi teman makan siang saya. terima kasihh mas 🙏🙏
Pernah kejadian juga di tempat kerja saya namun untungnya di env staging. Akhirnya kami pisahkan vpn untuk staging dan production sekalipun programmer senior dengan harapan saat development wajib menggunakan vpn staging.
Di kantor gw, development dan production dijembatani oleh satu orang. Dan gak ada seorang pun di development punya akses ke production kecuali hanya satu orang itu yang bertanggungjawab. Itu pun sebelum dimigrate, perubahan code kita di review di gitlab, baru di pull branch dan data migration.
bener yang disampaikan, ditempat saya pun hanya bbrp aja yg dikasih CRUD ke DB prod. Walopun udah ada backup berkala nya, tp ttp jaga2 byk layer. dapet insight ner uga nih, udah dibackupin berkala, tp nampaknya kelupaan buat test restore nya. thx for sharing!
Mau drop database, ataupun UPDATE query. Semua beresiko di server production. Gitu pentingnya adanya SOP atau system saat eksekusi. Jgn dibiasakan QUERY lsg di server database. Kerjaannya sih mungkin enteng, tapi krn Human Error, Akibatnya sgt fatal.
Gw pernah ngerjain project sebagai role DBA sekaligus Storage Engineer... saat itu ada storage pinjeman yg akan dibalikin. Otomatis datanya saya pindah ke storage lain. pada saat proses rebalance belum selesai, gw delete lah LUN di storagenya... 12 Database hilang cuy...
wah pernah kejadian di perusahaan sekarang. apps buat absensi ga dipakai di internal aja, tapi 2 client kami. dari engineer ada case drop database untuk SSO jadi ga bisa login. deh bikin geger itu. emang harus hati hati sih, untung pake cloud dan ada backupnya. walau beberapa data ada yagn ga ke track
pernah kejadian gini juga. dan pelakunya saya sendiri. jadi saya mau upgrade server dari Ubuntu v18 ke v20. nah karena saya fullstack jadi semuanya dikerjain sendiri. pada saat proses upgrade, ada kegagalan pada proses upgrade mysql. alhasil semua data hilang. sialnya saya gak punya backup dan lupa buat backup. pengen nangis asli dan gak bisa tidur. untungnya user gak ada yang ngeh data mereka hilang. ini jadi pelajaran buat saya kalo mau ngerjain apapun diserver, wajib backup data dulu.
saya pernah, delete data di production punya client, panic untung temen gw nenangin dan akhirnya kontak pihak hosting, alhamdulillah ada snapshot bbrp jam sebelumnya, sisanya saya minta pemilik toko untuk stock opname ulang di semua cabang karena system crash (ini aplikasi POS) alhamdulillah pemilik toko fine2 aja malah karena kejujuran saya dan cara saya nanganin masalah gitu dia malah respect dan sering ngontak saya secara pribadi sampe sekarang
Untuk di case aku sih kemarin juga gk sengaja timku delete data production, tapi untungnya aku udh buatin function di server untuk buat backup SQLite every transaction, jadi untuk restore bisa paling makan 2-3 jam-an
Pernah restart vps terus mongodb gagal restart. Karena bingung ujung2 install ulang mongodbnya dan gak bisa backup. Untung cari2 di vpsnya ada backup databaenya. Tetapi sekali di restore malah banyak error😢
pernah juga kejadian di kantor lama udah backup DB tapi ga pernah ngelakuin regular restore dan bener aja kejadian ga sengaja nge-drop DB prod dan saat mau restore file backupnya ternyata gagal di restore, beruntung itu data dari app yg masih beta test dan baru nyimpen dikit data transaksi user.
sempet liat incident kaya gini, antara rm -rf / dan delete from tbl tanpa filter where di prod 😆 tp ya untungnya bisa segera solved dan kejadiannya bkn dijam sibuk, jadi gak heboh haha
gue sebagai devops engineer pasti pegang akses production, agak ngeri2 sedap kalo apus data production wkwkkwkwkw, pernah ngerasain. jujur waktu itu karena ngantuk tapi beruntungnya waktu itu bikin cron backup.
Dapet cerita dari temen, atasan dia gk sengaja drop db di cmd server tapi temen gue jg malah disalahin dan minta tanggung jawab berdua. Alhasil semua data harus diinput manual lagi 😂
Ini yang paling gw takutin ketika disuruh cleansing data atau data fix sama user dan lead. Neken enter nya sambil komat2 & keringet dingin. Gak bisa bayangin sih kalo case nya kalo satu db ke drop
Case aku pernah human error di production, tapi bukan drop database, aku flutter developer, jadi aku gak sengaja ngubah env production jadi development, apinya berubah ke api dev gk prod, mana aplikasi udah update udah rilis, jadi 1 hari perusahaan dimatikan dulu gk nerima transaksi, untung saya gal dipecat, mungkin karena masih hitungan magang juga, tapi sejak itu bener bener harus teliti liat file lagi
baru kejadian sama saya 1 bulan lalu, tiba2 ada temen 1 team ngehapus project di gcp, otomatis semua yang ada di dalam project nya ke hapus (vm, db, dll) untung aja masih bisa di restore
Inilah alasan saya masih lebih percaya PHPmyadmin dan DB Manager dari pada Command Console dan Migration Schema yang kalo ada error perlu nunggu berjam jam buat nganalisa error log untuk menyadari apa yang sedang terjadi. Usahakan juga jangan pernah nge-whitelist DB access demi bisa diakses lewat script local di laptop. Itu fatal banget sih.
pengalaman saya as DBA serajin atau sesering apapun buat backup pastikan bisa di restore dan buat automation. nya kedua bisa informasikan ke team terutama team bisnis ada backup plan apa, selain mengandalkan restore backup dari database karena seperti sebelumnya backup itu ada gap walaupun kecil, atau bisa kerja bareng dengan team engineering nya apakah ada plan selain dari restore backup dari database
amit2 jangan sampe kejadian kyk gitu, soalnya aku biasanya pake 2 env d local, ada dev dan prod,, cuman yg prod jarang bgt aku pake, hal2 tertentu aja sih
Walaupun mereka mengalahkan kesalahan fatal tapi mereka tetap terbuka dengan apa yang terjadi dengan cukup detail. Kapan ya provider lokal kita bisa seterbuka ini kalau ada incident?
Pernah banget ngalamin njirr, pas mau running test ternyata ada kode yg menghapus seluruh table. Panik banget, untung ada backup tapi hilang data transaksi dari bbrp bulan.
Baru aja kejadian bulan lalu 😅 Jadi ada tim apps yang melakukan alter table pada salah satu db. Alhasil db nya hang, di hari jumat lagi 😂 Beruntung ada backup di hari itu, dan restorenya berhasil
klo saya, pernahnya delete load balancer yg sifatnya dynamic di GCP Prod, perusahaan mining, langsung panik gaes , untungnya bisa di buat ulang pakai deployment ulang
sebagai dba yg tiap hari nyentuh env prod, kalo denger incident gni entah dari temen atau artikel, dengkul langsung lemes rasanya , kalo ditempat saya, developer cuma dikasih akses read only ke env prod, dan user db nya tidak boleh sharing antar developer.
Ditempat saya ga ada db local, semua langsung production. testing aja pake production gegara nerusin app leluhur mana gada dokumentasi. env lokal sama dengan env production. Bahkan saya tiap mau php artisan serve aja selalu ngeri selalu teliti takut takut malah php artisan migrate 😂
QA diperlukan agar bisa recreate skenario bug di production seperti input nya apa outputnya apa. karena kalo udah di production jangan diapa2in lagi dah
pernah kejadian jg pada diri sendiri.. untung bukan data transaksi. sekarang udah direstrict aksesnya hanya bisa melalui jump host. btw untuk log ini standartnya ada ngga ya? isinya apa aja? atau beda company beda jg standartnya? satu lagi, berarti harusnya semakin banyak data yang ditulis ke log semakin besar jg ya impactnya ke performance?
wkwkwkwk di kantor gw juga pernah kejadian malah lebih parah, udah lupa backup, server production dijalanin command rm -rf di direktori root, otomatis satu server langsung kosong
kalo engineer nya gua yg baru fullstack crud dikit2 nestnextjs pasti gabakal bisa di restore selamanya kaga ngarti sama sekali gitu2an 😂 kalo ada salah mirgate auto migrate reset ajalah 😅
Bisa gk Pak Eko, meskipun dapet akses ke database production tapi hak aksesnya di batesin, kayak file sharing gitu ada yg bisa edit, ada yg cuma bisa read aja,
programmer baru jangan mau deh dikasih akses ke db production apapun alasannya. Dulu gw suka dikasih padahal diluar role gw dan sekarang gw kapok. Bebannya berat cuy. Dan kalau ada anomali pasti kita dikambing hitamkan. Jadi, walau statusnya orang baru atau junior, jangan pernah mau dikasih akses db prod, titik.
Perbanyak konten kayak gini mas, seru belajar dari kejadian2 orang kyk gini wkwkwk
setuju.. konten kyk gini tuh menjadi teman makan siang ku
Terimakasih banyak untuk insight nya Pak. 🙏otw bikin useful log 🚀
Sama2
satu lagi problem yg bisa terjadi saat pakai db migration adalah script "down" nya ga sesuai sama "up" nya. Mungkin karena buru buru terus asal copas script sebelumnya dan function down nya lupa disesuaikan. Alhasil tabel yg di drop ga sesuai. Tapi itu ga masalah kalo masih di local sih. Ga kebayang stress nya kalo harus ngalamin masalah itu di prod, amit amit.
hal yang paling ditakuti pas berurusan dengan db production: "4000 data entries have been affected"
Njir pas baca aja agak merinding bro
Salah ngefilter, ngeri euy 🗿
Baru aja kemarin 180.000 huhu
biasakan melakukan SELECT query terlebih dahulu. Baru melakukan update/delete
Biasakan gunakan transaction
kasus begini akan selalu menjadi legenda dan obrolan senior to junior atau new comer dikantor dengan pengantar awal... "lo pernah dengar kisah legend gk????"
padahal hampir semua framework atau microframework memberikan peringatan ketika akan running migration di live (production). harus buat sekenario ketika akan naik ke live ya temen2pertama kali belajar windows 95, guru saya selalu bilang "baca peringatannya walaupun di bluescreen"...
Mantap suhu
ini cerita real banget, semua developer berpotensi melakukan kesalahan yang serupa, gw pernah ngedevelop web di laravel, dan bisa akses ke database production, waktu itu gw lagi mau migrate database untuk keperluan tambah relasi struktur database dan lupa untuk ubah env nya, trus gw jalanin aja itu php artisan migrate:fresh, beruntungnya itu akses database production butuh aktifkan vpn perusahaan jadinya migrate nya gagal dan baru sadar setelah di check di env (tangan dan lutut lemes seketika). semoga developer2 lain terhindar dari hal yang serupa.
Pelajaran penting dr incident2 report semacam ini, trims mas eko utk sharing nya, sy pribadi ketika mau eksekusi cmd yg kira2 ber impact perubahan data, selalu memastikan pointing env nya dulu berkali2 🙏🙏🙏
Dikantor sekarang juga sama ga dapet akses production, awalnya aga terhalang mau bikin ini itu ga bisa tp bisa dapet manfaatnya sekarang takutnya ada hal2 kyk gini.
apalagi kalau mau ubah2 atau apa2 terkait database itu harus lewat DBA/DBE , dan script migration di code selalu di comment (walau jatohnya jadi membuat manual db/table/collection sih) tapi jadi aman. thanks pak insight nya
mantap sekali mas, saya senang sekali dengan video di channelnya mas eko. sampai hari inipun channel mas eko masih menjadi teman makan siang saya. terima kasihh mas 🙏🙏
Pernah kejadian juga di tempat kerja saya namun untungnya di env staging.
Akhirnya kami pisahkan vpn untuk staging dan production sekalipun programmer senior dengan harapan saat development wajib menggunakan vpn staging.
Di kantor gw, development dan production dijembatani oleh satu orang. Dan gak ada seorang pun di development punya akses ke production kecuali hanya satu orang itu yang bertanggungjawab. Itu pun sebelum dimigrate, perubahan code kita di review di gitlab, baru di pull branch dan data migration.
bener yang disampaikan, ditempat saya pun hanya bbrp aja yg dikasih CRUD ke DB prod. Walopun udah ada backup berkala nya, tp ttp jaga2 byk layer. dapet insight ner uga nih, udah dibackupin berkala, tp nampaknya kelupaan buat test restore nya. thx for sharing!
Lagi belajar database, jadi ngeri2 sedap😬 thank you mas eko saran nya
kesalahan fatalnya lebih ke database migration yang ada di framework seperti laravel sama environment nya
Mau drop database, ataupun UPDATE query. Semua beresiko di server production.
Gitu pentingnya adanya SOP atau system saat eksekusi.
Jgn dibiasakan QUERY lsg di server database. Kerjaannya sih mungkin enteng, tapi krn Human Error, Akibatnya sgt fatal.
8:00 sama nih, gw juga paling ga mau dapet akses production
Gw pernah ngerjain project sebagai role DBA sekaligus Storage Engineer... saat itu ada storage pinjeman yg akan dibalikin. Otomatis datanya saya pindah ke storage lain. pada saat proses rebalance belum selesai, gw delete lah LUN di storagenya... 12 Database hilang cuy...
belum ISO itu, nggak testing restore secara regular...😄😄
Sangat bermanfaat
Semoga bermanfaat
wah pernah kejadian di perusahaan sekarang. apps buat absensi ga dipakai di internal aja, tapi 2 client kami. dari engineer ada case drop database untuk SSO jadi ga bisa login. deh bikin geger itu. emang harus hati hati sih, untung pake cloud dan ada backupnya. walau beberapa data ada yagn ga ke track
pernah kejadian gini juga. dan pelakunya saya sendiri.
jadi saya mau upgrade server dari Ubuntu v18 ke v20. nah karena saya fullstack jadi semuanya dikerjain sendiri.
pada saat proses upgrade, ada kegagalan pada proses upgrade mysql. alhasil semua data hilang.
sialnya saya gak punya backup dan lupa buat backup. pengen nangis asli dan gak bisa tidur.
untungnya user gak ada yang ngeh data mereka hilang.
ini jadi pelajaran buat saya kalo mau ngerjain apapun diserver, wajib backup data dulu.
kobisa ga ngeh ya datanya hilang?
User y keluarga dia sendiri😂@@bungtomo4871
@@bungtomo4871 data lama biasanya
saya pernah, delete data di production punya client, panic
untung temen gw nenangin dan akhirnya kontak pihak hosting, alhamdulillah ada snapshot bbrp jam sebelumnya, sisanya saya minta pemilik toko untuk stock opname ulang di semua cabang karena system crash (ini aplikasi POS)
alhamdulillah pemilik toko fine2 aja malah karena kejujuran saya dan cara saya nanganin masalah gitu dia malah respect dan sering ngontak saya secara pribadi sampe sekarang
untung gak pura2 gak tau ya kak
Untuk di case aku sih kemarin juga gk sengaja timku delete data production, tapi untungnya aku udh buatin function di server untuk buat backup SQLite every transaction, jadi untuk restore bisa paling makan 2-3 jam-an
Pernah restart vps terus mongodb gagal restart. Karena bingung ujung2 install ulang mongodbnya dan gak bisa backup. Untung cari2 di vpsnya ada backup databaenya. Tetapi sekali di restore malah banyak error😢
pernah juga kejadian di kantor lama udah backup DB tapi ga pernah ngelakuin regular restore dan bener aja kejadian ga sengaja nge-drop DB prod dan saat mau restore file backupnya ternyata gagal di restore, beruntung itu data dari app yg masih beta test dan baru nyimpen dikit data transaksi user.
sempet liat incident kaya gini, antara rm -rf / dan delete from tbl tanpa filter where di prod 😆 tp ya untungnya bisa segera solved dan kejadiannya bkn dijam sibuk, jadi gak heboh haha
gue sebagai devops engineer pasti pegang akses production, agak ngeri2 sedap kalo apus data production wkwkkwkwkw, pernah ngerasain. jujur waktu itu karena ngantuk tapi beruntungnya waktu itu bikin cron backup.
Akses prod boleh tp permissionnya read only aja. Kan butuh jg utk troubleshot isu prod kadang kala.
Dapet cerita dari temen, atasan dia gk sengaja drop db di cmd server tapi temen gue jg malah disalahin dan minta tanggung jawab berdua. Alhasil semua data harus diinput manual lagi 😂
Ini yang paling gw takutin ketika disuruh cleansing data atau data fix sama user dan lead. Neken enter nya sambil komat2 & keringet dingin. Gak bisa bayangin sih kalo case nya kalo satu db ke drop
Case aku pernah human error di production, tapi bukan drop database, aku flutter developer, jadi aku gak sengaja ngubah env production jadi development, apinya berubah ke api dev gk prod, mana aplikasi udah update udah rilis, jadi 1 hari perusahaan dimatikan dulu gk nerima transaksi, untung saya gal dipecat, mungkin karena masih hitungan magang juga, tapi sejak itu bener bener harus teliti liat file lagi
baru kejadian sama saya 1 bulan lalu, tiba2 ada temen 1 team ngehapus project di gcp, otomatis semua yang ada di dalam project nya ke hapus (vm, db, dll) untung aja masih bisa di restore
Pengalaman pribadi 4 taun lalu. Meskipun solved karna temen punya mirror, saya tetep kena SP karna kedenger direksi 😅
Inilah alasan saya masih lebih percaya PHPmyadmin dan DB Manager dari pada Command Console dan Migration Schema yang kalo ada error perlu nunggu berjam jam buat nganalisa error log untuk menyadari apa yang sedang terjadi.
Usahakan juga jangan pernah nge-whitelist DB access demi bisa diakses lewat script local di laptop. Itu fatal banget sih.
ngebayangin orang yang ga sengaja ngedrop db di prod, pucat se pucat pucatnya pasti💀💀
Jantung rasanya berhenti sejenak🤣😅
@@rizalarfani7985kek nyawa dah mau lepas aja dari badan.
Lebih ngeri daripada ditolak cewek 💀
makan tak enak, tidur tak nyenyak
Pantat seketika menguncup wkwk
pengalaman saya as DBA serajin atau sesering apapun buat backup pastikan bisa di restore dan buat automation. nya
kedua bisa informasikan ke team terutama team bisnis ada backup plan apa, selain mengandalkan restore backup dari database karena seperti sebelumnya backup itu ada gap walaupun kecil, atau bisa kerja bareng dengan team engineering nya apakah ada plan selain dari restore backup dari database
Sangat bagus materinya
semoga bermanfaat
kalo sampe nge Drop sih belom.
cuma dulu pernah update data di salah satu table Production ga pake where 😅
pas select all liat hasilnya kok kembar semua datanya wkwkwkwk
amit2 jangan sampe kejadian kyk gitu, soalnya aku biasanya pake 2 env d local, ada dev dan prod,, cuman yg prod jarang bgt aku pake, hal2 tertentu aja sih
Walaupun mereka mengalahkan kesalahan fatal tapi mereka tetap terbuka dengan apa yang terjadi dengan cukup detail. Kapan ya provider lokal kita bisa seterbuka ini kalau ada incident?
harusnya di previlege nya untuk production hanya untuk read only disesuaikan berdasarkan user ldap yang login
Pernah banget ngalamin njirr, pas mau running test ternyata ada kode yg menghapus seluruh table. Panik banget, untung ada backup tapi hilang data transaksi dari bbrp bulan.
Baru aja kejadian bulan lalu 😅
Jadi ada tim apps yang melakukan alter table pada salah satu db. Alhasil db nya hang, di hari jumat lagi 😂
Beruntung ada backup di hari itu, dan restorenya berhasil
di tempat saya bekerja di kasih Laptop kantor mereka dan di kasih akses DB Prod, kadang panas dingin klo disuruh hapus data.
klo saya, pernahnya delete load balancer yg sifatnya dynamic di GCP Prod, perusahaan mining, langsung panik gaes , untungnya bisa di buat ulang pakai deployment ulang
jarang-jarang ada kompeni yang ngakuin kesalahannya dan jelaskan kesalahannya secara real
Padahal cuma nonton ini, tapi ikut degdegan.. kaya horror banget
sama, ngebayangin klo terjadi beneran di gw 🤣
Kelihatan fitur database tidak digunakan secara penuh, padahal ada fitur hak akses sesuai cred db.
saya dulu bukan delete sih tapi update row sql, saya pikir kan di env local eh taunya di prod dong. asli panik banget sih itu hahaha
sebagai dba yg tiap hari nyentuh env prod, kalo denger incident gni entah dari temen atau artikel, dengkul langsung lemes rasanya ,
kalo ditempat saya, developer cuma dikasih akses read only ke env prod, dan user db nya tidak boleh sharing antar developer.
kalo hapus2 DB saya selalu minta di temani temen terutama senior. buat double chek dan tidak salah hapus..
Ditempat saya ga ada db local, semua langsung production. testing aja pake production gegara nerusin app leluhur mana gada dokumentasi. env lokal sama dengan env production. Bahkan saya tiap mau php artisan serve aja selalu ngeri selalu teliti takut takut malah php artisan migrate 😂
test on prod, mantul
Pak, apa memungkinkan untuk bahas materi vitess untuk scale DB?
Ngeri banget emg kalo apa2 harus dilakuin di production, kadang agak riskan juga kalo do-changes langsung di DB production, suka was-was wkwk
minta maaf dulu sebelum execute
Salah pemilihan backup timestamp itu maksudnya gimana mas?
kalau db di block akses tidak pakai from anywhere, artinya hanya bisa diakses di server apakah cukup membantu mengurangi resiko ini Pak?
Thank you mas eko untuk insightnya.
pak boleh di bikinkan tutorial sql server karena pas banget mau ganti db dari mysql ke sql server . terima kasih...
Mengheningkan cipta bagi programmer yg ga sengaja drop table / databse di production
Untung saya gak pernah mau dikasih akses ke production.
Kalaupun butuh minta datanya aja, import di local.
QA diperlukan agar bisa recreate skenario bug di production seperti input nya apa outputnya apa. karena kalo udah di production jangan diapa2in lagi dah
sering-sering bahas ginian pak seru
apakah mungkin migrate nya 'fresh' jadi semua data yang ada di drop terus dibuat lagi 😅
Lah gw baru kejadian kemaren kwkwk, tp cuma hapus data di tabel prod getdate - 1, untung ada backup jd bisa reinsert transaksi lama 😂😂😂
pernah kejadian jg pada diri sendiri.. untung bukan data transaksi. sekarang udah direstrict aksesnya hanya bisa melalui jump host. btw untuk log ini standartnya ada ngga ya? isinya apa aja? atau beda company beda jg standartnya? satu lagi, berarti harusnya semakin banyak data yang ditulis ke log semakin besar jg ya impactnya ke performance?
log nya custom bikin sendiri, sesuai kebutuhan transaksi terpenting yg di log sebagai mirror backup
emang paling bener itu env prod dikasih buat read-only aja
Berhati-hatilah kalian yang sedang belajar. Karna gw sendiri pernah ngalamin ke update tanpa filter. Dan rasa nya pengen resign :(
Sampe saat ini ga berani migrate di production
artisan migrate:fresh, langsung jd pesulap jir 🗿
Jadi bahan pembelajaran
BUATIN TUTORIAL DJANGO PAK🙏
makan tak kenyang tidur tak sleeping pasti,
Aduh, mana saya sekarang punya akses db prod lagi pak 😅
minta maaf dulu sebelum kejadian
wkwkwkwk di kantor gw juga pernah kejadian malah lebih parah, udah lupa backup, server production dijalanin command rm -rf di direktori root, otomatis satu server langsung kosong
kalo disini udah di G*blok2in tuh yg kek gini... t*lol'nya keterlaluan
Itu merindingnya mungkin spt nyawa ada di atas pala, semua terasa melayang dan spt mimpi 😂
pak, apa memungkinkan bahas materi vitess untuk scale DB?
noted
kejadian waktu pake sequelize yang mestinya sync false ini true 😂
Kalau saya pernah Release production App ke playstore, tapi databasenya point ke staging 😭
Saya pernah begini wkwk. Untungnya react native ada fitur code push 😂
itu kena sp berapa ya kira2
kalo engineer nya gua yg baru fullstack crud dikit2 nestnextjs pasti gabakal bisa di restore selamanya kaga ngarti sama sekali gitu2an 😂 kalo ada salah mirgate auto migrate reset ajalah 😅
SI programmer: dah lah...
Bang pelajari cybersecurity juga dong
Bisa gk Pak Eko, meskipun dapet akses ke database production tapi hak aksesnya di batesin, kayak file sharing gitu ada yg bisa edit, ada yg cuma bisa read aja,
meding ngga usah sekalian ... kan susah juga ngatur grant akses nya supaya cuma boleh akses object tertentu saja
dulu gw minta user db tapi yang read only hehe aman kayaknya gitu ajah
Lama juga tuh panas dingin 12 jam lebih 😅
Case di video pake db apa ya ?
biasanya kesalahan saat unit test, isi database hilang 😂
"5000 rows affected" berasa simulasi kiamat kubro wkwk
tim devop panas-dingin 😂
sync: true nya lupa dimatiin XD
Ini DB nya pake apa?
Jauhkan hamba dari hal ini yaa allah
kalo production dan production.local itu mirip gk bang?
production local itu apa?
gimana ya nasib bro yg ngelakuin kesalahan ini sekarang? turut prihatin gw… 😅
Hadir
ingatlah fitur transaction anak muda biar bisa rollback awkaowokw
drop table gak bisa pake transaction kakak
Duarrr
kebayang itu panik nya wkwk
programmer baru jangan mau deh dikasih akses ke db production apapun alasannya. Dulu gw suka dikasih padahal diluar role gw dan sekarang gw kapok. Bebannya berat cuy. Dan kalau ada anomali pasti kita dikambing hitamkan. Jadi, walau statusnya orang baru atau junior, jangan pernah mau dikasih akses db prod, titik.
kan emang sengaja, lagi nyari kambing hitam #eh
@ProgrammerZamanNow lebih tepatnya ditumbalin kali ya wkwk. Baru nyadar pas udah kesini sini. Untung gw udh cabut duluan sblm makin aneh.
ADALAH SAYA
UPDATE table_a set kolom_a = 123; where xyz;
rows affected, jutaan => dead
@@ptf42069 sql sederhana sih .... tetapi mematikan database raksasa