Mengoptimalkan replikasi log biner untuk Aurora MySQL

Dari informasi berikut, Anda dapat mempelajari cara mengoptimalkan performa replikasi log biner dan memecahkan masalah terkait di Aurora MySQL.

Tip

Diskusi ini mengasumsikan bahwa Anda sudah mengenal mekanisme replikasi log biner MySQL dan cara kerjanya. Untuk informasi latar belakang, lihat Replication Implementation dalam dokumentasi MySQL.

Replikasi log biner multithreaded

Dengan replikasi log biner multi-thread, thread SQL membaca peristiwa dari log relai dan mengantrekannya agar thread pekerja SQL dapat diterapkan. Thread pekerja SQL dikelola oleh thread koordinator. Peristiwa log biner diterapkan secara paralel jika memungkinkan. Tingkat paralelisme tergantung pada faktor-faktor termasuk versi, parameter, desain skema, dan karakteristik beban kerja.

Replikasi log biner multithreaded didukung di Aurora MySQL versi 3, dan di Aurora MySQL versi 2.12.1 dan lebih tinggi. Agar replika multithreaded dapat memproses peristiwa binlog secara paralel secara efisien, Anda harus mengonfigurasi sumber untuk replikasi log biner multithreaded, dan sumber harus menggunakan versi yang menyertakan informasi paralelisme pada file log binernya.

Ketika instance Aurora MySQL DB dikonfigurasi untuk menggunakan replikasi log biner, secara default instance replika menggunakan replikasi single-threaded untuk versi Aurora MySQL yang lebih rendah dari 3,04. Untuk mengaktifkan replikasi multithreaded, Anda memperbarui replica_parallel_workers parameter ke nilai yang lebih besar daripada 1 di grup parameter kustom Anda.

Untuk Aurora MySQL versi 3.04 dan lebih tinggi, replikasi multithreaded secara default, dengan disetel ke. replica_parallel_workers 4 Anda dapat memodifikasi parameter ini di grup parameter kustom Anda.

Untuk meningkatkan ketahanan database Anda terhadap penghentian yang tidak terduga, kami sarankan Anda mengaktifkan replikasi GTID pada sumber dan mengizinkan replika. GTIDs Untuk memungkinkan replikasi GTID, atur gtid_mode ke ON_PERMISSIVE sumber dan replika. Untuk informasi selengkapnya tentang replikasi, lihat Menggunakan replikasi GTID berbasis.

Opsi konfigurasi berikut dapat membantu Anda menyesuaikan replikasi multi-thread. Untuk informasi penggunaan, lihat Replication and Binary Logging Options and Variables dalam Panduan Referensi MySQL. Untuk informasi selengkapnya tentang replikasi multithreaded, lihat MySQL Blog Improving the Parallel Applier with WriteSet-based Dependency Tracking.

Nilai parameter optimal tergantung pada beberapa faktor. Misalnya, performa replikasi log biner dipengaruhi oleh karakteristik beban kerja basis data Anda dan kelas instans DB tempat replika berjalan. Oleh karena itu, kami menyarankan Anda menguji secara menyeluruh semua perubahan pada parameter konfigurasi ini sebelum menerapkan pengaturan parameter baru ke instance produksi:

• binlog_format recommended value— diatur ke ROW

• binlog_group_commit_sync_delay

• binlog_group_commit_sync_no_delay_count

• binlog_transaction_dependency_history_size

• binlog_transaction_dependency_trackingNilai yang direkomendasikan adalah WRITESET

• replica_preserve_commit_order

• replica_parallel_typeNilai yang direkomendasikan adalah LOGICAL_CLOCK

• replica_parallel_workers

• replica_pending_jobs_size_max

• transaction_write_set_extractionNilai yang direkomendasikan adalah XXHASH64

Karakteristik skema dan beban kerja Anda adalah faktor yang memengaruhi replikasi secara paralel. Faktor yang paling umum adalah sebagai berikut.

• Tidak adanya kunci utama - RDS tidak dapat menetapkan ketergantungan writeset untuk tabel tanpa kunci primer. Dengan ROW format, pernyataan multi-baris tunggal dapat dicapai dengan pemindaian tabel penuh tunggal pada sumbernya, tetapi menghasilkan satu pemindaian tabel penuh per baris yang dimodifikasi pada replika. Tidak adanya kunci primer secara signifikan mengurangi throughput replikasi.

• Kehadiran kunci asing - Jika kunci asing ada, Amazon RDS tidak dapat menggunakan dependensi writeset untuk paralelisme tabel dengan hubungan FK.

• Ukuran transaksi — Jika satu transaksi mencakup puluhan atau ratusan megabyte atau gigabyte, thread koordinator dan salah satu thread pekerja mungkin menghabiskan waktu lama hanya memproses transaksi itu. Selama waktu itu, semua thread pekerja lainnya mungkin tetap menganggur setelah mereka selesai memproses transaksi mereka sebelumnya.

Di Aurora MySQL versi 3.06 dan lebih tinggi, Anda dapat meningkatkan kinerja replika log biner saat mereplikasi transaksi untuk tabel besar dengan lebih dari satu indeks sekunder. Fitur ini memperkenalkan kumpulan utas untuk menerapkan perubahan indeks sekunder secara paralel pada replika binlog. Fitur ini dikendalikan oleh parameter cluster aurora_binlog_replication_sec_index_parallel_workers DB, yang mengontrol jumlah total thread paralel yang tersedia untuk menerapkan perubahan indeks sekunder. Parameter diatur ke 0 (dinonaktifkan) secara default. Mengaktifkan fitur ini tidak memerlukan instance restart. Untuk mengaktifkan fitur ini, hentikan replikasi yang sedang berlangsung, atur jumlah thread parallel worker yang diinginkan, lalu mulai replikasi lagi.

