Apa yang harus saya lakukan jika instans read-only ApsaraDB RDS for MySQL saya menyinkronkan data dari instans utamanya dengan latensi sinkronisasi? - 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 menyebabkan latensi replikasi. Latensi replikasi dapat mengakibatkan ketidaksesuaian data antara instance RDS baca-saja dan utama serta memengaruhi beban kerja Anda. Selain itu, latensi replikasi juga dapat menyebabkan akumulasi log, yang secara cepat menghabiskan kapasitas penyimpanan instance RDS baca-saja.

Catatan

Jika banyak log dihasilkan untuk instance RDS utama, instance RDS baca-saja mungkin terkunci.
Latensi replikasi ditampilkan di bidang second_behind_master (dalam detik) dari output perintah show slave status \G.
Perhitungan latensi: Latensi = Waktu saat ini - Titik waktu ketika transaksi yang sedang diterapkan pada instance sekunder dikomit pada instance utama. Waktu saat ini menunjukkan titik waktu ketika Anda menjalankan perintah show slave status \G.

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

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 pada instance RDS utama, dan pernyataan DDL pada instance RDS utama dieksekusi untuk periode 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 waktu yang lama, granularitas pemantauan besar. Misalnya, jika rentang waktu pemantauan adalah 3 jam, granularitas pemantauan default mungkin hingga 30 detik. Data yang dihitung setiap kali adalah nilai rata-rata dalam periode 30 detik, dan 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 Manajemen ApsaraDB RDS, pergi ke tab Performance Trends, dan kemudian atur rentang waktu pemantauan ke nilai yang 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 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 melintasi ke detik berikutnya, latensi dihitung sebagai 1 detik terlepas dari apakah latensi aktual kurang dari 1 detik. Ini ditunjukkan pada baris 4 tabel berikut.

Transaksi	Waktu komit pada instance RDS utama	Waktu komit pada instance RDS sekunder	Waktu saat ini (titik waktu ketika Anda mengeksekusi pernyataan SHOW SLAVE STATUS \G)	Latensi akurat ke 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 melintasi 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 melintasi ke detik berikutnya, seperti 00:00:00.95, latensi 0 detik diperoleh, seperti yang ditunjukkan pada baris 3 pada tabel sebelumnya.

Penyebab untuk latensi lebih dari 1 detik

Jenis latensi ini mungkin 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 Manajemen 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 80 detik pada instance RDS utama, dibutuhkan 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 periode 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 banyak kueri lambat dieksekusi pada instance RDS utama, banyak tabel sementara dihasilkan. Hal ini menyebabkan penyimpanan tidak mencukupi dan meningkatkan disk I/O, dan latensi terjadi. Pernyataan DDL umum termasuk CREATE INDEX, REPAIR TABLE, dan ALTER TABLE ADD COLUMN.
- Kueri atau transaksi yang sedang berlangsung yang dilakukan pada instance RDS baca-saja memblokir pernyataan DDL yang disinkronkan dari instance RDS utama.
Kasus khusus
- Tidak ada indeks yang sesuai untuk pernyataan SQL yang dieksekusi untuk mereplikasi data. Akibatnya, banyak 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 optimizer 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.

Spesifikasi instance baca-saja terlalu kecil
- Lihat tipe instance instance RDS baca-saja di bagian Informasi Konfigurasi halaman Informasi Dasar instance RDS baca-saja di Konsol Manajemen ApsaraDB RDS. Untuk informasi lebih lanjut, lihat Tipe instance untuk instance ApsaraDB RDS for MySQL baca-saja standar (arsitektur x86 asli) dan Tipe instance untuk instance ApsaraDB RDS for MySQL baca-saja YiTian (arsitektur ARM asli).
- 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 Manajemen ApsaraDB RDS. Kemudian, periksa apakah ada hambatan sumber daya pada instance RDS baca-saja berdasarkan informasi pemantauan.
Transaksi per detik (TPS) instance utama terlalu tinggi.
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
Penulisan transaksi besar
- Ketika transaksi besar disinkronkan ke instance baca-saja dan menyebabkan latensi, masuk ke database dan jalankan pernyataan SQL show slave status \G. Jika nilai parameter Seconds_Behind_Master terus berubah sementara nilai parameter Exec_Master_Log_Pos tetap tidak berubah, itu menunjukkan bahwa thread SQL instance baca-saja sedang mengeksekusi transaksi besar atau operasi DDL. Output serupa dengan gambar berikut ditampilkan:
  Terakhir, jalankan pernyataan show processlist; untuk mengidentifikasi thread spesifik.
- Jalankan pernyataan show slave status \G pada instance baca-saja untuk menentukan apakah ada kunci metadata.
- Jika format pencatatan biner diatur ke ROW, transaksi besar menghasilkan file log biner yang besar. Anda dapat menjalankan perintah SHOW BINARY LOGS; untuk melihat nilai File_size. Jika nilainya lebih besar dari nilai parameter `max_binlog_size`, transaksi besar ada.
Waktu eksekusi pernyataan DDL pada instance utama lama.
- Periksa volume log biner pada instance RDS baca-saja untuk menentukan apakah operasi DDL ada. Jika file log biner tidak dipotong tepat waktu, file log biner besar dihasilkan.
- Periksa apakah tabel tanpa kunci utama sedang dihapus atau diperbarui pada instance baca-saja. Anda dapat menjalankan pernyataan show engine innodb status \G untuk memeriksa, atau jalankan pernyataan show open tables; dan periksa output untuk tabel yang memiliki nilai 1 di kolom in_use.
- Lihat informasi tentang log kueri lambat untuk memeriksa apakah operasi DDL, seperti OPTIMIZE, ALTER, REPAIR, dan CREATE, ada. Untuk informasi lebih lanjut, lihat Analisis 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 fitur 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:

Spesifikasi instance baca-saja terlalu kecil
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.
TPS (transaksi per detik) instance utama terlalu tinggi.
Jika TPS instance RDS utama tinggi, optimalkan atau pisahkan transaksi Anda.
Penulisan Transaksi Besar
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.
Waktu eksekusi pernyataan DDL pada instance utama terlalu lama.
- Jika latensi sinkronisasi data pada instance RDS baca-saja disebabkan oleh operasi DDL, kami sarankan Anda melakukan operasi DDL selama jam-jam sepi. 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 saya 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, konfigurasikan ekspansi penyimpanan otomatis, atau tingkatkan spesifikasi secara manual.
- Jika operasi DDL yang disinkronkan dari instance RDS utama diblokir pada instance RDS baca-saja, lakukan langkah-langkah berikut:
  1. Jalankan pernyataan show processlist; pada instance baca-saja dan konfirmasikan bahwa status thread SQL adalah 'waiting for table metadata lock'.
  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.
Kasus khusus
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 melintasi ke detik berikutnya, latensi 1 detik terjadi. Jika titik pengambilan sampel pada beberapa instance RDS baca-saja tidak melintasi 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 melintasi 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 dapat mendiagnosis tiga masalah berikut:
- 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 sangat 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.