Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mengoptimalkan replikasi log biner untuk Aurora My SQL
Setelah itu, Anda dapat mempelajari cara mengoptimalkan kinerja replikasi log biner dan memecahkan masalah terkait di Aurora My. SQL
Tip
Diskusi ini menganggap bahwa Anda sudah familiar dengan mekanisme replikasi log SQL biner saya dan cara kerjanya. Untuk informasi latar belakang, lihat Implementasi Replikasi
Replikasi log biner multithreaded
Dengan replikasi log biner multithreaded, sebuah SQL thread membaca peristiwa dari log relai dan mengantrekannya agar thread pekerja dapat diterapkan. SQL Thread SQL pekerja dikelola oleh utas koordinator. Peristiwa log biner diterapkan secara paralel jika memungkinkan.
Replikasi log biner multithreaded didukung di Aurora My versi SQL 3, dan di Aurora My versi 2.12.1 dan lebih tinggi. SQL
Ketika instans Aurora My SQL DB dikonfigurasi untuk menggunakan replikasi log biner, secara default instance replika menggunakan replikasi single-threaded untuk Aurora My versi lebih rendah dari 3.04. SQL Untuk mengaktifkan replikasi multi-thread, Anda memperbarui parameter replica_parallel_workers
ke nilai yang lebih besar dari nol di grup parameter kustom Anda.
Untuk Aurora My SQL versi 3.04 dan yang lebih tinggi, replikasi multithreaded secara default, dengan disetel ke. replica_parallel_workers
4
Anda dapat memodifikasi parameter ini di grup parameter kustom Anda.
Opsi konfigurasi berikut dapat membantu Anda menyesuaikan replikasi multi-thread. Untuk informasi penggunaan, lihat Opsi dan Variabel Replikasi dan Pencatatan Biner
Konfigurasi yang optimal akan bergantung 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_group_commit_sync_delay
-
binlog_group_commit_sync_no_delay_count
-
binlog_transaction_dependency_history_size
-
binlog_transaction_dependency_tracking
-
replica_preserve_commit_order
-
replica_parallel_type
-
replica_parallel_workers
Di Aurora My SQL 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 My SQL 2.10 dan yang lebih tinggi, Aurora secara otomatis menerapkan optimasi yang dikenal sebagai cache binlog I/O ke replikasi log biner. 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 tergantung pada SQL binlog_cache
pengaturan Saya.
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 Aurora SQL My 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 untuk memantau seberapa sering data dibaca dari binlog I/O cache.
-
aurora_binlog_io_cache_read_requests
menunjukkan jumlah permintaan baca I/O binlog dari cache. -
aurora_binlog_io_cache_reads
: menunjukkan jumlah baca I/O binlog yang mengambil informasi dari cache.
SQLKueri berikut menghitung persentase permintaan baca binlog yang memanfaatkan informasi yang di-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 cache I/O binlog juga menyertakan metrik baru yang terkait dengan thread 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 thread I/O replika. Angka itu berbeda dari lag utas SQL applier replika, yang diwakili oleh seconds_behind_master
metrik pada replika binlog. Anda dapat menentukan apakah replika binlog mengimbangi atau tertinggal di belakang sumber dengan memeriksa apakah jaraknya berkurang atau bertambah.