PolarDB：Aktifkan penulisan binlog yang dioptimalkan untuk transaksi besar

Latar Belakang

Setelah binary logging diaktifkan, data binlog dari sebuah transaksi ditulis ke dalam file binlog saat transaksi tersebut dikomit. Gambar berikut menunjukkan prosesnya. Saat sebuah transaksi dijalankan, binlog yang dihasilkan disimpan sementara di dalam cache binlog transaksi tersebut. Jika beberapa transaksi dikomit pada saat yang sama, transaksi-transaksi tersebut antre untuk menulis data binlog mereka dari cache binlog ke file binlog. Jika salah satu transaksi, seperti Trx2, memiliki ukuran binlog yang besar, misalnya 1 GB, transaksi tersebut membutuhkan waktu lebih lama untuk menulis data binlog ke file binlog. Akibatnya, transaksi lain dalam antrean dipaksa menunggu, menyebabkan penundaan dalam penulisan binlog dan komit transaksi mereka. Latensi ini dapat membuat sistem sementara tidak dapat ditulis dan menyebabkan masalah seperti lonjakan kueri SQL lambat. Akibatnya, aplikasi mungkin berulang kali mencoba operasi yang gagal, yang menyebabkan lonjakan koneksi baru dan semakin meningkatkan beban sistem.

Untuk mengatasi masalah ini, PolarDB for MySQL menyediakan fitur penulisan binlog yang dioptimalkan untuk transaksi besar. Setelah Anda mengaktifkan fitur ini, proses penulisan binlog dari transaksi besar tidak lagi menghambat proses komit transaksi lain. Optimasi ini mencegah ketidaktersediaan penulisan sementara di sistem, yang jika tidak dicegah dapat menyebabkan masalah seperti lonjakan permintaan penulisan SQL lambat atau peningkatan cepat jumlah koneksi.

Versi yang Didukung

Kluster PolarDB for MySQL Anda harus merupakan Edisi Enterprise atau Edisi Standar dan menjalankan versi mesin database berikut:

• PolarDB for MySQL 8.0.1 dengan versi revisi 8.0.1.1.42 atau yang lebih baru.

• PolarDB for MySQL 8.0.2 dengan versi revisi 8.0.2.2.25 atau yang lebih baru.

Batasan

Setelah Anda mengaktifkan penulisan binlog yang dioptimalkan untuk transaksi besar, binlog yang dihasilkan oleh transaksi besar ditulis ke dalam file binlog khusus. Gambar berikut menunjukkan bahwa header dari file binlog khusus tersebut berisi event seperti FORMAT DESCRIPTION EVENT dan PREVIOUS GTIDS LOG EVENT. Sebuah event placeholder khusus bernama IGNORABLE LOG EVENT juga termasuk dalam header. Sistem downstream secara otomatis mengabaikan IGNORABLE LOG EVENT.

Berikut adalah batasan yang berlaku karena struktur khusus file binlog:

• Node replikasi downstream tidak dapat menggunakan replikasi multi-threaded berbasis konkurensi database tetapi dapat menggunakan replikasi multi-threaded berbasis konkurensi jam logis. Anda tidak boleh menentukan slave_parallel_workers>0 dan slave_parallel_type='DATABASE' secara bersamaan. Namun, Anda dapat menentukan slave_parallel_workers> 0 dan slave_parallel_type= 'logical_clock' secara bersamaan.

• Anda tidak dapat menggunakan checksum untuk file binlog transaksi besar.

Penggunaan

Atur parameter loose_enable_large_trx_optimization ke ON untuk mengaktifkan penulisan binlog yang dioptimalkan untuk transaksi besar. Gunakan parameter loose_binlog_large_trx_threshold_up untuk menentukan ambang ukuran binlog yang memicu penulisan binlog yang dioptimalkan untuk transaksi besar.

Tabel berikut menjelaskan parameter-parameter tersebut.

Perbandingan Kinerja

Gambar berikut menunjukkan perbedaan antara waktu yang diperlukan untuk kluster yang menggunakan tipe penyimpanan PSL5 untuk mengcommit transaksi besar sebelum dan sesudah penulisan binlog yang dioptimalkan untuk transaksi besar diaktifkan.

Gambar tersebut menunjukkan pengurangan signifikan dalam waktu yang diperlukan untuk mengcommit transaksi besar setelah penulisan binlog yang dioptimalkan untuk transaksi besar diaktifkan. Akibatnya, masalah seperti beban I/O berat dan kunci tulis yang berkepanjangan yang disebabkan oleh commit transaksi besar dihilangkan.