Apa yang harus dilakukan jika instance ApsaraDB RDS for MySQL baca-saja saya mengalami latensi saat menyinkronkan data dari instance utama? - ApsaraDB RDS

Topik ini menjelaskan penyebab dan solusi untuk latensi selama replikasi data antara instance ApsaraDB RDS for MySQL utama dan instance RDS baca-saja.

Deskripsi Masalah

Instance RDS baca-saja menggunakan mekanisme replikasi asinkron atau semi-asinkron berbasis log asli MySQL untuk menyinkronkan data dari instance RDS utama. Mekanisme ini dapat menyebabkan latensi replikasi. Latensi tersebut dapat menyebabkan ketidaksesuaian data antara instance RDS baca-saja dan utama serta memengaruhi beban kerja Anda. Selain itu, latensi replikasi dapat menyebabkan akumulasi log, yang secara cepat menghabiskan kapasitas penyimpanan instance RDS baca-saja.

Catatan

Jika sejumlah besar log sedang dibuat untuk instance RDS utama, instance RDS baca-saja mungkin terkunci.
Parameter Seconds_Behind_Master dalam output pernyataan SHOW SLAVE STATUS \G menunjukkan latensi replikasi berbasis log.
Perhitungan Latensi: Latensi = Waktu saat ini - Titik waktu ketika transaksi yang diterapkan pada instance RDS sekunder dikomit pada instance RDS utama. Waktu saat ini adalah titik waktu ketika Anda mengeksekusi pernyataan SHOW SLAVE STATUS \G.

Latensi replikasi dapat diklasifikasikan menjadi jenis-jenis berikut berdasarkan durasinya:

Latensi kurang dari atau sama dengan 1 detik. Jenis latensi ini disebabkan oleh akurasi perhitungan, metode perhitungan, titik pengambilan sampel, dan granularitas pemantauan. Jika jenis latensi ini terjadi, replikasi data berjalan normal, dan Anda dapat mengabaikan masalah ini.
Latensi lebih dari 1 detik. Jenis latensi ini terjadi dalam skenario berikut: Spesifikasi instance RDS baca-saja rendah, transaksi per detik (TPS) instance RDS utama besar, transaksi besar ada di instance RDS utama, atau pernyataan DDL pada instance RDS utama dieksekusi untuk jangka waktu yang lama. Jika jenis latensi ini terjadi, Anda harus mengidentifikasi penyebab dan menyelesaikan masalah.

Penyebab

Penyebab untuk latensi kurang dari atau sama dengan 1 detik

Latensi kurang dari 1 detik: Rentang waktu pemantauan diatur ke nilai besar. Tidak ada latensi aktual dari jenis ini yang terjadi, dan Anda dapat mengabaikan masalah ini.
Jika rentang waktu pemantauan mencakup periode panjang, granularitas pemantauan menjadi besar. Misalnya, jika rentang waktu pemantauan adalah 3 jam, granularitas pemantauan default bisa mencapai 30 detik. Data yang dihitung setiap kali adalah nilai rata-rata dalam periode 30 detik, sehingga latensi kurang dari 1 detik mungkin dilaporkan. Namun, granularitas minimum dari latensi yang dihitung adalah 1 detik.
Untuk mendapatkan latensi yang lebih akurat, Anda dapat masuk ke konsol ApsaraDB RDS, pergi ke tab Performance Trends, dan mengatur rentang waktu pemantauan ke nilai kurang dari 6 menit. Dengan cara ini, Anda dapat melihat latensi dengan granularitas pemantauan 1 detik. Untuk informasi lebih lanjut, lihat Gunakan fitur dasbor untuk instance ApsaraDB RDS for MySQL.

Latensi 1 detik: Jenis latensi ini disebabkan oleh akurasi perhitungan, metode perhitungan, titik pengambilan sampel, dan transaksi lintas detik. Tidak ada latensi aktual dari jenis ini yang terjadi, dan Anda dapat mengabaikan masalah ini.

