All Products
Search

This Product

    ApsaraDB RDS:Binlog in Redo

    Document Center

    ApsaraDB RDS:Binlog in Redo

    Last Updated:May 13, 2026

    Fitur Binlog in Redo meningkatkan kinerja database dengan menulis konten log biner ke redo log saat transaksi di-commit, sehingga mengurangi operasi I/O disk sinkron.

    Prasyarat

    Informasi latar belakang

    Pada skenario MySQL yang bersifat mission-critical, untuk memastikan keamanan data, log biner dan redo log harus secara sinkron dituliskan ke disk saat transaksi di-commit. Artinya, dua parameter berikut harus diatur ke nilai 1:

    sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;

    MySQL standar memerlukan dua operasi I/O disk sinkron untuk setiap commit transaksi: satu untuk log biner dan satu untuk redo log. Persyaratan ini mengurangi efisiensi commit, terutama pada cloud disk.

    Untuk meningkatkan efisiensi commit transaksi, AliSQL memperkenalkan fitur Binlog in Redo, yang diaktifkan dengan mengatur parameter persist_binlog_to_redo=ON dan dinonaktifkan secara default. Saat transaksi di-commit, fitur ini menggabungkan konten log biner dengan redo log dan menuliskannya secara bersamaan. Hanya diperlukan satu operasi I/O sinkron untuk menyimpan redo log, yang sekaligus juga menuliskan data log biner ke disk. Desain ini menghilangkan dua operasi I/O terpisah yang diperlukan dalam MySQL standar untuk log biner dan redo log, sehingga secara signifikan mengurangi latensi dan meningkatkan throughput.

    Selain itu, Binlog in Redo menggunakan pemrosesan batch dan mekanisme group commit untuk mengurangi kontensi lock akibat alokasi GTID dalam skenario konkurensi tinggi. Pendekatan ini mengurangi konflik lock dan memastikan kinerja tinggi.

    Sebuah thread latar belakang secara asinkron menuliskan file log biner dengan menambahkan data secara batch secara berkala. Hal ini menghindari tekanan pada sistem file yang disebabkan oleh panggilan fsync secara real-time dan meningkatkan efisiensi I/O secara keseluruhan. Bahkan jika database restart secara tidak terduga, sistem dapat secara otomatis memulihkan integritas file log biner dengan memutar ulang data log biner yang tersimpan dalam redo log, sehingga memastikan konsistensi data.

    Fitur Binlog in Redo tidak mengubah format log biner. Replikasi dan tool pihak ketiga yang berbasis log biner tidak terpengaruh.

    Catatan

    Setelah mengaktifkan fitur Binlog in Redo, untuk memulihkan instans disk lokal berkinerja tinggi ke database yang dikelola sendiri menggunakan file backup fisik, Anda harus menggunakan tool XtraBackup yang disediakan oleh RDS. Untuk menginstal tool XtraBackup, lihat Tool preparation.

    Parameter

    • persist_binlog_to_redo

      Mengaktifkan atau menonaktifkan fitur Binlog in Redo. Ini adalah variabel sistem global. Nilai yang valid: on atau off. Perubahan pada parameter ini langsung berlaku tanpa perlu me-restart instans.

      Catatan

      Untuk mengaktifkan fitur ini, selain mengatur persist_binlog_to_redo ke on, Anda juga harus mengatur binlog_order_commits ke off dan mengatur mode replikasi data instans ke replikasi asinkron.

      Jika parameter sync_binlog instans Anda tidak diatur ke 1, fitur Binlog in Redo tidak akan aktif meskipun Anda telah mengonfigurasi parameter-parameter di atas. Dalam kasus ini, kami merekomendasikan Anda menggunakan fitur Binlog Parallel Flush untuk mengoptimalkan kinerja instans Anda.

    • sync_binlog_interval

      Interval persistensi asinkron log biner. Ini adalah variabel sistem global dan hanya berlaku ketika persist_binlog_to_redo = on. Nilai default-nya adalah 50, dengan satuan milidetik (ms). Pada sebagian besar kasus, nilai default sudah cukup. Perubahan pada parameter ini langsung berlaku tanpa perlu me-restart instans.

    Benchmark kinerja

    • Lingkungan pengujian

      • Server aplikasi: Instance ECS Alibaba Cloud

      • Spesifikasi instans RDS: 32 core, memori 128 GB, cloud disk ESSD

      • Jenis instans: Edisi Ketersediaan Tinggi (mode replikasi data: replikasi asinkron)

    • Kasus uji

      Kasus uji Sysbench bawaan berikut digunakan:

      • oltp_update_non_index

      • oltp_write_only

    • Hasil pengujian

      • oltp_update_non_index

        Setelah Binlog in Redo diaktifkan, TPS meningkat secara signifikan pada skenario konkurensi rendah dan terlihat jelas pada skenario konkurensi tinggi, dengan latensi yang lebih rendah.

        oltp_update_non_index_TPSoltp_update_non_index_Latency

      • oltp_write_only

        Setelah Binlog in Redo diaktifkan, TPS meningkat secara substansial baik pada skenario konkurensi rendah maupun tinggi, dengan latensi yang lebih rendah.

        oltp_write_only_TPSoltp_write_only_Latency

    Kesimpulan

    • Kasus uji oltp_update_non_index hanya berisi transaksi satu pernyataan, sehingga lebih sering melakukan commit. Sebaliknya, oltp_write_only berisi transaksi multi-pernyataan (dua pernyataan UPDATE, satu pernyataan DELETE, dan satu pernyataan INSERT), sehingga lebih jarang melakukan commit. Akibatnya, peningkatan kinerja untuk oltp_update_non_index lebih signifikan dibandingkan oltp_write_only.

    • Pada jumlah koneksi bersamaan kurang dari 64, fitur Binlog in Redo secara signifikan meningkatkan kinerja dan mengurangi latensi. Hal ini menjadikannya efektif untuk sebagian besar beban kerja produksi.

    • Pada jumlah koneksi bersamaan lebih dari 256, fitur Binlog in Redo memberikan kinerja puncak yang lebih tinggi dan latensi yang lebih rendah, sehingga mampu menangani lonjakan traffic secara lebih baik.