ApsaraDB RDS:Penyebab\ dan\ solusi\ untuk\ latensi\ sinkronisasi\ pada\ instans\ read\-only\ RDS\ for\ MySQL

Penyebab 1: Spesifikasi instans read-only terlalu rendah

Apa yang terjadi. Replikasi menggunakan thread I/O (untuk mengambil log biner dari primary) dan thread SQL (untuk menerapkannya secara lokal). Kedua thread bersaing untuk sumber daya I/O, termasuk operasi input/output per detik (IOPS). Jika instans read-only tidak mampu mempertahankan IOPS yang dibutuhkan, ia akan tertinggal.

Cara memastikan. Di Konsol ApsaraDB RDS, buka Monitoring and Alerts untuk instans read-only. Periksa apakah utilisasi CPU, penggunaan memori, bandwidth I/O, atau IOPS secara konsisten mencapai batas maksimumnya. Anda juga dapat melihat tipe instans di bagian Configuration Information pada halaman Basic Information. Untuk informasi lebih lanjut, lihat Tipe instans untuk instans read-only ApsaraDB RDS for MySQL (x86) dan Tipe instans untuk instans read-only ApsaraDB RDS for MySQL (ARM).

Cara memperbaiki. Upgrade instans read-only ke spesifikasi yang setara atau lebih tinggi daripada instans primary. Untuk informasi lebih lanjut, lihat Mengubah spesifikasi instans ApsaraDB RDS for MySQL.

Penyebab 2: Transaksi per detik (TPS) tinggi pada instans primary

Apa yang terjadi. Satu thread SQL menerapkan semua transaksi yang direplikasi pada instans read-only secara serial. Jika instans primary memproses volume besar penulisan konkuren, instans read-only tidak mampu mengimbangi.

Cara memastikan. Buka halaman Dashboard instans primary atau read-only dan periksa metrik TPS. Untuk informasi lebih lanjut, lihat Menggunakan fitur dashboard untuk instans ApsaraDB RDS for MySQL.

Cara memperbaiki. Optimalkan atau pecah transaksi besar pada instans primary untuk mengurangi volume penulisan per transaksi dan mempersingkat waktu setiap transaksi menahan thread SQL.

Penyebab 3: Transaksi besar pada instans primary

Apa yang terjadi. Operasi seperti UPDATE, DELETE, INSERT...SELECT, dan REPLACE...SELECT pada volume data besar menghasilkan entri log biner yang besar. Instans read-only harus menghabiskan waktu yang sama untuk menerapkan transaksi tersebut seperti yang dihabiskan oleh instans primary saat mengeksekusinya. Misalnya, penghapusan yang memakan waktu 80 detik pada primary juga memerlukan 80 detik untuk direplikasi.

Selain itu, meskipun transaksi konkuren pada beberapa tabel didukung, hanya satu thread yang mereplikasi transaksi pada tabel tertentu dalam satu waktu, yang dapat memperparah keterlambatan.

Cara memastikan. Jalankan SHOW SLAVE STATUS \G pada instans read-only dan amati apakah Seconds_Behind_Master terus meningkat sementara Exec_Master_Log_Pos tetap sama. Kemudian jalankan SHOW PROCESSLIST untuk mengidentifikasi thread SQL tertentu. Jika binary logging diatur ke format ROW, periksa apakah ada file log biner yang melebihi ambang batas max_binlog_size:

SHOW BINARY LOGS;

Jika File_size melebihi max_binlog_size, kemungkinan besar transaksi besar adalah penyebabnya.

Periksa juga adanya kontensi kunci metadata (MDL) dengan memeriksa output SHOW SLAVE STATUS \G untuk kondisi menunggu kunci.

Cara memperbaiki. Pecah transaksi besar menjadi batch yang lebih kecil. Misalnya, tambahkan klausa WHERE dengan batasan jumlah baris pada pernyataan DELETE sehingga setiap batch memproses jumlah baris yang dapat dikelola, memungkinkan instans read-only tetap mengimbangi.

Penyebab 4: DDL berdurasi panjang pada instans primary