Dalam ApsaraDB RDS for MySQL, titik-titik pengambilan sampel selalu dibulatkan ke detik terdekat. Misalnya, titik pengambilan sampel 00:00:00.95 dianggap sebagai titik pengambilan sampel 00:00:00, dan titik pengambilan sampel 00:00:01.05 dianggap sebagai titik pengambilan sampel 00:00:01. Jika titik pengambilan sampel melampaui ke detik berikutnya, latensi dihitung sebagai 1 detik terlepas dari apakah latensi aktual kurang dari 1 detik. Hal ini ditunjukkan pada baris 4 tabel berikut.

Transaksi	Waktu komit pada instance RDS utama	Waktu komit pada instance RDS sekunder	Waktu saat ini	Latensi akurat hingga detik
Trx1	00:00:00.30	00:00:00.50	00:00:00.35	0(0.35) - 0(0.3) = 0
			00:00:00.45	0(0.45) - 0(0.3) = 0
Trx2	00:00:00.90	00:00:01.10	00:00:00.95	0(0.95) - 0(0.9) = 0
			00:00:01.05	1(1.05) - 0(0.9) = 1

Data dikumpulkan pada interval 1 detik, dan setiap titik pengambilan sampel melampaui ke detik berikutnya. Jika beban kerja berat atau transaksi lintas detik ada, latensi 1 detik mungkin diperoleh pada setiap titik pengambilan sampel. Jika titik pengambilan sampel tidak melampaui ke detik berikutnya, seperti 00:00:00.95, latensi 0 detik diperoleh, seperti yang ditunjukkan pada baris 3 dalam tabel di atas.

Penyebab untuk latensi lebih dari 1 detik

Jenis latensi ini dapat terjadi karena penyebab berikut:

Penyebab 1: Spesifikasi rendah instance RDS baca-saja
Spesifikasi instance RDS baca-saja lebih rendah daripada spesifikasi instance RDS utamanya, dan beban kerja pada instance RDS baca-saja berat. Misalnya, IOPS instance RDS baca-saja tinggi. Untuk tujuan konsistensi data, instance RDS baca-saja menggunakan mekanisme replikasi berbasis log asli MySQL untuk menyinkronkan data dari instance RDS utama. Mekanisme ini memulai thread I/O dan thread SQL. Thread I/O membaca log dari instance RDS utama, dan thread SQL menerapkan log ke instance RDS baca-saja. Kedua thread tersebut mengonsumsi sumber daya I/O instance RDS baca-saja. Jika instance RDS baca-saja tidak dapat menyediakan sumber daya yang cukup untuk mempertahankan IOPS yang sesuai, latensi sinkronisasi data terjadi antara instance RDS baca-saja dan utama. Anda dapat masuk ke konsol ApsaraDB RDS dan melihat IOPS pada halaman Pemantauan dan Peringatan.
Penyebab 2: TPS tinggi instance RDS utama
Instance RDS baca-saja menggunakan thread untuk menyinkronkan data dari instance RDS utama. Jika instance RDS utama memproses penulisan multi-thread konkuren dan TPS instance RDS utama secara signifikan tinggi, latensi sinkronisasi data terjadi antara instance RDS baca-saja dan utama.
Penyebab 3: Transaksi besar
- Transaksi yang melakukan operasi seperti UPDATE, DELETE, INSERT...SELECT, dan REPLACE...SELECT pada volume data besar dieksekusi pada instance RDS utama. Sejumlah besar data log dihasilkan dan perlu dikirim ke instance RDS baca-saja. Instance RDS baca-saja memerlukan periode waktu yang sama dengan instance RDS utama untuk menyelesaikan transaksi. Ini menyebabkan latensi sinkronisasi data. Misalnya, jika Anda melakukan operasi penghapusan yang berlangsung selama 80 detik pada instance RDS utama, juga memerlukan 80 detik bagi instance RDS baca-saja untuk menyelesaikan operasi yang sama. Akibatnya, latensi sinkronisasi data terjadi.
- Transaksi konkuren pada beberapa tabel didukung. Namun, hanya satu thread yang dapat digunakan untuk mereplikasi transaksi pada tabel. Ini memperpanjang periode replikasi.
Penyebab 4: Pernyataan DDL dieksekusi untuk jangka waktu yang lama pada instance RDS utama
- Sinkronisasi data antara instance RDS baca-saja dan instance RDS utamanya dilakukan secara berurutan. Jika pernyataan DDL dieksekusi pada tabel besar untuk jangka waktu yang lama atau sejumlah besar kueri lambat dieksekusi pada instance RDS utama, sejumlah besar tabel sementara dihasilkan. Ini menyebabkan penyimpanan tidak mencukupi dan meningkatkan disk I/O, sehingga menyebabkan latensi. Pernyataan DDL umum termasuk CREATE INDEX, REPAIR TABLE, dan ALTER TABLE ADD COLUMN.
- Kueri atau transaksi yang sedang berlangsung pada instance RDS baca-saja memblokir pernyataan DDL yang disinkronkan dari instance RDS utama.
Penyebab 5: Kasus khusus
- Tidak ada indeks yang sesuai untuk pernyataan SQL yang dieksekusi untuk mereplikasi data. Akibatnya, sejumlah besar pemindaian tabel penuh dilakukan dan jumlah pembacaan logis secara signifikan meningkat.
- Jika sebuah tabel hanya memiliki indeks unik dengan nilai NULL dan tidak memiliki kunci utama, rencana eksekusi untuk indeks unik daripada rencana eksekusi yang dipilih oleh pengoptimal digunakan secara prioritas ketika instance RDS sekunder mereplikasi data. Ini berlaku bahkan jika Anda menggunakan klausa WHERE untuk menentukan kondisi kueri.

