Saat jam sibuk, banyak beban kerja memperbarui database dengan konkurensi tinggi. Jika throughput transaksi (TPS) pada instans primary melebihi throughput Thread I/O dan SQL pada instans replika, maka dapat terjadi latensi replikasi. Untuk mengatasi masalah ini, ApsaraDB RDS for MySQL mengoptimalkan logika lock-wait antara Thread I/O, SQL, dan worker threads serta mengurangi jumlah lock wait. Optimasi ini menghilangkan latensi replikasi untuk beban kerja yang memiliki transaksi kecil berkonkurensi tinggi.
Ikhtisar
Latensi replikasi
Latensi replikasi: Saat jam sibuk, banyak beban kerja memperbarui database dengan konkurensi tinggi. Jika instans primary menerapkan transaksi dengan tingkat konkurensi yang lebih tinggi daripada instans replika, throughput transaksi replika dapat tertinggal, sehingga menyebabkan latensi replikasi. Bahkan ketika Anda menambah jumlah worker threads atau mengaktifkan fitur Writeset, konkurensi apply pada replika mungkin tetap tidak mencukupi karena Thread I/O atau SQL-nya mencapai bottleneck throughput.
Bottleneck throughput Thread I/O dan SQL: Replikasi multi-threaded MySQL menggunakan tiga jenis thread: Thread I/O, thread SQL, dan beberapa worker threads. Thread I/O mengambil event binlog dari instans primary. Thread SQL mendistribusikan event binlog tersebut ke worker threads. Worker threads kemudian menerapkan transaksi secara paralel.
Koordinasi antara Thread I/O dan SQL, serta antara thread SQL dan worker threads, bergantung pada operasi wait dan notify yang dilindungi oleh lock. Setiap event binlog memerlukan satu siklus lock-and-notify semacam itu. Satu transaksi terdiri dari beberapa event binlog. Sebagai contoh, dalam skrip uji sysbench write_only yang umum digunakan, satu transaksi melibatkan pembaruan dua baris, penyisipan satu baris, dan penghapusan satu baris, yang menghasilkan 11 event binlog. Dalam kondisi konkurensi tinggi, lock-lock ini sering menjadi bottleneck performa, sehingga membatasi throughput Thread I/O dan SQL.
Ketika Thread I/O atau SQL mencapai bottleneck throughput, worker threads tidak menerima transaksi untuk diterapkan secara tepat waktu. Jika konkurensi apply worker threads pada instans replika lebih rendah daripada konkurensi beban kerja pada instans primary, maka akan terjadi latensi replikasi.
Optimasi batching transaksi kecil
Untuk mengoptimalkan latensi replikasi pada transaksi kecil berkonkurensi tinggi, AliSQL memperkenalkan optimasi batching transaksi kecil. Optimasi ini menggabungkan beberapa event binlog dari satu transaksi kecil menjadi satu siklus lock-and-notify untuk Thread I/O dan SQL. Pendekatan ini secara signifikan mengurangi jumlah operasi lock, sehingga meningkatkan throughput kedua thread tersebut.
Prasyarat
Untuk menggunakan optimasi ini, instans Anda harus memenuhi persyaratan berikut:
Versi mesin database: Instans Anda harus menjalankan ApsaraDB RDS for MySQL 8.0 dengan versi mesin minor 20260228 atau lebih baru. Jika instans Anda belum memenuhi persyaratan ini, Anda dapat Meningkatkan versi mesin minor atau Meningkatkan versi mesin database.
Prosedur
Anda dapat mengaktifkan fitur ini dengan mengonfigurasi parameter global pada instans primary atau instans hanya baca Anda:
Buka halaman Instances. Di bilah navigasi atas, pilih Wilayah tempat instans RDS berada. Lalu, temukan instans RDS tersebut dan klik ID instansnya.
Di panel navigasi kiri, klik Parameter settings.
Pada tab Modifiable parameters, cari parameter
loose_replica_package_transaction_limit_sizedan konfigurasikan nilainya.Deskripsi parameter: Nilai 0 menonaktifkan fitur ini. Ketika nilainya lebih besar dari 0, transaksi dengan ukuran binlog lebih kecil dari nilai ini memenuhi syarat untuk optimasi ini.
Nilai yang valid: 0 hingga 1 MB.
Nilai yang direkomendasikan: 1 MB.
Klik OK, lalu klik Submit parameters. Di kotak dialog, pilih Effective period. Perubahan parameter berlaku segera dan tidak memerlukan restart instans.
Hasil optimasi
Kami menjalankan skrip sysbench write_only pada instans primary dengan 128 thread konkuren (80.000 transaksi per detik atau TPS) untuk mensimulasikan beban kerja tulis puncak selama 60 detik. Pengujian menghasilkan hasil sebagai berikut:
Sebelum optimasi: Latensi replikasi pada instans replika terus meningkat, dan throughput-nya sangat rendah.
Setelah optimasi: Instans replika tidak mengalami latensi replikasi, dan throughput-nya hampir dua kali lipat.