Apa yang terjadi. Replikasi menerapkan pernyataan Data Definition Language (DDL) secara serial. Operasi DDL pada tabel besar—seperti CREATE INDEX, ALTER TABLE ADD COLUMN, atau REPAIR TABLE—dapat memblokir seluruh replikasi berikutnya hingga selesai. Kueri lambat yang menghasilkan banyak tabel temporary memperparah masalah ini dengan mengonsumsi I/O disk.

Secara terpisah, kueri yang sedang berjalan atau transaksi terbuka pada instans read-only dapat menyebabkan kontensi MDL yang memblokir pernyataan DDL yang datang dari primary.

Cara memastikan.

• Periksa apakah file log biner terus bertambah tanpa dipotong, yang mengindikasikan backlog DDL.

• Jalankan pernyataan berikut pada instans read-only untuk memeriksa kontensi kunci:

  SHOW ENGINE INNODB STATUS \G

• Jalankan pernyataan berikut untuk mengidentifikasi tabel yang sedang digunakan:

  SHOW OPEN TABLES;

  Tabel dengan in_use = 1 terkunci dan mungkin memblokir replikasi.

• Tinjau log kueri lambat untuk operasi terkait DDL seperti OPTIMIZE, ALTER, REPAIR, dan CREATE. Untuk informasi lebih lanjut, lihat Analisis log kueri lambat.

Cara memperbaiki.

• Jadwalkan operasi DDL pada jam sepi.

• Aktifkan fitur ekspansi penyimpanan otomatis, atau atur ambang batas ekspansi penyimpanan manual menjadi 90%. Untuk informasi lebih lanjut, lihat Bagaimana cara melakukan scaling pada instans ApsaraDB RDS?

• Aktifkan SQL Explorer untuk memantau kinerja SQL secara berkala. Untuk informasi lebih lanjut, lihat Menggunakan fitur SQL Explorer dan Audit pada instans ApsaraDB RDS for MySQL.

• Konfigurasikan peringatan penggunaan disk atau upgrade spesifikasi instans. Untuk informasi lebih lanjut, lihat Mengubah spesifikasi instans ApsaraDB RDS for MySQL.

Jika pernyataan DDL dari primary diblokir oleh kunci metadata pada instans read-only:

1. Jalankan SHOW PROCESSLIST; pada instans read-only untuk menemukan thread SQL yang menunggu kunci metadata.

2. Hentikan session yang memegang kunci tersebut untuk melanjutkan replikasi. Untuk informasi lebih lanjut, lihat Menggunakan DMS untuk melepaskan kunci metadata.

Penyebab 5: Tabel memiliki indeks unik tetapi tidak memiliki primary key

Apa yang terjadi. Ketika sebuah tabel tidak memiliki primary key dan hanya memiliki indeks unik yang berisi nilai NULL, thread SQL replikasi menggunakan rencana eksekusi berdasarkan indeks unik tersebut alih-alih rencana yang dipilih oleh pengoptimal—meskipun klausa WHERE seharusnya memungkinkan pencarian yang lebih efisien. Hal ini memaksa pemindaian tabel penuh selama replikasi, yang secara signifikan meningkatkan logical read dan memperlambat thread SQL.

Cara memastikan. Jalankan kueri berikut pada instans primary untuk mengidentifikasi tabel yang tidak memiliki primary key:

SELECT tab.table_schema AS database_name, tab.table_name
FROM information_schema.tables tab
LEFT JOIN information_schema.table_constraints tco
  ON tab.table_schema = tco.table_schema
  AND tab.table_name = tco.table_name
  AND tco.constraint_type = 'PRIMARY KEY'
WHERE tco.constraint_type IS NULL
  AND tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
  AND tab.table_type = 'BASE TABLE'
ORDER BY tab.table_schema, tab.table_name;

Untuk tabel yang dikembalikan oleh kueri tersebut, gunakan view sys.schema_index_statistics untuk memastikan apakah indeks unik tersebut berisi nilai NULL.

Cara memperbaiki. Tambahkan primary key eksplisit ke setiap tabel yang tidak memilikinya.