Metode Identifikasi

Jika latensi kurang dari atau sama dengan 1 detik, Anda dapat mengabaikan masalah ini. Bagian ini menjelaskan cara mengidentifikasi penyebab latensi yang lebih dari 1 detik.

Metode identifikasi untuk Penyebab 1
- Lihat tipe instance instance RDS baca-saja di bagian Informasi Konfigurasi halaman Informasi Dasar instance RDS baca-saja di konsol ApsaraDB RDS. Untuk informasi lebih lanjut, lihat Tipe instance untuk instance ApsaraDB RDS for MySQL baca-saja (x86) dan Tipe instance untuk instance ApsaraDB RDS for MySQL baca-saja (ARM).
- Lihat informasi pemantauan, termasuk utilisasi CPU, penggunaan memori, bandwidth I/O, dan jumlah koneksi, pada halaman Pemantauan dan Peringatan instance RDS baca-saja di konsol ApsaraDB RDS. Kemudian, periksa apakah ada hambatan sumber daya pada instance RDS baca-saja berdasarkan informasi pemantauan.
Metode identifikasi untuk Penyebab 2
Lihat TPS instance RDS utama atau baca-saja pada halaman Dasbor instance RDS. Untuk informasi lebih lanjut, lihat Gunakan fitur dasbor untuk instance ApsaraDB RDS for MySQL.
Metode identifikasi untuk Penyebab 3
- Masuk ke instance RDS dan eksekusi pernyataan SHOW SLAVE STATUS \G untuk memeriksa apakah nilai parameter Seconds_Behind_Master terus berubah sementara nilai parameter Exec_Master_Log_Pos tetap tidak berubah. Jika ini terjadi, thread SQL instance RDS baca-saja sedang mengeksekusi transaksi besar atau operasi DDL. Output serupa dengan gambar berikut ditampilkan.
  Kemudian, eksekusi pernyataan SHOW PROCESSLIST untuk mengidentifikasi thread spesifik.
- Eksekusi pernyataan SHOW SLAVE STATUS \G pada instance RDS baca-saja untuk menentukan apakah metadata locks (MDLs) ada.
- Jika format logging biner diatur ke ROW, transaksi besar menghasilkan file log biner besar. Anda dapat mengeksekusi pernyataan SHOW BINARY LOGS; untuk melihat nilai parameter File_size. Jika nilainya lebih besar dari nilai parameter max_binlog_size, transaksi besar ada.
Metode identifikasi untuk Penyebab 4
- Periksa volume log biner pada instance RDS baca-saja untuk menentukan apakah operasi DDL ada. Jika file log biner tidak dipotong secara tepat waktu, file log biner besar dihasilkan.
- Periksa apakah tabel yang tidak mengandung kunci utama dihapus atau diperbarui pada instance RDS baca-saja. Anda dapat mengeksekusi pernyataan SHOW ENGINE INNODB STATUS \G pada instance RDS baca-saja untuk melihat hasil output. Anda juga dapat mengeksekusi pernyataan SHOW OPEN TABLES; untuk melihat tabel-tabel yang nilainya di kolom in_use adalah 1.
- Lihat informasi tentang log kueri lambat untuk memeriksa apakah operasi DDL, seperti OPTIMIZE, ALTER, REPAIR, dan CREATE, ada. Untuk informasi lebih lanjut, lihat Log kueri lambat.
Metode identifikasi untuk Penyebab 5 (kunci unik dengan nilai NULL)
1. Gunakan view sys.schema_index_statistics untuk memeriksa apakah tabel tidak memiliki kunci utama dan hanya memiliki indeks unik.
2. Periksa apakah indeks unik mengandung nilai NULL.

