ApsaraDB RDS:Optimalkan commit transaksi besar

Fitur

Karena penulisan binlog bersifat serial, transaksi besar memerlukan waktu lama untuk menulis event binlog-nya dan juga memblokir transaksi lain dari melakukan commit. Fitur ini mengoptimalkan mekanisme penulisan binlog untuk commit transaksi besar sehingga kecepatan commit tidak lagi bergantung pada jumlah event binlog. Fitur ini mengatasi masalah umum berikut:

• Transaksi yang sangat besar memblokir instans, sehingga transaksi lain tidak dapat melakukan commit.

• Transaksi besar menyebabkan konsumsi I/O tinggi, yang dapat menghabiskan sumber daya I/O dan memperlambat operasi lain, seperti kueri.

• Transaksi besar memperlambat eksekusi transaksi kecil, menyebabkan lonjakan koneksi aktif dan fluktuasi performa. Dalam kasus parah, hal ini dapat memicu kegagalan berantai dan membuat instans tidak tersedia.

• Eksekusi transaksi besar yang sering menyebabkan ketidakstabilan performa berkelanjutan pada beban kerja Anda.

Prasyarat

Instans harus memenuhi salah satu persyaratan versi berikut:

• MySQL 8.4

• MySQL 8.0 dengan versi mesin minor 20240731 atau lebih baru.

• MySQL 5.7 dengan versi mesin minor 20240731 atau lebih baru.

  Catatan

  Pada halaman Basic Information, periksa bagian Configuration Information untuk tombol Upgrade minor engine version. Jika tombol tersebut tersedia, Anda dapat melakukan upgrade instans Anda. Jika tombol tersebut tidak tersedia, instans Anda sudah menggunakan versi mesin minor terbaru. Untuk informasi lebih lanjut, lihat Upgrade minor engine version.

Penggunaan

• Instans baru: Fitur binlog cache free flush diaktifkan secara default.

• Instans yang sudah ada: Anda dapat mengaktifkan fitur ini dengan mengatur variabel sistem global loose_binlog_cache_free_flush. Perubahan berlaku segera tanpa memerlukan restart instans.

• Parameter terkait:

  loose_binlog_cache_free_flush_limit_size: Setelah Anda mengaktifkan fitur binlog cache free flush, jika binlog yang dihasilkan oleh suatu transaksi melebihi nilai parameter ini, file temporary binlog cache akan dipromosikan menjadi file binlog saat commit. Nilai default: 256 MB. Rentang nilai: 20971520 hingga 18446744073709551615 (satuan: byte).

Analisis masalah

Saat sebuah instans MySQL menjalankan transaksi besar, log kueri lambat (slow query log) dapat mencatat penundaan tidak biasa untuk statement yang seharusnya selesai dengan cepat, seperti COMMIT.

Masalah ini disebabkan oleh konflik sumber daya dalam mekanisme penulisan binlog yang bersifat serial. Transaksi besar dalam satu thread memerlukan waktu lama untuk menulis binlog-nya, sehingga memblokir transaksi lain dari proses commit dan menyebabkan penundaan global yang terserialisasi.

Selama pengujian sysbench oltp_write_only, setelah menjalankan operasi UPDATE besar yang menghasilkan binlog sebesar 512 MB setiap 5 detik, kami mengamati efek berikut:

• Setiap kali operasi UPDATE besar tersebut melakukan commit, Transactions Per Second (TPS) turun tajam.

• Dampak performa sebanding dengan ukuran binlog: semakin besar binlog yang dihasilkan oleh transaksi, semakin signifikan dampak latensi terhadap beban kerja lain.

Gambar berikut mengilustrasikan dampak transaksi besar terhadap beban kerja yang sedang berjalan.

Operasi terkait UPDATE:

CREATE TABLE t_large (a INT, b LONGTEXT) ENGINE = InnoDB;

# Masukkan satu baris dengan teks sebesar 256 MB. Operasi UPDATE berikutnya akan menghasilkan 512 MB event binlog.
INSERT INTO t_large VALUES (1, repeat('a', 256000000)); 

UPDATE t_large SET a = a + 1;

Efek optimasi

• Stabilitas TPS yang jauh lebih baik

  • Sebelum optimasi: Operasi UPDATE besar yang dijalankan setiap 5 detik menyebabkan fluktuasi TPS yang parah.

  • Setelah optimasi (garis oranye): Dampak operasi UPDATE besar terhadap TPS hampir sepenuhnya dihilangkan.

  

• Tidak ada fluktuasi latensi yang signifikan

  • Seperti yang ditunjukkan oleh garis oranye (setelah optimasi), dampak operasi UPDATE dengan berbagai ukuran terhadap latensi tidak lagi signifikan.

  • Bahkan ketika ukuran binlog melebihi 512 MB, latensi commit transaksi lain tidak terpengaruh secara signifikan.

  

Cara kerja