Dalam lingkungan replikasi semi-sinkron MySQL, commit transaksi besar sering memicu timeout semi-sinkron karena transmisi Binlog yang berlangsung lama. Hal ini menyebabkan replikasi semi-sinkron beralih ke replikasi asinkron, sehingga mengurangi keandalan data. Selain itu, hal ini juga memblokir transaksi berikutnya dan menyebabkan fluktuasi kinerja. Untuk mengatasi masalah tersebut, RDS for MySQL memperkenalkan fitur real-time binlog transmission. Fitur ini mengalirkan Binlog dari transaksi besar ke instans replika selama transaksi masih berjalan. Pendekatan ini memangkas waktu sinkronisasi saat commit menjadi milidetik, sehingga menjamin keandalan data yang tinggi dan kinerja layanan yang stabil.
Ikhtisar fitur
Latar belakang
MySQL native menggunakan satu channel untuk mentransmisikan Binlog antara instans primary dan replika. Ketika Binlog dari transaksi besar menduduki channel ini, transmisi Binlog untuk semua transaksi berikutnya akan terblokir. Hal ini menyebabkan penumpukan transaksi yang menunggu untuk di-commit pada instans primary, sehingga instans tersebut sementara tidak dapat menerima tulisan (unwritable). Untuk mencegah waktu henti layanan yang berkepanjangan, MySQL menyediakan parameter rpl_semi_sync_master_timeout. Jika instans replika gagal mengirim acknowledgment atas Binlog dalam waktu yang ditentukan, replikasi semi-sinkron akan beralih ke replikasi asinkron. Oleh karena itu, transaksi besar dapat menyebabkan dua masalah utama:
Fluktuasi kinerja: Instans menjadi tidak dapat menerima tulisan selama beberapa detik, dan banyak permintaan commit dicatat sebagai query SQL lambat.
Berkurangnya keandalan: Mode replikasi mengalami degradasi, yang berpotensi menyebabkan kehilangan data dalam kasus ekstrem.
Real-time binlog transmission
Pada model tradisional, Binlog suatu transaksi disimpan sementara di Binlog Cache pada instans primary selama eksekusi. Binlog tersebut baru ditulis ke file Binlog dan dikirim ke instans replika setelah transaksi di-commit. Fitur real-time binlog transmission pada RDS for MySQL mengoptimalkan proses ini. Untuk setiap transaksi besar yang melebihi ambang batas tertentu, fitur ini secara kontinu mengalirkan event Binlog yang dihasilkan dari Binlog Cache ke instans replika. Event-event tersebut disimpan sementara di Relay Log Cache khusus. Saat transaksi di-commit pada instans primary, hanya perintah commit akhir yang dikirim. Instans replika kemudian dapat segera menuliskan data yang telah di-cache ke file Relay Log-nya dan mengembalikan acknowledgment. Desain pengaliran ini memangkas waktu transmisi Binlog saat commit dari hitungan detik menjadi milidetik, sehingga secara efektif menghilangkan bottleneck transmisi.
Prinsip teknis: Desain Relay Log Cache
Untuk menyimpan sementara event Binlog yang dialirkan pada instans replika, RDS for MySQL membuat Relay Log Cache khusus untuk setiap transaksi besar. Sebelum menulis data, sistem menyisakan ruang di awal cache untuk kemudian diisi dengan header Relay Log Event. Hal ini memungkinkan konversi cepat dari cache ke file Relay Log. Sistem secara cerdas menangani kasus-kasus di mana ruang yang disediakan tidak mencukupi atau berlebihan dengan cara kembali ke logika asli atau menambahkan Empty Event, sehingga mekanisme tetap andal.
Cakupan penerapan
Fitur ini memerlukan salah satu versi database berikut:
MySQL 8.4
MySQL 8.0 dengan versi mesin minor 20250531 atau lebih baru
Petunjuk
Aktifkan fitur ini dengan mengatur parameter global berikut pada instans primary maupun replika. Perubahan parameter berlaku langsung tanpa perlu restart instans.
Untuk mengaktifkan fitur:
Pada instans primary:
loose_binlog_realtime_transmit_source_enabled=ONPada instans replika:
loose_binlog_realtime_transmit_replica_enabled=ON
Parameter inti:
loose_binlog_realtime_transmit_long_transaction_limit_sizeTujuan: Menentukan ambang batas ukuran transaksi yang memicu transmisi real-time. Saat ukuran Binlog yang dihasilkan oleh suatu transaksi melebihi nilai ini, fitur akan aktif secara otomatis.
Nilai default: 128 MB.
Manfaat
Kami mensimulasikan skenario beban tinggi dengan menjalankan transaksi besar berukuran 2 GB pada instans yang menggunakan replikasi semi-sinkron. Hasil pengujian ditunjukkan pada gambar berikut:
Sebelum optimasi (MySQL native): Setelah commit transaksi besar, Queries Per Second (QPS) instans turun ke nol, menunjukkan fluktuasi kinerja yang parah. Selanjutnya, sistem beralih ke mode asinkron akibat timeout semi-sinkron. Meskipun kinerja pulih kembali, keandalan data menjadi terganggu.
Setelah optimasi (RDS for MySQL): Dengan real-time binlog transmission diaktifkan, QPS instans tetap stabil bahkan saat melakukan commit transaksi besar. Hal ini secara efektif mencegah fluktuasi kinerja dan degradasi mode replikasi.