Solusi

Penting

Sebelum Anda melakukan operasi berisiko tinggi, seperti memodifikasi konfigurasi atau data instance, kami sarankan Anda memeriksa kemampuan pemulihan bencana dan toleransi kesalahan instance untuk memastikan keamanan data.
Sebelum Anda memodifikasi konfigurasi atau data instance, seperti instance Elastic Compute Service (ECS) atau instance RDS, kami sarankan Anda membuat snapshot atau mengaktifkan cadangan untuk instance tersebut. Misalnya, Anda dapat mengaktifkan pencadangan log untuk instance RDS.
Jika Anda memberikan izin pada informasi sensitif atau mengirimkan informasi sensitif di Konsol Manajemen Alibaba Cloud, kami sarankan Anda memodifikasi informasi sensitif tersebut sesegera mungkin. Informasi sensitif mencakup nama pengguna dan kata sandi.

Bagian ini menjelaskan metode penanganan umum. Anda dapat menggunakan salah satu metode berikut berdasarkan penyebab yang diidentifikasi:

Metode penanganan untuk Penyebab 1
Kami sarankan Anda meningkatkan spesifikasi instance RDS baca-saja dan memastikan bahwa spesifikasi instance RDS baca-saja lebih besar dari atau sama dengan spesifikasi instance RDS utamanya. Ini mencegah latensi replikasi yang disebabkan oleh spesifikasi kecil instance RDS baca-saja. Untuk informasi lebih lanjut, lihat Ubah spesifikasi instance ApsaraDB RDS for MySQL.
Metode penanganan untuk Penyebab 2
Jika TPS instance RDS utama tinggi, optimalkan atau pisahkan transaksi Anda.
Metode penanganan untuk Penyebab 3
Pisahkan transaksi besar menjadi transaksi yang lebih kecil. Misalnya, Anda dapat menambahkan klausa WHERE dalam pernyataan DELETE untuk membatasi volume data yang dapat dihapus sekaligus untuk membagi operasi penghapusan menjadi operasi yang lebih kecil. Dengan cara ini, instance RDS baca-saja dapat dengan cepat menyelesaikan transaksi besar tanpa latensi.
Metode penanganan untuk Penyebab 4
- Jika latensi sinkronisasi data pada instance RDS baca-saja disebabkan oleh operasi DDL, kami sarankan Anda melakukan operasi DDL selama jam non-puncak. Anda dapat menggunakan salah satu metode berikut:
  - Dukungan layanan: Aktifkan fitur ekspansi penyimpanan otomatis. Anda juga dapat mengatur ambang batas untuk memicu ekspansi penyimpanan manual ke 90%. Untuk informasi lebih lanjut, lihat Bagaimana cara menskalakan instance ApsaraDB RDS?
  - Optimasi SQL: Aktifkan SQL Explorer untuk memeriksa kinerja pernyataan SQL secara berkala. Untuk informasi lebih lanjut, lihat Gunakan fitur SQL Explorer dan Audit pada instance ApsaraDB RDS for MySQL.
  - Beban: Konfigurasikan aturan peringatan untuk penggunaan disk atau tingkatkan spesifikasi secara manual. Untuk informasi lebih lanjut, lihat Ubah spesifikasi instance ApsaraDB RDS for MySQL.
