Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah lag replikasi log biner untuk Aurora MySQL
Bagian ini memberikan panduan tentang lag replikasi log biner untuk Aurora MySQL yang dikonfigurasi sebagai replika log biner. Ini mencakup arsitektur replikasi, replikasi paralel, pelacakan ketergantungan, pemantauan, dan praktik terbaik konfigurasi.
Replikasi log biner mereplikasi data antar MySQL-compatible database. Replikasi log biner yang tercakup dalam bagian ini tidak sinkron: sumber tidak menunggu replika untuk mengkonfirmasi penerapan perubahan sebelum melakukan transaksi. Ini tidak berlaku untuk replikasi semi-sinkron. Dalam replikasi semi-sinkron, sumber menunggu setidaknya satu replika untuk mengakui penerimaan transaksi sebelum melakukan. Misalnya, cluster Multi-AZ DB untuk Amazon RDS untuk MySQL menggunakan replikasi semi-sinkron, yang berada di luar cakupan untuk bagian ini. Replika mempertahankan koneksi persisten ke sumber melalui utas untuk I/O terus mengalirkan peristiwa log biner. Bagian ini berlaku untuk semua topologi replikasi binlog di mana Aurora MySQL adalah replika. Sumbernya bisa berupa cluster Aurora MySQL lainnya, Amazon RDS untuk MySQL, MySQL lokal, atau MySQL di Amazon EC2. Bagian ini juga berlaku ketika Aurora MySQL adalah sumber yang mereplikasi ke MySQL-compatible target apa pun.
**catatan**
Untuk kasus penggunaan replikasi lintas wilayah, pertimbangkan untuk menggunakan [Menggunakan Database Global Amazon Aurora](aurora-global-database.md) sebagai alternatif replikasi berbasis log biner. Aurora Global Database menggunakan infrastruktur khusus untuk replikasi, memberikan latensi yang lebih rendah dan membutuhkan manajemen operasional yang lebih sedikit daripada replikasi log biner di seluruh wilayah.
**Mengalami lonjakan lag sekarang? ** Lewati materi latar belakang dan mul [Mengidentifikasi hambatan lag replikasi](#aurora-mysql-replication-lag-identifying) ailah dengan menentukan apakah I/O thread atau utas SQL adalah hambatan, lalu ikuti tautan untuk skenario itu: [Memecahkan I/O masalah lag utas](#aurora-mysql-replication-lag-io-thread) atau. [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread)
**Topics**
+ [Arsitektur replikasi MySQL](#aurora-mysql-binlog-replication-lag-overview)
+ [Mengidentifikasi hambatan lag replikasi](#aurora-mysql-replication-lag-identifying)
+ [Memecahkan I/O masalah lag utas](#aurora-mysql-replication-lag-io-thread)
+ [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread)
+ [Multi-threaded replikasi (MTR)](#aurora-mysql-replication-lag-mtr)
+ [Aurora-specific optimasi replikasi](#aurora-mysql-replication-lag-aurora-optimizations)
+ [Memantau replikasi paralel](#aurora-mysql-replication-lag-monitoring)
+ [Praktik terbaik untuk meminimalkan jeda replikasi](#aurora-mysql-replication-lag-best-practices)
## Arsitektur replikasi MySQL
Replikasi MySQL diimplementasikan melalui utas khusus:
+ **Thread dump log biner (sumber) ** - Dibuat saat replika terhubung. Mengirim konten log biner ke replika. Terlihat `SHOW PROCESSLIST` sebagai utas “Binlog Dump”.
+ **Th I/O read replikasi (replika) ** — Menghubungkan ke sumber dan meminta pembaruan log biner. Menulisnya ke log relai replika. Selalu satu utas per saluran replikasi terlepas dari konfigurasi replikasi multi-utas (MTR).
+ **Replication SQL thread (replika) ** — Membaca log relay dan menerapkan transaksi. Applier selalu terdiri dari satu utas koordinator yang membaca transaksi dari log relay, ditambah N utas pekerja yang menerapkannya, di mana N adalah nilai dari`replica_parallel_workers`. Dengan`replica_parallel_workers=1`, pekerja tunggal menerapkan transaksi secara berurutan. Dengan`replica_parallel_workers >= 2`, koordinator menetapkan transaksi independen ke beberapa utas pekerja untuk penerapan paralel.
**catatan**
Peng `replica_parallel_workers=0` aturan tidak digunakan lagi sejak MySQL 8.0.30 dan dapat dihapus dalam rilis MySQL mendatang. Gunakan `replica_parallel_workers=1` untuk aplikasi utas tunggal sebagai gantinya.
Proses replikasi bekerja sebagai berikut:
1. Sumber mengeksekusi pernyataan DML, DCL, atau DDL.
1. Pada komit, sumber menulis data ke log biner.
1. U I/O tas pada replika mengambil peristiwa dan menulisnya ke log relay.
1. Utas SQL menerapkan perubahan dari log relai (single-thread atau multi-thread).
## Mengidentifikasi hambatan lag replikasi
Jeda replikasi dapat terjadi di dua area: I/O thread atau utas SQL. Langkah pertama adalah menentukan komponen mana yang tertinggal.
**catatan**
Bid `Seconds_Behind_Source` ang dalam `SHOW REPLICA STATUS` mengukur penundaan antara saat peristiwa dicatat pada sumber dan ketika utas SQL menerapkannya. Metrik ini tidak menunjukkan lag I/O utas secara khusus. Untuk mengidentifikasi I/O lag utas, Anda harus membandingkan posisi log biner seperti yang dijelaskan dalam langkah-langkah berikut.
**catatan**
Beberapa perintah MySQL dan string internal yang ditampilkan di bagian ini, seperti`SHOW MASTER STATUS`, menggunakan terminologi lama. Dokumentasi ini menggunakan istilah yang disukai “sumber” dan “replika” di seluruh bagian.
**Untuk menentukan thread replikasi mana yang tertinggal**
1. Pada replika, jalankan `SHOW REPLICA STATUS` dan bandingkan`Source_Log_File`/`Read_Source_Log_Pos`I/O (posisi utas) dengan`File`/`Position`dari `SHOW MASTER STATUS` sumber. Jika ini berbeda secara signifikan (>50 MB atau >1 file binlog terpisah), utasnya tertinggal I/O .
1. Bandingkan posisi I/O thread dengan posisi thread SQL (`Relay_Source_Log_File`/`Exec_Source_Log_Pos`). Jika ut I/O as tertangkap tetapi utas SQL ada di belakang (terpisah >50 MB), utas SQL adalah hambatannya.
**Penilaian awal cepat menggunakan data replika saja**
Anda dapat melakukan penilaian awal hanya menggunakan data sisi replika. Jalan `SHOW REPLICA STATUS` kan dua kali, dengan jarak 1-2 menit, dan amati hal berikut:
Jika `Read_Source_Log_Pos` maju tetapi `Exec_Source_Log_Pos` terhenti atau maju jauh lebih lambat, utas SQL adalah hambatan (Skenario B). Lanjut ke [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread).
Jika keduanya `Read_Source_Log_Pos` `Exec_Source_Log_Pos` terhenti saat `Seconds_Behind_Source` tumbuh, I/O benang kemungkinan tertinggal. Sebelum membuat perubahan konfigurasi, konfirmasikan dengan membandingkan posisi replika terhadap sumber menggunakan `SHOW MASTER STATUS` seperti yang dijelaskan pada langkah 1 dari prosedur sebelumnya.
| Skenario | I/O utas vs Sumber | Utas SQL vs ut I/O as | Kemacetan |
| --- | --- | --- | --- |
| A | Jauh di belakang (> 50 MB) | Tutup (<10 MB) | I/O benang |
| B | Tutup (<10 MB) | Jauh di belakang (> 50 MB) | Utas SQL |
| C | Jauh di belakang | Jauh di belakang | Keduanya (dimulai dengan I/O) |
**Example Menafsirkan posisi log biner**
Contoh berikut menunjukkan bagaimana membandingkan posisi log biner untuk menentukan bottleneck.
Pada replika, `SHOW REPLICA STATUS` mengembalikan:
```
Source_Log_File: mysql-bin.000045
Read_Source_Log_Pos: 524288000
Relay_Source_Log_File: mysql-bin.000045
Exec_Source_Log_Pos: 524200000
```
Pada sumbernya, `SHOW MASTER STATUS` mengembalikan:
```
File: mysql-bin.000045
Position: 1073741824
```
Untuk menentukan lag I/O utas, kurangi posisi I/O utas dari posisi sumber:
(1073741824 - 524288000)/1048576 = ** 524 MB ** - Thread jauh di belakang sumber (Skenario A). I/O
Untuk menentukan lag thread SQL, kurangi posisi thread SQL dari posisi I/O thread:
(524288000 - 524200000)/1048576 = ** 0.08 MB ** - Thread SQL mengikuti thread. I/O
Dalam hal ini, fokuskan pemecahan masalah pada I/O utas. Untuk informasi selengkapnya, lihat [Memecahkan I/O masalah lag utas](#aurora-mysql-replication-lag-io-thread).
**Anatomi lonjakan lag replikasi**
Pola umum adalah lonjakan tiba-tiba `Seconds_Behind_Source` diikuti oleh kembalinya cepat ke mendekati nol. Ini terjadi ketika DML yang berjalan lama pada sumber (seperti PEMINDAIAN UPDATE jutaan baris tetapi hanya memodifikasi beberapa baris) membutuhkan waktu beberapa menit untuk dieksekusi. Dengan logging ROW-based biner, hanya baris yang dimodifikasi yang ditulis ke log biner. Ketika thread SQL mengambil peristiwa ini, ia menghitung lag berdasarkan waktu mulai transaksi pada sumbernya. Ini menghasilkan nilai awal yang besar. Namun, karena hanya beberapa baris yang perlu diterapkan, replika mengejar ketinggalan dengan cepat. Ini adalah perilaku yang diharapkan dan tidak menunjukkan masalah replikasi berkelanjutan.
## Memecahkan I/O masalah lag utas
Th I/O read bertanggung jawab untuk mengambil peristiwa log biner dari sumber dan menuliskannya ke log relay. Penyebab dan resolusi umum:
| Penyebab | Bagaimana mengidentifikasi | Resolusi |
| --- | --- | --- |
| Batasan bandwidth jaringan | Periksa CloudWatch NetworkReceiveThroughput/NetworkTransmitThroughput | Gunakan instans dengan kapasitas jaringan yang lebih tinggi; pastikan kelas instance serupa pada sumber dan replika |
| Latensi jaringan (lintas wilayah atau lokal) | Jarak geografis antara sumber dan replika; waktu pulang-pergi yang tinggi | Untuk sumber lokal, gunakan untuk konektivitas khusus dengan latensi rendah |
| Kendala sumber daya pada sumber | CPU tinggi (CPUUtilization), tekanan memori (FreeableMemory) | Tingkatkan instance sumber. Setiap replika yang terhubung membuat thread dump binlog pada sumber — kurangi jumlah replika yang terhubung jika sumber dibatasi sumber daya. |
| Transaksi besar dengan BLOB/TEXT data | Pantau ukuran peristiwa log biner melalui SumBinaryLogSize CloudWatch metrik | Set binlog\_row\_image=noblob el; aktifkan kompresi transaksi log biner (binlog\_transaction\_compression=ON). Uji di non-produksi terlebih dahulu - kompresi meningkatkan pemanfaatan CPU pada sumber dan replika. |
| Batas ruang log relay tercapai | Replica\_IO\_Statemenunjukkan “Menunggu replika utas SQL untuk membebaskan ruang log relai yang cukup” | Ini menunjukkan bahwa thread SQL adalah akar penyebabnya, bukan ut I/O asnya. Atasi lag utas SQL terlebih dahulu. Di Aurora MySQL, defaultnya relay\_log\_space\_limit adalah sekitar 953 MiB. Pesan ini adalah bagian dari operasi normal ketika thread SQL tidak dapat menerapkan perubahan cukup cepat. Pesan ini tidak selalu menunjukkan masalah I/O kinerja utas. |
### Strategi pengoptimalan untuk I/O lag utas
1. **Gunakan setidaknya kelas instance yang sama dengan sumber ** - Pendekatan ini menyediakan CPU, memori, I/O kapasitas, dan bandwidth jaringan yang cukup.
1. **Pastikan bandwidth jaringan yang cukup ** — Gunakan instans dengan kapasitas jaringan tinggi. Untuk sumber lokal, pertimbangkan bandwidth khusus dan pengalaman jaringan yang lebih konsisten.
1. **Periksa sumber daya sisi sumber, terutama dengan banyak replika ** - Pantau CPU sumber, memori, jaringan, dan binlog. I/O Setiap replika yang terhubung menambahkan thread dump binlog pada sumbernya, sehingga sumber yang melayani banyak replika dapat dengan sendirinya menjadi hambatan. Sebaiknya konfirmasikan sumber tidak jenuh sebelum meningkatkan replika. Jika sumbernya terbatas sumber daya, pertimbangkan untuk mengurangi jumlah replika yang terhubung.
1. **Verifikasi I/O cache binlog Aurora aktif ** — C I/O ache binlog mengurangi disk I/O pada sumber untuk menyajikan peristiwa log biner. Ini diaktifkan secara otomatis di Aurora MySQL versi 2.10 dan lebih tinggi - tidak diperlukan konfigurasi. Jika sumbernya adalah cluster Aurora, verifikasi cache digunakan dengan`SHOW GLOBAL STATUS LIKE 'aurora_binlog_io_cache%'`. Untuk informasi selengkapnya, lihat [Mengoptimalkan replikasi binlog](binlog-optimization.md#binlog-optimization-binlog-io-cache).
1. **Aktifkan kompresi transaksi log biner ** — `binlog_transaction_compression=ON` Tetapkan dalam grup parameter. Mengurangi persyaratan bandwidth. Pengaturan ini memiliki pertimbangan berikut:
+ Kompresi meningkatkan pemanfaatan CPU pada sumber dan replika.
+ Uji di lingkungan non-produksi terlebih dahulu untuk menemukan keseimbangan optimal antara kompresi dan pemanfaatan sumber daya.
+ Secara opsional, sesuaikan tingkat kompresi menggunakan `binlog_transaction_compression_level_zstd` (default: 3, rentang: 1—22).
1. **Minimalkan penulisan ke log biner ** — Set `binlog_row_image=noblob` el untuk menghilangkan BLOB/TEXT data dari log biner. Jangan gunakan jika replika memiliki pemicu kolom BLOB referensi. Untuk informasi lebih lanjut, lihat [ binlog\_row\_image ](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_image) di situs web MySQL.
1. **Menerapkan filter replikasi pada sumber ** — Gunakan `binlog-do-db` atau `binlog-ignore-db` untuk mengecualikan database yang tidak perlu. Ini adalah parameter statis yang membutuhkan reboot.
**penting**
Source-side filter mempengaruhi apa yang ditulis ke log biner sepenuhnya. Database yang dikecualikan tidak direplikasi ke replika hilir mana pun. Jika sumbernya adalah instans MySQL yang dikelola sendiri (lokal atau di Amazon EC2), database yang dikecualikan juga tidak tersedia untuk pemulihan point-in-time berbasis log biner. Amazon RDS untuk MySQL tidak mendukung pemfilteran binlog sisi sumber (`binlog-do-db`/tidak dapat dikonfigurasi); gunakan `binlog-ignore-db` filter replikasi sisi replika sebagai gantinya. Aurora menggunakan volume cluster untuk PITR dan tidak terpengaruh oleh filter log biner untuk tujuan pencadangan.
## Memecahkan masalah lag utas SQL
Utas SQL adalah hambatan ketika utas ter I/O jebak dengan sumbernya tetapi berkembang`Seconds_Behind_Source`. Untuk mengukur lag, pantau lebih dari jendela 15 menit. Bandingkan tingkat pembuatan binlog pada sumber (`Position`delta dari`SHOW MASTER STATUS`) dengan tingkat penerapan utas SQL pada replika (`Exec_Source_Log_Pos`delta).
Penyebab dan resolusi umum:
| Penyebab | Bagaimana mengidentifikasi | Resolusi |
| --- | --- | --- |
| Single-threaded replikasi | SELECT @@global.replica\_parallel\_workers;mengembalikan 0 atau 1 | Aktifkan replikasi multi-utas (MTR) dengan pelacakan ketergantungan WRITESET. MTR saja tidak menyelesaikan lag jika konflik jam tinggi. Lihat [Pelacakan ketergantungan pada sumbernya](#aurora-mysql-replication-lag-mtr-dependency) untuk penyetelan pelacakan ketergantungan dan [Statistik replika multi-utas log kesalahan](#aurora-mysql-replication-lag-monitoring-error-log) untuk mengidentifikasi konflik jam. |
| Kurangnya kunci utama | Tanpa kunci primer (atau kunci unik dengan NOT NULL), replika melakukan pemindaian tabel lengkap untuk setiap baris yang dimodifikasi dalam operasi UPDATE dan DELETE. Gunakan kueri berikut untuk mengidentifikasi tabel tanpa kunci utama: SELECT t.table_schema, t.table_name
FROM information_schema.tables t
LEFT JOIN information_schema.table_constraints tc
ON t.table_schema = tc.table_schema
AND t.table_name = tc.table_name
AND tc.constraint_type = 'PRIMARY KEY'
WHERE tc.constraint_type IS NULL
AND t.table_type = 'BASE TABLE'
AND t.table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
ORDER BY 1;
| Tambahkan kunci utama ke semua tabel yang direplikasi. Jika menambahkan kunci primer eksplisit tidak segera memungkinkan, pertimbangkan untuk mengaktifkan Generated Invisible Primary Keys (GIPK) dengan mengatur sql\_generate\_invisible\_primary\_key parameter ke ON (tersedia dalam versi Aurora MySQL 3 berdasarkan MySQL 8.0.30 dan yang lebih baru). Untuk informasi selengkapnya tentang Kunci Utama Tak Terlihat yang Dibuat, lihat [ Kunci Utama Tak Terlihat yang ](https://dev.mysql.com/doc/refman/8.0/en/create-table-gipks.html) Dibuat di situs web MySQL. |
| Transaksi tulis besar pada sumber | Transaksi yang memodifikasi banyak baris (misalnya, UPDATE massal atau DELETE) direplikasi sebagai satu unit yang hanya dapat diterapkan oleh satu thread pekerja, terlepas dari konfigurasi MTR. Pada sumbernya, identifikasi transaksi tulis aktif yang berjalan lama dengan: SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_rows_modified > 10000
ORDER BY trx_started;
Pada replika, satu pekerja tetap sibuk dengan pernyataan yang sama SHOW PROCESSLIST sementara yang lain duduk diam. Long-running transaksi idle atau transaksi yang menunggu kunci pada sumber tidak dengan sendirinya menyebabkan jeda replikasi — hanya volume penulisan yang dikomit yang penting, karena peristiwa mencapai log biner pada waktu komit. | Pecahkan operasi massal menjadi transaksi yang lebih kecil (misalnya, beberapa ribu baris per komit) sehingga replika dapat menerapkannya secara paralel. Untuk contoh yang berhasil, lihat[Contoh 4: Satu transaksi besar tidak dapat disejajarkan](#aurora-mysql-replication-lag-monitoring-example4). |
| Operasi DDL | DDL memblokir peristiwa replikasi lainnya | Gunakan alat perubahan skema online, atau gunakan pener Blue/Green apan. Jadwalkan DDL selama periode lalu lintas rendah. Untukpt-online-schema-change, lihat [ Percona Toolkit ](https://docs.percona.com/percona-toolkit/) di situs web Percona. Untukgh-ost, lihat [ gh-ost ](https://github.com/github/gh-ost) di situs web. GitHub |
| Konfigurasi replikasi paralel yang tidak optimal | Pemanfaatan pekerja rendah; konflik jam tinggi dalam statistik koordinator. Centang bidang “Menunggu saat konflik jam” di entri log kesalahan statistik replika multi-utas (lihat[Statistik replika multi-utas log kesalahan](#aurora-mysql-replication-lag-monitoring-error-log)). Nilai tinggi relatif terhadap “detik berlalu” menunjukkan transaksi sering diblokir oleh dependensi. | Tune pelacakan ketergantungan (WRITESET) dan jumlah pekerja |
| Pertentangan sumber daya dari beban kerja analitis | Kueri OLAP kompleks bersaing dengan utas SQL untuk sumber daya (CPU, memori) | Pisahkan beban kerja analitik ke replika khusus |
| Statistik tabel usang | Rencana kueri suboptimal pada replika. Gunakan kueri berikut untuk mengidentifikasi tabel dengan statistik basi (lebih dari 7 hari): SELECT database_name, table_name,
MIN(last_update) AS oldest_stat_update,
DATEDIFF(NOW(), MIN(last_update)) AS stats_age_in_days
FROM mysql.innodb_index_stats
WHERE database_name NOT IN ('mysql', 'sys')
GROUP BY database_name, table_name
HAVING stats_age_in_days > 7
ORDER BY stats_age_in_days DESC;
| Jalan ANALYZE TABLE kan secara berkala pada tabel dengan statistik basi |
### Kurangi beban kerja terapan dengan filter replikasi sisi replika
Aurora MySQL versi 3.01.0 dan yang lebih tinggi mendukung filter replikasi sisi replika. Gunakan ini untuk melewati database atau tabel yang tidak relevan selama penerapan, mengurangi beban kerja thread SQL. Replica-side filter diterapkan oleh utas SQL — utas masih I/O mengambil semua peristiwa log biner dari sumbernya, jadi filter ini mengurangi pekerjaan terapan saja, bukan transfer jaringan. Tidak seperti filter sisi sumber (yang beroperasi pada tingkat database saja), filter sisi replika mendukung granularitas tingkat tabel menggunakan dan. `replicate-do-table` `replicate-ignore-table` Untuk informasi selengkapnya, lihat [Mengonfigurasi filter replikasi dengan Aurora MySQL](AuroraMySQL.Replication.Filters.md).
## Multi-threaded replikasi (MTR)
Dengan MTR, replika menerapkan transaksi independen secara paralel. Itu tidak dapat membagi satu transaksi besar menjadi bagian-bagian paralel. Tingkat paralelisme dibatasi oleh informasi ketergantungan yang ditulis oleh sumber.
Ketika MTR diaktifkan (`replica_parallel_workers >= 2`), aplikator SQL dibagi menjadi utas ** koordinator ** dan beberapa utas ** pekerja. ** Koordinator membaca transaksi dari log relay. Ini memeriksa stempel waktu logis (`last_committed`dan`sequence_number`) yang disematkan sumber dalam setiap transaksi. Kemudian menetapkan transaksi independen ke utas pekerja yang tersedia untuk eksekusi paralel. Dua transaksi independen jika mereka tidak berbagi dependensi data - yaitu, jika mereka memodifikasi baris yang berbeda. Sumber menentukan dependensi ini pada waktu komit menggunakan metode pelacakan ketergantungan yang dikonfigurasi dan merekamnya dalam log biner. Replika tidak dapat meningkatkan paralelisme di luar apa yang diizinkan sumber.
### MTR adalah default yang disarankan
Sebaiknya jalankan replika dengan MTR diaktifkan. MTR diaktifkan secara default (`replica_parallel_workers=4`) di MySQL 8.0.27 dan yang lebih tinggi, termasuk versi Aurora MySQL 3 berdasarkan rilis tersebut. Pada versi sebelumnya (Aurora MySQL 2.12.1 dan yang lebih tinggi, atau versi berdasarkan rilis MySQL sebelum 8.0.27), aktifkan secara eksplisit dengan menyetel `replica_parallel_workers` nilai 2 atau lebih. Menjaga MTR tetap aktif membutuhkan biaya sedikit ketika paralelisme tidak tersedia dan memungkinkan replika memanfaatkannya kapan pun beban kerja memungkinkan.
MTR tidak mengurangi lag dalam kasus berikut:
+ Kemacetan adalah utas ( I/O network/bandwidth masalah).
+ Lag disebabkan oleh satu transaksi yang berjalan lama.
+ Replikanya adalah CPU-saturated (lebih banyak utas membuatnya lebih buruk).
+ Tabel tidak memiliki kunci utama (memaksa pemindaian tabel penuh, meniadakan paralelisme).
### Pelacakan ketergantungan pada sumbernya
Sumber menentukan transaksi mana yang dapat diterapkan secara paralel menggunakan `binlog_transaction_dependency_tracking` parameter. Nilai yang disarankan:`WRITESET`.
+ **COMMIT\_ORDER ** — Melacak dependensi berdasarkan waktu komit. Bekerja paling baik dengan konkurensi tinggi dan komitmen grup besar. Paralelisme terbatas di lingkungan konkurensi rendah.
+ **WRITESET (disarankan) ** — Melacak dependensi data tingkat baris yang sebenarnya. Kinerja selalu setidaknya sebagus COMMIT\_ORDER. Secara signifikan lebih baik dengan beban kerja konkurensi rendah. Memerlukan tabel untuk memiliki kunci utama.
Pelacakan ketergantungan WRITESET menghasilkan writeset kosong atau sebagian (membatasi paralelisme) dalam kasus berikut:
+ Tabel tanpa kunci utama atau unik
+ Pernyataan DDL (CREATE TABLE, ALTER TABLE, dan sebagainya)
+ Transaksi yang mengubah tabel induk dalam hubungan kunci asing
Selain itu, riwayat ketergantungan dihapus ketika log biner berputar atau ketika `binlog_transaction_dependency_history_size` batas tercapai, sementara mengurangi paralelisme.
+ **WRITESET\_SESSION ** — Sama seperti WRITESET dengan batasan tambahan bahwa transaksi dari sesi yang sama tidak dapat diparalelkan.
**catatan**
MySQL 8.4 telah menghapus `binlog_transaction_dependency_tracking` dan default ke WRITESET (tidak dapat dikonfigurasi). Versi sebelumnya default ke COMMIT\_ORDER.
### Jenis paralel (`replica_` parallel\_type)
`replica_parallel_type`Parameter menentukan bagaimana transaksi didistribusikan di antara utas pekerja. Ada dua opsi:
+ **LOGICAL\_CLOCK (disarankan) ** — Menggunakan stempel waktu logis untuk menentukan transaksi mana yang dapat dieksekusi secara paralel, bahkan dalam database yang sama. Pendekatan ini menghasilkan throughput replikasi yang lebih tinggi dan latensi yang lebih rendah untuk sebagian besar beban kerja. Gunakan kecuali Anda memiliki beban kerja multi-database tertentu yang tidak mendapat manfaat darinya.
+ **DATABASE ** — Menetapkan transaksi ke thread pekerja berdasarkan database yang dipengaruhinya. Pertimbangkan hanya jika aplikasi Anda menggunakan beberapa database dengan beban kerja yang terpisah dengan jelas dan transaksi jarang melintasi batas database. Saat menggunakan DATABASE, `binlog_transaction_dependency_tracking` pengaturan pada sumber tidak digunakan — paralelisme ditentukan semata-mata oleh database mana yang ditargetkan transaksi.
**catatan**
Di MySQL versi 8.0.26 dan sebelumnya, `replica_parallel_type` default ke. `DATABASE` Dari MySQL 8.0.27 dan seterusnya, defaultnya menjadi. `LOGICAL_CLOCK` Jika Anda menggunakan versi yang lebih lama, setel parameter ini secara eksplisit `LOGICAL_CLOCK` untuk memanfaatkan pelacakan ketergantungan berbutir lebih halus.
### Konfigurasi MTR
**Source-side parameter**
| Parameter | Nilai yang disarankan | Catatan |
| --- | --- | --- |
| binlog\_transaction\_dependency\_tracking | SET TULIS | Kelompok parameter cluster. Dinamis. Tidak diperlukan untuk MySQL 8.4. |
| binlog\_transaction\_dependency\_history\_size | 25000 (standar) | Kelompok parameter cluster. Dinamis. Mengontrol berapa banyak hash baris yang disimpan sumber untuk pelacakan ketergantungan WRITESET; ketika riwayat terisi atau log biner berputar, itu dihapus dan paralelisme sementara turun. Pertimbangkan menggandakan nilai (misalnya, menjadi 50000) pada sumber yang banyak menulis jika replika menunjukkan lonjakan periodik dalam statistik log kesalahan “menunggu saat konflik jam” (lihat[Statistik replika multi-utas log kesalahan](#aurora-mysql-replication-lag-monitoring-error-log)) yang selaras dengan rotasi log biner. Nilai yang lebih besar menghabiskan lebih banyak memori pada sumber. |
| binlog\_format | BARIS | Kelompok parameter cluster. Statis (membutuhkan reboot). |
| binlog\_group\_commit\_sync\_delay | 0 (default) | Mikrodetik untuk menunda komit grup. Meningkatkan nilai ini mengelompokkan lebih banyak transaksi bersama-sama, meningkatkan paralelisme pada replika dengan mengorbankan sedikit peningkatan latensi komit pada sumber. Hanya bermanfaat saat menggunakan pelacakan ketergantungan COMMIT\_ORDER — WRITESET sudah melacak dependensi tingkat baris yang sebenarnya terlepas dari waktu komit. Dinamis. |
| binlog\_group\_commit\_sync\_no\_delay\_count | 0 (default) | Jumlah transaksi maksimum yang harus ditunggu sebelum melakukan. Gunakan with binlog\_group\_commit\_sync\_delay untuk membatasi penundaan setelah transaksi yang cukup dilakukan. Hanya relevan untuk pelacakan ketergantungan COMMIT\_ORDER. Dinamis. |
**Replica-side parameter**
| Parameter | Nilai yang disarankan | Catatan |
| --- | --- | --- |
| replica\_parallel\_workers | Mulai dari jumlah vCPU, hingga dua kali jumlah vCPU | Grup parameter instance. Dinamis tetapi membutuhkan restart replikasi. Default komunitas adalah 4 pada MySQL 8.0.27 (dan versi Aurora MySQL 3 berdasarkan itu); versi sebelumnya default ke 0, yang tidak digunakan lagi sejak MySQL 8.0.30. Sebaiknya mulai dari hitungan vCPU, lalu memantau pemanfaatan CPU dan statistik log kesalahan “Menunggu (hitung) ketika Pekerja diduduki” (lihat[Statistik replika multi-utas log kesalahan](#aurora-mysql-replication-lag-monitoring-error-log)). Tingkatkan hanya ketika “Tunggu (hitung) ketika Pekerja diduduki” secara konsisten tinggi dan pemanfaatan CPU tetap di bawah 80%. |
| replica\_parallel\_type | LOGIK\_JAM | Kelompok parameter cluster. Dinamis tetapi membutuhkan restart replikasi. |
| replica\_pending\_jobs\_size\_max | > = max\_allowed\_packet pada sumber | Grup parameter instance. Dinamis. |
| replica\_preserve\_commit\_order | PADA | Kelompok parameter cluster. Dinamis tetapi membutuhkan restart replikasi. |
| binlog\_format | MATI | Kelompok parameter cluster. Statis. Aurora-specific ekstensi untuk menonaktifkan logging biner. |
Setelah mengubah pengaturan pekerja paralel, mulai ulang replikasi:
```
CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;
```
## Aurora-specific optimasi replikasi
Aurora MySQL menyediakan fitur-fitur berikut untuk meningkatkan kinerja replikasi log biner. Tabel berikut merangkum ketersediaan, status default, dan cara mengaktifkan setiap fitur.
| Fitur | Versi | Default | Cara mengaktifkan/memverifikasi |
| --- | --- | --- | --- |
| In-memory log relai | Aurora MySQL 3.10\+ | ON (untuk Aurora-managed replikasi saat kondisi terpenuhi) | Secara otomatis diaktifkan untuk Aurora-managed replikasi (blue/green penerapan, Aurora-to-Aurora, dan replika lintas wilayah) saat replika menggunakan replikasi utas tunggal (replica\_parallel\_workers=0), replikasi multi-utas dengan mode GTID dan penentuan posisi otomatis diaktifkan, atau replikasi berbasis file dengan. replica\_preserve\_commit\_order=ON Dikendalikan oleh aurora\_in\_memory\_relaylog parameter dinamis (cluster DB atau tingkat instance): hentikan replikasi, atur ke ON atau OFF dalam grup parameter, lalu mulai ulang replikasi — tidak perlu reboot instance. Tidak tersedia diAurora Serverless. Verifikasi status saat ini denganSHOW GLOBAL STATUS LIKE 'Aurora\_in\_memory\_relaylog\_status'. Untuk informasi selengkapnya, lihat [In-memory log relai](binlog-optimization.md#binlog-optimization-in-memory-relay-log). |
| Perubahan indeks sekunder paralel | Aurora MySQL 3.06\+ | MATI (0) | Atur aurora\_binlog\_replication\_sec\_index\_parallel\_workers ke jumlah utas yang diinginkan. Hentikan replikasi, atur parameter, lalu mulai replikasi. Tidak diperlukan restart instans. Untuk informasi selengkapnya, lihat [Replikasi log biner multithreaded](binlog-optimization.md#binlog-optimization-multithreading). |
| Cache Binlog I/O | Aurora MySQL 2.10\+ dan 3.x | ON (otomatis) | Secara otomatis diaktifkan. Mengurangi disk I/O pada sumber saat menyajikan peristiwa log biner ke replika. Tidak diperlukan konfigurasi. Untuk informasi selengkapnya, lihat [Mengoptimalkan replikasi binlog](binlog-optimization.md#binlog-optimization-binlog-io-cache). |
## Memantau replikasi paralel
Gunakan metode berikut untuk memantau kinerja replikasi dan mengidentifikasi hambatan secara paralel berlaku:
### Skema Performa
Tabel kunci untuk memantau MTR:
+ `performance_schema.replication_applier_status_by_worker`— Menampilkan detail transaksi yang ditangani oleh setiap thread pekerja, termasuk menerapkan stempel waktu dan kesalahan.
+ `performance_schema.replication_applier_status_by_coordinator`— Menampilkan informasi tentang aktivitas buffering thread koordinator.
Untuk mengevaluasi seberapa merata pekerjaan didistribusikan di seluruh utas pekerja, gunakan kueri berikut:
```
SELECT
a.channel_name,
rw1.thread_id AS replica_worker_thread_id,
ts1.count_star AS number_of_trx_executed,
ROUND((ts1.count_star / sum_count_star) * 100, 2) AS percent_of_trx_executed_by_worker
FROM (
SELECT rw.channel_name, SUM(ts.count_star) AS sum_count_star
FROM performance_schema.events_transactions_summary_by_thread_by_event_name AS ts
JOIN performance_schema.replication_applier_status_by_worker AS rw
ON ts.thread_id = rw.thread_id
GROUP BY rw.channel_name
) AS a
JOIN performance_schema.replication_applier_status_by_worker AS rw1
ON a.channel_name = rw1.channel_name
JOIN performance_schema.events_transactions_summary_by_thread_by_event_name AS ts1
ON rw1.thread_id = ts1.thread_id;
```
Jika satu atau dua pekerja menangani sebagian besar transaksi, ini menunjukkan ketergantungan transaksi yang tinggi yang membatasi paralelisme. Pertimbangkan untuk beralih ke pelacakan ketergantungan WRITESET pada sumber.
Jika posisi I/O thread dan utas SQL dekat satu sama lain tetapi `Seconds_Behind_Source` masih berkembang, utas koordinator itu sendiri mungkin menjadi hambatan. Periksa `performance_schema.replication_applier_status_by_coordinator` penundaan buffering. Kemacetan koordinator biasanya menunjukkan dependensi transaksi yang berat atau utas koordinator tunggal yang kelebihan beban yang tidak dapat mendistribusikan peristiwa dengan cukup cepat.
### Statistik replika multi-utas log kesalahan
Ketika `log_error_verbosity=3` (default), Aurora MySQL menulis statistik replika multi-thread ke log kesalahan MySQL secara berkala. Anda dapat melihat entri ini dengan:
+ Di konsol RDS, di ** bagian ** Log & event, lihat log kesalahan.
+ Mengunduh melalui AWS CLI: `aws rds download-db-log-file-portion --db-instance-identifier --log-file-name error/mysql-error-running.log`
+ Jika ekspor CloudWatch log diaktifkan untuk log kesalahan, cari di grup log yang diekspor.
Untuk menemukan entri statistik replika multi-utas di log kesalahan, cari string yang ditunjukkan dalam contoh berikut. Log kesalahan MySQL menggunakan terminologi lama dalam string internal ini; dokumentasi ini menggunakan istilah yang disukai “replika” di seluruh.
Berikut ini adalah contoh entri log kesalahan:
```
2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 7215200; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1203644200 waited (count) when Workers occupied = 1022462 waited when Workers occupied = 62349203500
```
Bidang utama untuk dianalisis:
| Bidang | Deskripsi | Tindakan |
| --- | --- | --- |
| detik berlalu | Waktu dalam detik sejak output statistik terakhir. Aurora MySQL tidak menulis statistik secara berkala - ia menulisnya berdasarkan jumlah peristiwa yang dieksekusi ditambah waktu yang berlalu. | Gunakan untuk menghitung throughput: peristiwa yang ditetapkan/detik berlalu = peristiwa rata-rata per interval. |
| acara yang ditugaskan | Jumlah peristiwa yang ditetapkan oleh utas koordinator ke utas pekerja sejak keluaran terakhir. | Pantau perubahan throughput replikasi dari waktu ke waktu. |
| Antrian pekerja terisi di atas level overrun | Jumlah peristiwa yang diantri ke thread pekerja melebihi level overrun (90% dari panjang antrian maksimum 16384 peristiwa). Jika nol, tidak ada pekerja yang beroperasi pada kapasitas atas. | Menunjukkan pekerja tidak dapat mengikuti koordinator. Periksa transaksi yang berjalan lama atau indeks yang hilang. |
| Menunggu karena antrian Pekerja penuh | Berapa kali koordinator harus menunggu karena antrian thread pekerja penuh (mencapai kapasitas 100%). | Periksa transaksi yang berjalan lama, indeks yang hilang, atau mengunci pertentangan di utas pekerja. |
| Menunggu karena ukuran total | Berapa kali koordinator menunggu karena replica\_pending\_jobs\_size\_max batas tercapai. Jika peristiwa besar yang luar biasa melebihi ukuran ini, transaksi diadakan sampai semua pekerja memiliki antrian kosong. | Meningkatkanreplica\_pending\_jobs\_size\_max. Periksa transaksi besar pada sumbernya. |
| Menunggu saat konflik jam | Jumlah nanodetik yang ditunggu koordinator karena transaksi bergantung pada transaksi lain yang belum dilakukan. Ini mengukur peristiwa waktu tidak dapat ditetapkan karena dependensi. | Beralih ke pelacakan ketergantungan WRITESET pada sumber. Pastikan tabel memiliki kunci utama. Beberapa konflik jam menunggu diharapkan — fokus pada pengurangan rasio relatif terhadap penantian lainnya. |
| Menunggu (hitung) saat Pekerja diduduki | Berapa kali koordinator perlu menetapkan peristiwa pertama transaksi tetapi semua antrian pekerja tidak kosong. Koordinator tidur sampai antrian menjadi kosong. | Ini menunjukkan replica\_parallel\_workers kekurangan pasokan. Dependensi bukanlah hambatan — Anda bisa saja mengeksekusi lebih banyak peristiwa secara paralel tetapi tidak memiliki utas pekerja yang tersedia. Meningkatkanreplica\_parallel\_workers. |
| Menunggu ketika pekerja diduduki | Total nanodetik koordinator tidur sambil menunggu antrian pekerja kosong. | Nilai tinggi mengkonfirmasi kapasitas pekerja adalah hambatan. Meningkatkanreplica\_parallel\_workers. |
### Contoh kerja: mendiagnosis hambatan penerapan paralel
Contoh berikut menunjukkan cara menggunakan sumber pemantauan sebelumnya untuk mendiagnosis hambatan penerapan paralel umum. Setiap contoh dimulai dari gejala yang sama - `Seconds_Behind_Source` terus berkembang dan Anda telah mengonfirmasi bahwa utas SQL adalah hambatan (lihat[Mengidentifikasi hambatan lag replikasi](#aurora-mysql-replication-lag-identifying)) - dan menggunakan statistik replika multi-thread dan Skema Kinerja untuk menentukan tindakan korektif.
#### Contoh 1: Pekerja kekurangan pasokan
Pada CloudWatch tahun, `ReplicaLag` metrik naik dengan mantap dari mendekati nol menjadi sekitar 400 detik selama 30 menit. Pemanfaatan CPU pada replika tetap sekitar 55%, jadi replika tidak CPU-bound.
Untuk mengonfirmasi di mana lag berada, jalankan `SHOW REPLICA STATUS` dua kali, terpisah 60 detik. `Read_Source_Log_Pos`meningkat sekitar 1,2 GB sementara `Exec_Source_Log_Pos` naik hanya sekitar 300 MB. U I/O tas mengikuti sumbernya, tetapi utas SQL tertinggal - utas SQL adalah hambatannya.
MTR diaktifkan dengan`replica_parallel_workers=4`. Ambil statistik replika multi-utas terbaru dari log kesalahan (lihat[Statistik replika multi-utas log kesalahan](#aurora-mysql-replication-lag-monitoring-error-log)):
```
2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 123; events assigned = 9876544; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 8455000 waited (count) when Workers occupied = 2456789 waited when Workers occupied = 110293847000
```
Menafsirkan bidang utama:
+ **menunggu ketika Pekerja diduduki = 110293847000 ** nanodetik, atau sekitar 110 detik. Dari 123 detik dalam interval ini, koordinator menghabiskan sekitar 90% waktunya menunggu thread pekerja menjadi gratis.
+ **menunggu pada konflik jam = 8455000 ** nanodetik, atau sekitar 0,008 detik, yang dapat diabaikan. Dependensi transaksi bukanlah faktor pembatas.
**Diagnosis: ** koordinator secara konsisten memiliki lebih banyak transaksi independen yang siap diterapkan daripada memiliki pekerja untuk menjalankannya. Karena menunggu konflik jam dapat diabaikan, paralelisme dibatasi oleh jumlah pekerja, bukan oleh dependensi.
**Tind ** akan: `replica_parallel_workers` tingkatkan jumlah vCPU replika (misalnya, 16 pada a`db.r6g.4xlarge`) dan mulai ulang replikasi:
```
CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;
```
**Verifikasi: ** baris statistik selanjutnya menunjukkan penantian hampir hilang, dan `ReplicaLag` kembali ke bawah 5 detik:
```
2026-05-10 15:02:14.882201 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 31840552; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 9120000 waited (count) when Workers occupied = 41233 waited when Workers occupied = 5980411000
```
“menunggu ketika Pekerja diduduki” turun dari sekitar 110 detik menjadi sekitar 6 detik, dan throughput (peristiwa yang ditetapkan) lebih dari tiga kali lipat. Hentikan peningkatan pekerja setelah pemanfaatan CPU mendekati 80% atau penantian berhenti menurun.
#### Contoh 2: Pelacakan ketergantungan COMMIT\_ORDER membuat serial beban kerja konkurensi rendah
Sumbernya adalah instans Amazon RDS untuk MySQL yang menjalankan beban kerja OLTP dengan hanya 4-8 utas aplikasi yang berkomitmen secara bersamaan. Replikanya adalah `db.r6g.4xlarge` dengan `replica_parallel_workers=16` dan`replica_parallel_type=LOGICAL_CLOCK`. Meskipun 16 pekerja, `ReplicaLag` tahan stabil sekitar 600 detik dan pemanfaatan CPU replika hanya sekitar 20% - pekerja terlihat menganggur.
Pertama, periksa seberapa merata transaksi didistribusikan di seluruh pekerja menggunakan kueri distribusi pekerja dari: [Skema Performa](#aurora-mysql-replication-lag-monitoring-perf-schema)
```
+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
| | 45 | 1903556 | 96.41 |
| | 46 | 23104 | 1.17 |
| | 47 | 18995 | 0.96 |
| | 48 | 16720 | 0.85 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+
```
Output sebelumnya menunjukkan 4 pertama dari 16 utas pekerja. Satu pekerja menerapkan lebih dari 96% transaksi sementara 15 lainnya hampir menganggur (masing-masing pekerja yang tersisa dieksekusi kurang dari 0,05%). Terapkan secara efektif serial.
Selanjutnya, konfirmasikan ini dengan statistik replika multi-utas di log kesalahan:
```
2026-05-10 15:22:11.110432 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 2014500; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 98712340000 waited (count) when Workers occupied = 50122 waited when Workers occupied = 1209847000
```
+ **menunggu pada konflik jam = 98712340000 ** nanodetik, atau sekitar 99 dari 120 detik. Koordinator menghabiskan sekitar 82% dari interval tidak dapat mengirimkan transaksi berikutnya karena bergantung pada transaksi yang masih diterapkan.
+ **menunggu ketika Pekerja diduduki = 1209847000 ** nanodetik, atau sekitar 1,2 detik. Pekerja hampir selalu bebas, jadi lebih banyak pekerja tidak membantu.
Ini menunjukkan masalah ketergantungan, bukan masalah kapasitas. Periksa metode pelacakan ketergantungan pada ** sumber**:
```
SELECT @@global.binlog_transaction_dependency_tracking;
```
```
+-------------------------------------------------+
| @@global.binlog_transaction_dependency_tracking |
+-------------------------------------------------+
| COMMIT_ORDER |
+-------------------------------------------------+
```
**Akar penyebab: ** dengan`COMMIT_ORDER`, sumber memutuskan transaksi mana yang dapat berjalan secara paralel berdasarkan transaksi mana yang dilakukan bersama dalam komit grup log biner yang sama. Dalam beban kerja konkurensi rendah ini, hanya segelintir thread yang melakukan satu waktu, jadi commit grup sangat kecil. Akibatnya, sumber mencap hampir setiap transaksi dengan `last_committed` nilai yang sama dengan transaksi sebelumnya`sequence_number`, menandainya sebagai tergantung pada transaksi sebelumnya. Replika kemudian harus menerapkannya satu demi satu - meskipun mereka memodifikasi baris yang sama sekali tidak terkait - itulah sebabnya 15 dari 16 pekerja duduk diam.
**Tindakan: ** alihkan sumber ke pelacakan ketergantungan tingkat baris, yang tidak bergantung pada waktu komit. Atur secara dinamis dan pertahankan dalam grup parameter cluster (atau DB):
```
SET GLOBAL binlog_transaction_dependency_tracking = WRITESET;
```
`WRITESET`menghitung hash dari baris yang dimodifikasi setiap transaksi, sehingga transaksi yang menyentuh baris yang berbeda menerima cap waktu independen dan dapat diterapkan secara paralel terlepas dari kapan mereka melakukan. Pastikan semua tabel memiliki kunci utama, karena WRITESET menghasilkan writeset kosong untuk tabel tanpa kunci tersebut (lihat). [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread) Pada MySQL 8.4, WRITESET adalah default dan parameter ini tidak ada lagi.
**Verifikasi: ** setelah perubahan, kueri distribusi pekerja menunjukkan pekerjaan tersebar merata di semua pekerja (menunjukkan 4 pertama dari 16; setiap pekerja sekarang menangani sekitar 6% transaksi):
```
+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
| | 45 | 132540 | 6.30 |
| | 46 | 125610 | 5.97 |
| | 47 | 129774 | 6.17 |
| | 48 | 122901 | 5.84 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+
```
dan statistik log kesalahan menunjukkan konflik jam runtuh saat `ReplicaLag` jatuh mendekati nol:
```
2026-05-10 15:41:55.204713 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 19874100; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 412300000 waited (count) when Workers occupied = 88122 waited when Workers occupied = 7019847000
```
“menunggu saat konflik jam” turun dari sekitar 99 detik menjadi sekitar 0,4 detik, throughput naik kira-kira sepuluh kali lipat, dan hambatan bergeser dari dependensi ke kapasitas pekerja - di mana Anda dapat menyetel jumlah pekerja seperti pada Contoh 1.
#### Contoh 3: Kunci primer yang hilang memaksa pemindaian tabel penuh pada replika
`ReplicaLag`melonjak selama pekerjaan batch malam hari yang menjalankan `DELETE` pernyataan besar `UPDATE` dan, lalu pulih sesudahnya. Selama lonjakan, CPU replika sedang tetapi satu pekerja tampak macet.
Pada replika, jalankan `SHOW PROCESSLIST` dan lihat thread pekerja replikasi. Satu pekerja tetap di `Updating` negara bagian dengan pernyataan yang sama selama beberapa detik pada satu waktu:
```
+----+-------------+------+---------+----------+------+
| Id | User | db | Command | State | Time |
+----+-------------+------+---------+----------+------+
| 12 | system user | app | Connect | Updating | 38 |
+----+-------------+------+---------+----------+------+
```
Periksa tabel yang direplikasi mana yang tidak memiliki kunci utama menggunakan kueri deteksi dari: [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread)
```
+--------------+----------------+
| table_schema | table_name |
+--------------+----------------+
| app | events_archive |
+--------------+----------------+
```
**Akar penyebab: ** dengan logging ROW-based biner, setiap baris dalam `DELETE` acara `UPDATE` atau harus ditempatkan pada replika sebelum dapat diterapkan. Jika tabel tidak memiliki kunci primer atau kunci NOT NULL unik, replika melakukan pemindaian tabel lengkap untuk ** setiap baris yang ** terpengaruh. Pada tabel multi-juta baris, operasi batch berubah menjadi jutaan pemindaian penuh, dan pekerja yang menerapkannya terhenti — memblokir kemajuan aplikasi dan meningkatkan lag.
**Tind ** akan: tambahkan kunci utama ke tabel. Jika Anda tidak dapat menentukan kunci eksplisit segera, aktifkan Generated Invisible Primary Keys (GIPK) dengan mengatur `sql_generate_invisible_primary_key` parameter ke `ON` (tersedia dalam versi Aurora MySQL 3 berdasarkan MySQL 8.0.30 dan yang lebih baru), sehingga tabel baru menerima kunci primer otomatis (lihat). [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread)
**Verifikasi: ** setelah menambahkan kunci utama, pekerja tidak lagi berlama-lama`Updating`, tarif penerapan utas SQL pulih, dan `ReplicaLag` kembali ke baseline selama jendela batch berikutnya.
#### Contoh 4: Satu transaksi besar tidak dapat disejajarkan
`ReplicaLag`melompat tajam pada waktu yang dapat diprediksi setiap hari, tahan selama beberapa menit, lalu turun kembali mendekati nol. Pelacakan ketergantungan WRITESET diaktifkan`replica_parallel_workers=16`,, dan semua tabel memiliki kunci utama, sehingga contoh sebelumnya tidak berlaku.
Selama lonjakan, kueri distribusi pekerja menunjukkan satu pekerja sibuk dan sisanya menganggur, tetapi tidak seperti Contoh 2, log kesalahan tidak menunjukkan konflik jam tinggi atau penantian yang diduduki pekerja:
```
2026-05-10 02:13:40.551922 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 95; events assigned = 4120000; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1530000 waited (count) when Workers occupied = 980 waited when Workers occupied = 210440000
```
Penantian ketergantungan dan penantian yang diduduki pekerja rendah, namun hanya satu pekerja yang aktif. Ini mengesampingkan kemacetan ketergantungan (Contoh 2) dan kemacetan kapasitas pekerja (Contoh 1).
Periksa pekerja yang sibuk`performance_schema.replication_applier_status_by_worker`, atau jalankan`SHOW PROCESSLIST`. Seorang pekerja tunggal menerapkan satu transaksi untuk seluruh durasi lonjakan. Pada sumber, pekerjaan aplikasi menjalankan satu pernyataan besar — misalnya, `DELETE FROM orders WHERE created_at < '2025-01-01'` mempengaruhi beberapa juta baris — sebagai satu transaksi.
**Akar penyebab: ** MTR paralel ** di seluruh transaksi ** independen; itu tidak dapat membagi satu transaksi di antara pekerja. Transaksi besar diterapkan oleh tepat satu pekerja, jadi menambahkan pekerja, beralih ke WRITESET, atau menambahkan kunci utama tidak membantu. Untuk informasi selengkapnya, lihat [Multi-threaded replikasi (MTR)](#aurora-mysql-replication-lag-mtr).
**Tind ** akan: pecahkan operasi besar menjadi batch yang lebih kecil pada sumber (misalnya, hapus beberapa ribu baris per transaksi, dengan jeda singkat di antara batch). Transaksi yang lebih kecil dilakukan secara independen, sehingga replika dapat menyebarkannya ke seluruh pekerja. Jadwalkan pekerjaan massal selama jendela lalu lintas rendah jika memungkinkan.
**Verifikasi: ** setelah melakukan batch pekerjaan, `ReplicaLag` lonjakan harian menjadi rata, dan kueri distribusi pekerja menunjukkan penyebaran batch di beberapa pekerja, bukan satu.
### Memantau praktik terbaik
1. Konfigurasikan CloudWatch alarm pada `ReplicaLag` metrik dengan ambang batas yang sesuai.
1. Gunakan tabel detak jantung untuk pengukuran lag yang lebih akurat daripada`Seconds_Behind_Source`. Misalnya, gunakan`pt-heartbeat`, yang memerlukan instalasi terpisah (lihat [ Percona Toolkit ](https://docs.percona.com/percona-toolkit/) di situs web Percona).
1. Pantau `SumBinaryLogSize` CloudWatch metrik pada sumber untuk melacak tingkat pembuatan log biner.
1. Akti CloudWatch fkan ekspor log log untuk log kesalahan untuk mempertahankan statistik replika multi-utas.
1. Gunakan Pemantauan yang Ditingkatkan untuk CPU, memori, dan I/O pemanfaatan pada sumber dan replika.
1. Gunakan Amazon CloudWatch Database Insights untuk mengidentifikasi peristiwa tunggu dan kueri teratas yang menyebabkan pertikaian sumber daya. Performance Insights mencapai akhir masa pakai pada 31 Juli 2026; setelah tanggal tersebut konsol Performance Insights dialihkan ke CloudWatch Database Insights. Pilih mode Database Insights yang sesuai dengan kebutuhan Anda — Mode standar mempertahankan pengalaman dan harga pemantauan inti, sementara mode Lanjutan menambahkan pemantauan tingkat armada, diagnostik kunci, dan pengambilan rencana eksekusi. Untuk informasi selengkapnya, lihat [Memantau beban DB dengan Amazon CloudWatch Database Insights di Amazon Aurora](USER_PerfInsights.md).
## Praktik terbaik untuk meminimalkan jeda replikasi
Rekomendasi berikut merangkum tindakan utama untuk meminimalkan jeda replikasi. Untuk panduan terperinci tentang setiap topik, ikuti tautan referensi silang.
1. **Pastikan semua tabel memiliki kunci utama ** — Tanpa kunci utama, replika melakukan pemindaian tabel penuh untuk setiap baris yang dimodifikasi dalam operasi UPDATE dan DELETE. Untuk informasi selengkapnya, lihat [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread).
1. **Aktifkan replikasi multi-utas dengan WRITESET ** — Paralelize SQL berlaku untuk transaksi independen. Untuk detail konfigurasi, lihat[Multi-threaded replikasi (MTR)](#aurora-mysql-replication-lag-mtr).
1. **Gunakan setidaknya kelas instance yang sama dengan sumber ** - Menyediakan CPU, memori, dan sumber daya jaringan yang cukup untuk replikasi. Untuk informasi selengkapnya, lihat [Strategi pengoptimalan untuk I/O lag utas](#aurora-mysql-replication-lag-io-optimization).
1. **Jaga agar ukuran transaksi tetap kecil ** — Transaksi besar mengurangi paralelisme dan meningkatkan Panjang Daftar Riwayat. Untuk informasi selengkapnya, lihat [Memecahkan masalah lag utas SQL](#aurora-mysql-replication-lag-sql-thread).
1. **Nonaktifkan logging biner pada replika ** — Tetapkan `binlog_format=OFF` kecuali diperlukan replikasi hilir. Untuk detail parameter, lihat [Konfigurasi MTR](#aurora-mysql-replication-lag-mtr-config).
1. **Hindari transaksi dan kueri yang berjalan lama pada replika ** — Long-running baca transaksi mencegah pembersihan daftar riwayat, yang dapat menurunkan kinerja replikasi.
1. **Aktifkan GTID-based replikasi ** - Menyediakan pelacakan posisi otomatis dan mengaktifkan log relai dalam memori Aurora (Aurora MySQL 3.10\+). Lihat informasi yang lebih lengkap di [Aurora-specific optimasi replikasi](#aurora-mysql-replication-lag-aurora-optimizations).