PolarDB:Replikasi semisinkron berbasis replikasi fisik di PolarDB for MySQL

Informasi Latar Belakang

Secara default, MySQL mendukung replikasi semisinkron berbasis log biner. Dalam mode ini, transaksi hanya dapat dikomit di database utama setelah database sekunder mengonfirmasi penerimaan dan penyinkronan log biner untuk transaksi tersebut. Namun, sinkronisasi ini menambah latensi yang memengaruhi kinerja penulisan database utama.

PolarDB for MySQL menggunakan arsitektur replikasi fisik untuk menyinkronkan data antara zona utama dan sekunder melalui log redo yang efisien. Pendekatan ini meningkatkan efisiensi replikasi semisinkron dan secara signifikan mengurangi dampaknya terhadap kinerja database utama. Pada beban konkurensi tinggi, replikasi semisinkron berbasis replikasi fisik hanya menurunkan kinerja sekitar 10% dibandingkan dengan replikasi asinkron.

Dibandingkan dengan replikasi semisinkron MySQL berbasis log biner, PolarDB for MySQL replikasi semisinkron berbasis log redo (redo stream) menawarkan efisiensi sinkronisasi lebih tinggi. Selama eksekusi transaksi, log redo dihasilkan dan ditransmisikan ke zona sekunder secara real-time. Transaksi dapat langsung dikomit setelah log redo untuk commit disinkronkan ke zona sekunder. Pada replikasi semisinkron MySQL berbasis log biner, log biner lengkap baru dihasilkan saat transaksi akan dikomit, dan pesan sukses operasi hanya dikembalikan ke klien setelah semua log biner disinkronkan.

Deskripsi Fitur

Logika replikasi semisinkron pada PolarDB for MySQL mudah dipahami. Fitur ini menggunakan arsitektur replikasi fisik untuk menyinkronkan data antara zona utama dan sekunder melalui log redo. Log redo dihasilkan untuk permintaan tulis yang dimodifikasi di zona utama dan disinkronkan ke zona sekunder melalui tautan replikasi fisik. Sebelum zona utama mengomitm transaksi tulis dan mengembalikan pesan sukses ke sistem bisnis, zona utama harus menunggu konfirmasi penerimaan log redo untuk commit dari zona sekunder.

• Waktu tunggu maksimum sebelum commit transaksi

  Permintaan tulis mungkin gagal dikomit di zona utama karena faktor tak terduga dari zona sekunder. Oleh karena itu, waktu tunggu maksimum sebelum commit transaksi ditentukan di lapisan kernel. Jika zona utama tidak menerima konfirmasi dari zona sekunder dalam waktu yang ditentukan, transaksi tulis akan timeout dan zona utama secara otomatis mengomitm transaksi tersebut.

• Mekanisme adaptif

  Dalam kasus ekstrem, zona sekunder mungkin tidak dapat mengonfirmasi informasi sinkronisasi dengan zona utama pada kesempatan pertama. Akibatnya, zona utama mengomitm setiap permintaan tulis setelah periode timeout, yang menyebabkan penurunan kinerja. Untuk mencegah masalah ini, PolarDB for MySQL mengimplementasikan mekanisme adaptif untuk replikasi semisinkron. Sistem memantau konektivitas jaringan antara zona utama dan sekunder, dan secara otomatis beralih ke replikasi asinkron jika timeout sering terjadi. Ini memastikan bahwa permintaan tulis di zona utama tidak terpengaruh oleh replikasi semisinkron dalam kasus ekstrem. Sistem juga secara otomatis beralih kembali ke replikasi semisinkron ketika konektivitas jaringan pulih.

Catatan Penggunaan

• Hanya kluster PolarDB for MySQL Enterprise Edition dengan versi utama 8.0.1 dan versi revisi 8.0.1.35.1 atau lebih baru yang mendukung replikasi semisinkron lintas zona.

  • Kluster PolarDB for MySQL Enterprise Edition dengan versi utama 8.0.1 dan versi revisi 8.0.1.1.40 atau lebih baru mendukung mekanisme adaptif untuk replikasi semisinkron.

  • Kluster PolarDB for MySQL Enterprise Edition dengan versi utama 8.0.1 dan versi revisi 8.0.1.1.44.2 atau lebih baru mendukung parameter innodb_polar_wait_slave_reply_max_time. Anda dapat mengonfigurasi parameter ini untuk menentukan waktu tunggu maksimum sebelum commit transaksi tulis di zona utama setelah replikasi semisinkron diaktifkan. Nilai default parameter ini adalah 500 ms.

• Recovery Point Objective (RPO) dan Recovery Time Objective (RTO)

  • Dalam replikasi asinkron, alih otomatis lintas zona menyebabkan kerugian. Dalam kebanyakan kasus, RPO kurang dari 100 ms. Dalam kasus terburuk, RPO kurang dari 60 detik. Evaluasi dampak pada bisnis Anda sebelum menggunakan fitur ini.

  • Dalam replikasi semisinkron, kinerja kluster berkurang sekitar 10% setelah Anda mengaktifkan fitur alih otomatis lintas zona. Secara default, waktu tunggu sebelum commit transaksi adalah 500 ms. Jika waktu tunggu melebihi 500 ms, mode replikasi kembali ke replikasi asinkron. RPO adalah 0 jika tidak ada fallback.

  • Dalam replikasi asinkron dan semisinkron, RTO kurang dari 30 detik.