- Jika operasi DDL yang disinkronkan dari instance RDS utama diblokir pada instance RDS baca-saja, lakukan langkah-langkah berikut:
  1. Eksekusi pernyataan SHOW PROCESSLIST; pada instance RDS baca-saja untuk mengidentifikasi thread SQL yang statusnya menunggu kunci metadata tabel.
  2. Jalankan perintah kill untuk menghentikan sesi yang menyebabkan blokir pada instance RDS baca-saja untuk melanjutkan sinkronisasi data antara instance RDS baca-saja dan instance RDS utamanya. Untuk informasi lebih lanjut, lihat Gunakan DMS untuk melepaskan kunci metadata.
Metode penanganan untuk Penyebab 5
Tambahkan kunci utama eksplisit ke tabel yang tidak memiliki kunci utama.

FAQ

Mengapa latensi 1 detik terjadi pada beberapa instance RDS baca-saja saya?
Prosedur pengumpulan dan waktu mulai instance RDS baca-saja berbeda satu sama lain. Jika titik pengambilan sampel pada beberapa instance RDS baca-saja melampaui ke detik berikutnya, latensi 1 detik terjadi. Jika titik pengambilan sampel pada beberapa instance RDS baca-saja tidak melampaui ke detik berikutnya, tidak ada latensi 1 detik yang terjadi. Untuk informasi lebih lanjut, lihat Penyebab untuk latensi kurang dari atau sama dengan 1 detik.
Apakah instance RDS saya terpengaruh jika latensi 1 detik terjadi pada instance RDS saya?
Tidak, instance RDS Anda tidak terpengaruh. Latensi 1 detik tidak menunjukkan bahwa latensi aktual terjadi pada instance RDS Anda. Misalnya, jika latensi aktual adalah 0,1 detik tetapi titik pengambilan sampel melampaui ke detik berikutnya, latensi 1 detik dilaporkan. Dalam kasus ini, latensi 1 detik disebabkan oleh akurasi perhitungan, metode perhitungan, dan titik pengambilan sampel. Untuk informasi lebih lanjut, lihat Penyebab untuk latensi kurang dari atau sama dengan 1 detik.
Kami sarankan Anda menentukan ambang batas latensi baca untuk proxy atau memicu peringatan berdasarkan persyaratan bisnis Anda. Pastikan bahwa nilai ambang batas yang ditentukan lebih besar dari 1 detik.
Apa yang harus saya lakukan jika pesan kesalahan ReplicationInterrupted ditampilkan atau peringatan Slave_SQL_Running atau Slave_IO_Running dilaporkan untuk instance RDS baca-saja?
Anda perlu mengidentifikasi penyebab kesalahan tersebut.
- Periksa apakah kapasitas penyimpanan instance RDS baca-saja mencukupi.
  Jika kapasitas penyimpanan tidak mencukupi, instance RDS baca-saja tidak dapat menyinkronkan log biner instance RDS utama.
  Catatan
  Anda dapat melihat penggunaan penyimpanan instance RDS baca-saja di bagian Usage Statistics halaman Basic Information.
- Periksa latensi replikasi.
  Jika latensi replikasi terus melebihi 5 detik dalam 5 menit, latensi instance RDS baca-saja tinggi, dan peringatan dipicu. Jika data sering ditulis ke instance RDS utama atau transaksi besar ada pada instance RDS utama, replikasi data mungkin terganggu.
  Catatan
  Untuk melihat latensi replikasi, lakukan operasi berikut: Pergi ke halaman Basic Information instance RDS baca-saja. Di panel navigasi kiri halaman, klik Monitoring and Alerts. Pada tab Standard Monitoring, lihat nilai metrik Latensi Replikasi Instance Sekunder(detik).
- Periksa log kueri lambat.
  Log kueri lambat secara signifikan memengaruhi kinerja instance dan dapat meningkatkan latensi replikasi.
  Catatan
  Anda dapat menggunakan salah satu metode berikut untuk memeriksa log kueri lambat pada halaman Basic Information instance RDS baca-saja:
  - Di panel navigasi kiri, klik Logs. Kemudian, periksa log kueri lambat pada tab Slow Query Logs.
  - Di panel navigasi kiri, pilih Autonomy Services > Slow Query Logs untuk memeriksa log kueri lambat.
Jika gangguan replikasi tidak disebabkan oleh penyebab-penyebab di atas, Anda dapat mengabaikan kesalahan tersebut. Sistem secara otomatis akan memeriksa instance dan menyelesaikan masalah gangguan replikasi.