Jika dua transaksi (sekumpulan operasi DB yang diproses sebagai satu kesatuan) saling menunggu baris yang dikunci pihak lain, DB membatalkan salah satunya secara paksa.
Mengapa Trade A mengunci dengan urutan item→mata uang game, trade B dengan urutan mata uang game→item → Akibatnya DB mendeteksi deadlock dan melakukan rollback pada salah satunya → Di layar Trade dan crafting sesekali gagal, item kembali seperti semula
Saat banyak pemain berkumpul, Saat melakukan aksi tertentu
Penanggung jawab
Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game
Samakan urutan penguncian, persingkat transaksi, coba ulang otomatis saat gagal.
Tugas Tim Infrastruktur
Biarkan deteksi deadlock aktif, kumpulkan catatan deadlock lalu bagikan, perpendek batas waktu tunggu lock (default 50 detik) di server MySQL yang deteksinya dimatikan.
Kisaran angka
Waktu sampai terdeteksi: MySQL (InnoDB) hampir seketika, PostgreSQL default 1 detik, SQL Server hingga sekitar 5 detik. Selama itu kedua request tertahan. Pada server MySQL yang deteksinya dimatikan karena request bersamaan sangat banyak, request menunggu sampai batas waktu tunggu lock (default 50 detik).
Di grafik
Melonjak acak sesekali · Jumlah deadlock, jumlah trade gagal
Yang diperiksa
MySQL: periksa LATEST DETECTED DEADLOCK di SHOW ENGINE INNODB STATUS (hanya 1 yang terbaru), semua deadlock yang tercatat di error log jika innodb_print_all_deadlocks diaktifkan, dan lock_deadlocks di INFORMATION_SCHEMA.INNODB_METRICS. PostgreSQL: deadlocks di pg_stat_database. SQL Server: xml_deadlock_report di sesi system_health yang aktif secara default. Kode error di sisi server game: MySQL 1213, PostgreSQL 40P01, SQL Server 1205
Cocok jika
Saat trade dan crafting gagal, jumlah deadlock naik, dan dua transaksi yang tercatat mengunci tabel yang sama dengan urutan saling berlawanan
Tidak cocok jika
Jumlah deadlock tidak berubah tetapi tetap gagal: lebih mungkin batas waktu tunggu lock terlampaui (error MySQL 1205) atau hot row (db-hot-row)
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Sumber
InnoDB Startup Options and System VariablesMySQL Jika deteksi aktif (default), InnoDB langsung mendeteksi deadlock dan melakukan rollback; innodb_lock_wait_timeout default 50 detik
Deadlock DetectionMySQL Pada konkurensi sangat tinggi, deteksi itu sendiri bisa menjadi lambat, sehingga kadang dimatikan dan diserahkan ke batas waktu tunggu lock
Deadlocks guideMicrosoft SQL Server Interval default pemeriksaan deadlock 5 detik, dipersingkat hingga 100 ms jika deadlock sering terjadi; sesi system_health yang aktif secara default mengumpulkan xml_deadlock_report; pihak yang dikorbankan menerima error 1205
How to Minimize and Handle DeadlocksMySQL Selalu ubah banyak baris dan tabel dengan urutan yang sama, coba lagi jika gagal, catat semua deadlock dengan innodb_print_all_deadlocks
InnoDB Standard Monitor and Lock Monitor OutputMySQL LATEST DETECTED DEADLOCK: dua transaksi pada deadlock terbaru, lock yang dipegang dan ditunggu, serta transaksi yang dibatalkan (rollback)