Mengoptimalkan replikasi binlog

Di Aurora MySQL 2.10 dan yang lebih tinggi, Aurora secara otomatis menerapkan optimasi yang dikenal sebagai cache binlog untuk replikasi log biner. I/O Dengan membuat cache peristiwa binlog yang paling baru di-commit, optimisasi ini dirancang untuk meningkatkan performa thread dump binlog sambil membatasi dampak pada transaksi latar depan di instans sumber binlog.

catatan

Memori yang digunakan untuk fitur ini tidak bergantung pada pengaturan binlog_cache MySQL.

Fitur ini tidak berlaku untuk instans Aurora DB yang menggunakan kelas instans db.t2 dan db.t3.

Anda tidak perlu menyesuaikan parameter konfigurasi apa pun untuk mengaktifkan optimisasi ini. Secara khusus, jika Anda telah menyesuaikan parameter konfigurasi aurora_binlog_replication_max_yield_seconds ke nilai bukan nol di versi MySQL Aurora sebelumnya, atur kembali ke nol untuk versi yang tersedia saat ini.

Variabel status aurora_binlog_io_cache_reads dan aurora_binlog_io_cache_read_requests membantu Anda memantau seberapa sering data dibaca dari I/O cache binlog.

• aurora_binlog_io_cache_read_requestsmenunjukkan jumlah permintaan I/O baca binlog dari cache.

• aurora_binlog_io_cache_readsmenunjukkan jumlah I/O pembacaan binlog yang mengambil informasi dari cache.

Kueri SQL berikut menghitung persentase permintaan baca binlog yang memanfaatkan informasi cache. Dalam hal ini, makin dekat rasionya ke 100, makin baik.

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

Fitur I/O cache binlog juga menyertakan metrik baru yang terkait dengan utas dump binlog. Thread dump adalah thread yang dibuat saat replika binlog baru terhubung ke instans sumber binlog.

Metrik thread dump dicetak ke log basis data setiap 60 detik dengan awalan [Dump thread metrics]. Metrik ini mencakup informasi untuk setiap replika binlog seperti Secondary_id, Secondary_uuid, nama file binlog, dan posisi yang dibaca setiap replika. Metrik ini juga mencakup Bytes_behind_primary yang merepresentasikan jarak dalam byte antara sumber replikasi dan replika. Metrik ini mengukur lag I/O utas replika. Angka tersebut berbeda dengan lag thread pengaplikasi SQL replika, yang direpresentasikan oleh metrik seconds_behind_master pada replika binlog. Anda dapat menentukan apakah replika binlog mengimbangi atau tertinggal di belakang sumber dengan memeriksa apakah jaraknya berkurang atau bertambah.

Log relai dalam memori

Di Aurora MySQL versi 3.10 dan lebih tinggi, Aurora memperkenalkan pengoptimalan yang dikenal sebagai log relai dalam memori untuk meningkatkan throughput replikasi. Optimalisasi ini meningkatkan I/O kinerja log relai dengan menyimpan semua konten log relai perantara di memori. Akibatnya, ini mengurangi latensi komit dengan meminimalkan I/O operasi penyimpanan karena konten log relai tetap mudah diakses di memori.

Secara default, fitur log relai dalam memori diaktifkan secara otomatis untuk skenario replikasi yang dikelola Aurora (termasuk penerapan biru-hijau, replikasi Aurora-Aurora, dan replika lintas wilayah) ketika replika memenuhi salah satu konfigurasi ini:

• Mode replikasi ulir tunggal (replica_parallel_workers = 0)

• Replikasi multi-utas dengan mode GTID diaktifkan:

  • Posisi otomatis diaktifkan

  • Mode GTID diatur ke ON pada replika

• Replikasi berbasis file dengan replica_preserve_commit_order = ON

Fitur log relai dalam memori didukung pada kelas instance yang lebih besar dari t3.large, tetapi tidak tersedia pada instance. Aurora Serverless Buffer melingkar log relay memiliki ukuran tetap 128 MB. Untuk memantau konsumsi memori fitur ini, Anda dapat menjalankan kueri berikut:

SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';

Fitur log relai dalam memori dikendalikan oleh parameter aurora_in_memory_relaylog, yang dapat diatur pada cluster DB atau tingkat instans. Anda dapat mengaktifkan atau menonaktifkan fitur ini secara dinamis tanpa memulai ulang instance Anda:

1. Hentikan replikasi yang sedang berlangsung

2. Setel aurora_in_memory_relaylog ke ON (untuk mengaktifkan) atau OFF (untuk menonaktifkan) di grup parameter

3. Mulai ulang replikasi

Contoh:

CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;

Bahkan ketika aurora_in_memory_relaylog disetel ke ON, fitur log relai dalam memori mungkin masih dinonaktifkan dalam kondisi tertentu. Untuk memverifikasi status fitur saat ini, Anda dapat menggunakan perintah berikut:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';

Jika fitur ini tiba-tiba dinonaktifkan, Anda dapat mengidentifikasi alasannya dengan menjalankan:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';

Perintah ini mengembalikan pesan yang menjelaskan mengapa fitur saat ini dinonaktifkan.