Hasil Pengujian Kinerja

Metode pengujian: Bandingkan kinerja permintaan per detik (QPS) kluster PolarDB for MySQL yang menggunakan replikasi asinkron, PolarDB for MySQL replikasi semisinkron, dan replikasi semisinkron MySQL. Kluster memiliki spesifikasi yang sama.

Alat pengujian: mode oltp_write_only Sysbench

Spesifikasi kluster: 16 core 64 GB

Versi yang diuji: PolarDB for MySQL 8.0.1 dengan versi revisi 8.0.1.35.1, yang mungkin sedikit berbeda dari versi terbaru

Volume data: 10 tabel data, 10 juta baris data per tabel

Dalam skenario konkurensi tinggi, penurunan kinerja sekitar 10% setelah replikasi semisinkron diaktifkan. Kinerja replikasi semisinkron PolarDB for MySQL berbasis log redo lebih tinggi daripada replikasi semisinkron MySQL berbasis log biner.

FAQ

P1: Mengapa kinerja menurun lebih dari 10% setelah replikasi semisinkron diaktifkan?

A1: Dalam skenario konkurensi tinggi, penurunan kinerja optimal adalah sekitar 10%. Hal ini karena beberapa log redo diproses dalam batch, yang secara efektif mengurangi overhead yang disebabkan oleh latensi jaringan. Dalam skenario konkurensi rendah, manfaat pemrosesan batch tidak terlihat jelas, sehingga kinerja mungkin menurun secara signifikan. Pemrosesan redo I/O tidak dapat dilakukan dalam batch jika hanya satu thread digunakan untuk menulis data. Setelah replikasi semisinkron diaktifkan, latensi perjalanan bolak-balik jaringan sangat menurunkan kinerja.

P2: Mengapa parameter innodb_polar_wait_slave_reply_max_time tidak ditampilkan di konsol? Bagaimana cara menyesuaikan parameter ini ke nilai yang tepat?

A2: Parameter ini hanya tersedia untuk kluster PolarDB for MySQL Enterprise Edition dengan versi utama 8.0.1 dan versi revisi 8.0.1.1.44.2 atau lebih baru. Jika Anda tidak dapat menemukan parameter di konsol, periksa apakah versi kluster memenuhi persyaratan. Jika tidak, perbarui versi kluster. Untuk informasi lebih lanjut, lihat Versi Revisi Manajemen Versi.

Secara umum, Anda tidak perlu secara manual memodifikasi parameter ini. Nilai defaultnya adalah 500 ms. Jika Anda memiliki persyaratan khusus, Anda dapat menyesuaikan parameter ini. Misalnya, jika Anda ingin menunggu hingga informasi relevan disinkronkan ke zona sekunder sebelum mengomitm transaksi, Anda dapat meningkatkan nilai parameter ini. Nilai default 500 ms sesuai untuk sebagian besar kasus. Jika Anda ingin membatasi waktu tunggu sebelum commit transaksi, Anda dapat mengatur parameter ini ke nilai yang lebih kecil. Secara umum, latensi jaringan antara zona utama dan sekunder berada dalam 1 ms. Dalam replikasi semisinkron, sistem harus menunggu setidaknya satu perjalanan bolak-balik jaringan. Jika parameter ini diatur ke nilai kecil, seperti 0 atau 1 ms, sistem mungkin beralih dari replikasi semisinkron ke replikasi asinkron. Oleh karena itu, Anda harus mempertimbangkan situasi aktual saat memodifikasi parameter ini.

P3: Kapan mekanisme adaptif replikasi semisinkron mulai berlaku? Bisakah saya mengaktifkan replikasi semisinkron tetapi menonaktifkan mekanisme adaptif?

A3: Setelah replikasi semisinkron diaktifkan, mekanisme adaptif secara otomatis mulai berlaku. Sistem secara otomatis memantau status sinkronisasi zona utama dan sekunder dan menyesuaikan mode replikasi secara real-time. Mekanisme adaptif tidak dapat dinonaktifkan secara terpisah. Jika Anda ingin menjaga agar replikasi semisinkron tetap efektif, atur parameter innodb_polar_wait_slave_reply_max_time ke nilai besar. Mekanisme adaptif menentukan status timeout berdasarkan nilai parameter.

P4: RPO adalah 0 jika fallback tidak terjadi. Apakah fallback berarti penonaktifan dinamis replikasi semisinkron oleh mekanisme adaptif?

A4: Tidak, fallback dan penonaktifan dinamis replikasi semisinkron oleh mekanisme adaptif tidak sama. Jika fallback tidak terjadi, informasi redo harus disinkronkan ke zona sekunder sebelum transaksi apa pun dapat dikomit. Dalam hal ini, nilai RPO 0 dapat dijamin. Namun, mekanisme adaptif tidak memantau transaksi tetapi komunikasi paket jaringan. Jika mekanisme adaptif menonaktifkan replikasi semisinkron, beberapa transaksi mungkin telah dikomit dalam kasus timeout sinkronisasi. Dengan kata lain, RPO mungkin tidak 0 meskipun replikasi semisinkron tidak dinonaktifkan oleh mekanisme adaptif. Ada kemungkinan rendah bahwa beberapa transaksi mungkin dikomit dalam kasus timeout sinkronisasi. Fitur replikasi semisinkron memastikan bahwa RPO mendekati 0 secara tak terbatas.