MySQL menggunakan replikasi logis untuk memastikan konsistensi data antara instans primary dan instans standby. Setelah sebuah transaksi dikomit pada instans primary, event Binlog-nya dikirim ke instans standby untuk diterapkan. Dalam arsitektur ini, pernyataan Data Definition Language (DDL) yang berjalan lama dapat menyebabkan latensi replikasi signifikan pada instans standby. Untuk mengatasi masalah tersebut, RDS MySQL memperkenalkan fitur real-time DDL application yang memberi tahu instans standby untuk mulai mengeksekusi pernyataan DDL secara konkuren dengan instans primary. Eksekusi paralel ini hampir menghilangkan latensi replikasi terkait DDL dan memastikan ketersediaan tinggi untuk instans Anda.
Ikhtisar fitur
Latar belakang
Latensi dalam replikasi logis terdiri dari dua bagian utama: waktu transmisi event Binlog dan waktu replay transaksi pada instans standby. Untuk operasi DDL, yang hanya menghasilkan satu Gtid_log_event dan satu Query_log_event, jumlah data yang ditransmisikan sangat kecil sehingga waktu transmisi event Binlog dapat diabaikan. Penyebab utama latensi replikasi DDL adalah waktu eksekusi yang lama dari pernyataan DDL tersebut.
Real-time DDL application di RDS MySQL
Akar penyebab latensi replikasi terkait DDL adalah arsitektur MySQL yang mengharuskan pernyataan DDL dikomit terlebih dahulu pada instans primary sebelum instans standby dapat menerapkannya. Solusi paling langsung adalah memungkinkan instans standby mengeksekusi pernyataan DDL secara paralel dengan instans primary, alih-alih menunggu.
Inilah prinsip inti dari fitur real-time DDL application. Saat pernyataan DDL mulai dieksekusi pada instans primary, instans tersebut segera memberi tahu instans standby untuk memulai operasi yang sama. Instans standby mengeksekusi sebagian besar operasi DDL tersebut, lalu menunggu hasil akhir dari instans primary. Jika operasi berhasil pada instans primary, instans tersebut memberi sinyal kepada standby untuk melakukan commit; jika gagal, diberikan sinyal rollback. Akibatnya, latensi replikasi yang disebabkan oleh DDL berkurang menjadi waktu yang dibutuhkan untuk satu transmisi jaringan ditambah waktu commit DDL. Kedua langkah ini sangat cepat, biasanya memakan waktu paling lama puluhan milidetik.
Fitur ini disebut Binlog Realtime Replication (BRR).
Cara kerja
Instans primary membuat jenis event baru yang disebut Brr binlog event dan mengirimkannya ke instans standby dengan menggunakan fitur real-time transport. Event ini memberi tahu instans standby untuk mengeksekusi DDL, sehingga mencapai eksekusi konkuren pada kedua instans. Brr binlog event tidak direkam dalam Binlog atau Relay Log, sehingga tidak memengaruhi sistem downstream yang mengonsumsi binlog.
Instans standby membuat sejumlah thread pekerja Brr tertentu untuk menerapkan pernyataan DDL secara real time. Thread pekerja Brr ini beroperasi secara independen dari thread pekerja asli MySQL.
Versi yang didukung
Untuk menggunakan fitur ini, instans Anda harus memenuhi persyaratan versi berikut. Jika instans Anda tidak memenuhi persyaratan, Anda dapat meningkatkan versi mesin minor atau meningkatkan versi utama database.
MySQL 8.4
MySQL 8.0: versi mesin minor ≥ 20250731.
Batasan
Fitur real-time transport harus diaktifkan.
Jenis pernyataan DDL yang didukung bergantung pada versi mesin minor:
Versi mesin minor ≥ 20250731: mendukung Alter Table.
Versi mesin minor ≥ 20251031: mendukung Alter Table dan Optimize Table.
Prosedur
Untuk mengaktifkan fitur ini, konfigurasikan parameter instans pada instans primary maupun standby. Perubahan parameter berlaku serta-merta tanpa memerlukan restart instans.
Parameter instans primary:
loose_binlog_realtime_apply_ddl_source_enabled = ONloose_binlog_realtime_ddl_time_limit = N(di manaNadalah bilangan bulat yang lebih besar atau sama dengan 0. Fitur BRR dipicu untuk pernyataan DDL dengan waktu eksekusi lebih lama dari nilai ini. Parameter ini diukur dalam milidetik, dan nilai default-nya adalah 1000.)
Parameter instans standby:
loose_binlog_realtime_apply_workers = N(di manaNadalah bilangan bulat yang lebih besar atau sama dengan 1. Parameter ini menentukan jumlah thread pekerja Brr.)
Hasil optimisasi
Pengujian ini menggunakan tabel berukuran 23 GB dengan 80.000.000 baris. Operasi rebuild tabel (alter table sbtest1 engine=innodb) kemudian dilakukan pada tabel tersebut.
Hasil optimisasi ditunjukkan pada gambar di bawah. Instans primary mengeksekusi pernyataan DDL pada pukul 16:21:35 dan 16:32:50. Tanpa BRR diaktifkan, instans standby mengalami latensi replikasi berkelanjutan selama 277 detik. Dengan BRR diaktifkan, latensi replikasi hampir sepenuhnya dihilangkan.
Versi mesin minor instans pengujian adalah 20251031.
