RDS for MySQL mengoptimalkan logika tunggu untuk replikasi paralel guna menghilangkan replikasi lag yang disebabkan oleh pemrosesan data batch. Fitur ini sangat berguna untuk operasi batch seperti penghapusan data, organisasi, dan impor selama jam sepi.
Applicability
Instans database Anda harus memenuhi salah satu persyaratan versi berikut:
RDS for MySQL 8.4
RDS for MySQL 8.0 dengan versi mesin minor 20251130 atau lebih baru
Enablement
Anda dapat mengatur parameter global berikut pada instans primary atau instans hanya baca, yaitu mengatur loose_optimize_replica_parallelism menjadi ON.
Parameter name:
loose_optimize_replica_parallelismValue:
ONEffective: Pengaturan langsung berlaku. Tidak diperlukan restart instans.
Background
Banyak aplikasi melakukan operasi data seperti penghapusan, organisasi, dan impor selama jam sepi dengan menggunakan batch kecil dan konkurensi tinggi. Pendekatan ini cepat serta memungkinkan penyesuaian fleksibel terhadap ukuran batch dan tingkat konkurensi untuk mengontrol dampaknya terhadap database.
Selama pemrosesan data batch, dua jenis transaksi utama berjalan bersamaan pada instans: transaksi berukuran menengah dari pekerjaan batch—yang biasanya memproses ribuan baris per transaksi—dan transaksi kecil dari operasi bisnis reguler. Bahkan selama jam sepi, beberapa lalu lintas bisnis reguler tetap ada. Kedua jenis transaksi ini saling berselang-seling dalam file binlog. Jika beberapa transaksi kecil yang memodifikasi baris yang sama berada di antara dua transaksi berukuran menengah, maka kedua transaksi berukuran menengah tersebut tidak dapat dieksekusi secara konkuren.
Seperti yang ditunjukkan pada gambar di atas, Trx2 dan Trx5 adalah transaksi berukuran menengah dari proses batch. Trx3 dan Trx4 adalah transaksi kecil dari operasi bisnis reguler yang memodifikasi baris yang sama. Saat thread SQL mendispatch transaksi-transaksi ini, Trx2 dan Trx3 didispatch secara normal. Namun, Trx4 harus menunggu Trx3 dan semua transaksi sebelumnya melakukan commit sebelum thread SQL dapat mendispatch-nya. Hal ini menunda dispatch Trx5 hingga Trx2 melakukan commit, sehingga mencegah Trx2 dan Trx5 diterapkan secara paralel.
Akibatnya, tingkat konkurensi pada replica sangat rendah selama pemrosesan data batch. Terkadang, hanya satu thread pekerja yang aktif, sehingga kinerja efektif turun ke level single-threaded. Hal ini menyebabkan replikasi lag yang signifikan.
Results
Pengujian menggunakan penghapusan data batch menggambarkan hasilnya. Skrip write-only sysbench single-threaded mensimulasikan transaksi latar belakang kecil, sementara delapan thread konkuren menghapus data dalam batch berukuran 5.000 baris. Gambar di atas menunjukkan replikasi lag pada instans hanya baca. Sebelum fitur diaktifkan, throughput replica rendah dan replikasi lag meningkat. Setelah fitur diaktifkan, throughput meningkat secara signifikan dan replikasi lag berkurang hingga replica berhasil mengejar ketinggalan.
How it works
Ketika transaksi kecil yang saling bertabrakan tersebar di antara transaksi berukuran menengah, kini mereka menunggu di thread pekerja masing-masing hingga dependensinya melakukan commit. Hal ini menghindari penantian di thread SQL, yang jika terjadi akan menghambat dispatch transaksi lain. Akibatnya, transaksi berukuran menengah yang tidak saling bertabrakan dapat dieksekusi secara paralel.