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](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) 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](mysql-replication-gtid.md).
Opsi konfigurasi berikut dapat membantu Anda menyesuaikan replikasi multi-thread. Untuk informasi penggunaan, lihat [Replication and Binary Logging Options and Variables](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) dalam *Panduan Referensi MySQL*. Untuk informasi selengkapnya tentang replikasi multithreaded, lihat MySQL Blog [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/) 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_tracking`Nilai yang direkomendasikan adalah `WRITESET`
+ `replica_preserve_commit_order`
+ `replica_parallel_type`Nilai yang direkomendasikan adalah `LOGICAL_CLOCK`
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction`Nilai 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_requests`menunjukkan jumlah permintaan I/O baca binlog dari cache.
+ `aurora_binlog_io_cache_reads`menunjukkan 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\$1parallel\$1workers = 0)
+ Replikasi multi-utas dengan mode GTID diaktifkan:
+ Posisi otomatis diaktifkan
+ Mode GTID diatur ke ON pada replika
+ Replikasi berbasis file dengan replica\$1preserve\$1commit\$1order = 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\$1in\$1memory\$1relaylog, 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
1. Setel aurora\$1in\$1memory\$1relaylog ke ON (untuk mengaktifkan) atau OFF (untuk menonaktifkan) di grup parameter
1. 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\$1in\$1memory\$1relaylog 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.