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 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
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 sumbernya 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
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 keROW -
binlog_group_commit_sync_delay -
binlog_group_commit_sync_no_delay_count -
binlog_transaction_dependency_history_size -
binlog_transaction_dependency_trackingNilai yang direkomendasikan adalahWRITESET -
replica_preserve_commit_order -
replica_parallel_typeNilai yang direkomendasikan adalahLOGICAL_CLOCK -
replica_parallel_workers -
replica_pending_jobs_size_max -
transaction_write_set_extractionNilai yang direkomendasikan adalahXXHASH64
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
ROWformat, 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 lebih tinggi, Aurora secara otomatis menerapkan optimisasi yang dikenal sebagai cache I/O binlog 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 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 untuk memantau seberapa sering data dibaca dari binlog I/O cache.
-
aurora_binlog_io_cache_read_requestsmenunjukkan jumlah permintaan baca I/O binlog dari cache. -
aurora_binlog_io_cache_reads: menunjukkan jumlah baca I/O 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 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 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.
