Transaksi yang terbuka lama terus memegang lock, dan DB tidak bisa membersihkan data versi lama (purge), sehingga seluruh DB makin lama makin lambat.
Mengapa Menunggu respons server lain sambil membiarkan transaksi terbuka, atau menjalankan query agregasi panjang di DB primer saat layanan berjalan → Akibatnya Lock yang dipegang tidak dilepas, dan data versi lama yang harus dibersihkan terus menumpuk → Di layar Fitur yang memakai baris itu timeout, penyimpanan dan pembacaan data melambat secara umum selama beberapa jam
Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game
Jangan menunggu pemanggilan jaringan atau input pengguna di dalam transaksi, jalankan query agregasi di replika.
Tugas Tim Infrastruktur
Pasang alert untuk transaksi yang terbuka lama dan hentikan paksa, sediakan replika khusus agregasi, pantau pertambahan undo log dan baris mati.
Di grafik
Naik perlahan · Panjang undo log (History list length), jumlah baris mati
Yang diperiksa
MySQL: cari transaksi tertua dengan trx_started di INFORMATION_SCHEMA.INNODB_TRX, lalu periksa History list length (jumlah undo log yang belum dibersihkan) di bagian TRANSACTIONS pada SHOW ENGINE INNODB STATUS. PostgreSQL: periksa xact_start dan sesi dengan state idle in transaction di pg_stat_activity, serta n_dead_tup di pg_stat_user_tables
Cocok jika
Ada transaksi yang sudah berumur beberapa menit hingga beberapa jam, dan selama itu History list length atau n_dead_tup terus naik, lalu turun setelah transaksi itu diakhiri dan pembersihan (purge, VACUUM) berjalan
Tidak cocok jika
Tidak ada transaksi lama tetapi DB lambat secara umum: lebih mungkin checkpoint (db-checkpoint) atau disk
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut
DB menyimpan versi lama data agar pihak yang membaca bisa melihat kondisi sebelum diubah (MVCC). Catatan ini baru bisa dihapus setelah transaksi tertua selesai, sehingga jika satu transaksi terbuka selama beberapa jam, undo log menumpuk di MySQL, dan di PostgreSQL menumpuk baris mati (dead tuple) yang tidak bisa dibersihkan VACUUM. Di SQL Server, log transaksi tidak bisa menyusut dan kadang sampai memenuhi disk.
Sumber
InnoDB Multi-VersioningMySQL Selama masih ada transaksi yang bisa melihat versi lama, update undo log tidak bisa dibuang sehingga rollback segment membesar; transaksi yang hanya membaca pun dianjurkan sering di-commit
Routine Vacuuming (PostgreSQL Documentation)PostgreSQL Versi baris lama tidak bisa dihapus selama transaksi lain masih bisa melihatnya; transaksi yang terbuka lama harus diakhiri atau sesinya dihentikan
Purge ConfigurationMySQL Purge membersihkan daftar undo log transaksi yang sudah di-commit (history list); jumlah yang tertunda ditampilkan sebagai History list length di bagian TRANSACTIONS pada SHOW ENGINE INNODB STATUS