PolarDB:Semi-sync berbasis replikasi fisik di PolarDB for MySQL

Latar Belakang

MySQL standar menyediakan replikasi semisinkron berbasis binary log. Dalam mode ini, primary harus menunggu secondary mengonfirmasi bahwa binary log yang dihasilkan oleh suatu transaksi telah diterima sebelum transaksi tersebut dapat dikomit. Metode sinkronisasi ini menimbulkan latensi tambahan dan memengaruhi performa write pada primary.

PolarDB for MySQL menggunakan arsitektur replikasi fisik untuk menyinkronkan redo log antara zona primary dan secondary secara efisien. Pendekatan ini secara signifikan meningkatkan efisiensi replikasi semisinkron dan mengurangi kehilangan performa pada primary. Di bawah beban kerja dengan konkurensi tinggi, degradasi performa hanya sekitar 10% dibandingkan dengan replikasi asinkron.

Dibandingkan dengan replikasi semisinkron berbasis binary log pada MySQL standar, pendekatan berbasis replikasi fisik di PolarDB for MySQL menawarkan efisiensi sinkronisasi yang lebih tinggi. Selama eksekusi transaksi, catatan redo log dihasilkan dan dialirkan ke zona secondary secara real time. Oleh karena itu, saat komit, primary hanya perlu menunggu catatan redo log terkait berhasil disinkronkan ke zona secondary. Sebaliknya, mekanisme semisinkron tradisional berbasis binary log hanya menghasilkan binary log lengkap pada saat komit, dan primary baru dapat mengembalikan pesan sukses ke client setelah seluruh binary log tersebut disinkronkan.

Cara Kerja

Replikasi semisinkron PolarDB for MySQL menggunakan arsitektur replikasi fisik untuk menyinkronkan data antara zona primary dan secondary melalui redo log. Untuk permintaan write, catatan redo log dihasilkan saat data dimodifikasi di zona primary, lalu disinkronkan melalui tautan replikasi fisik. Primary harus menunggu zona secondary mengonfirmasi penerimaan redo log sebelum transaksi write terkait dapat mengembalikan respons sukses.

• Waktu Tunggu Maksimum Sebelum Commit

  Untuk mencegah masalah pada zona sekunder menghambat permintaan tulis di zona primer tanpa batas, kernel membatasi waktu tunggu maksimum sebelum transaksi tulis melakukan commit. Jika zona sekunder tidak mengirimkan konfirmasi dalam periode tersebut, zona primer secara otomatis melakukan commit transaksi tersebut.

• Mekanisme adaptif

  Pada kasus ekstrem, zona secondary mungkin gagal mengirimkan konfirmasi tepat waktu ke zona primary. Hal ini dapat menyebabkan setiap permintaan write menunggu hingga timeout sebelum dikomit, sehingga menurunkan performa. Untuk mencegah masalah ini, semi-sync dilengkapi mekanisme adaptif yang secara dinamis memantau komunikasi jaringan antara zona primary dan secondary. Jika timeout terjadi secara berkala, sistem secara otomatis beralih ke replikasi asinkron guna memastikan write di zona primary tidak terganggu. Ketika sistem mendeteksi bahwa sinkronisasi telah kembali normal, semi-sync akan diaktifkan kembali secara otomatis.

Kesesuaian

Kluster Anda harus memenuhi persyaratan berikut:

• Edisi produk: Enterprise Edition dan Standard Edition

• Versi engine:

  • MySQL 8.0.1:

    • Versi revisi 8.0.1.35.1 atau lebih baru: Semi-sync dapat diaktifkan.

    • Versi revisi 8.0.1.1.40 atau lebih baru: Semi-sync dapat diaktifkan, dan mekanisme adaptif didukung.

    • Versi revisi 8.0.1.1.44.2 atau lebih baru: Semi-sync dapat diaktifkan, dan parameter innodb_polar_wait_slave_reply_max_time tersedia untuk mengatur waktu tunggu maksimum default sebelum transaksi write dikomit. Nilai default-nya adalah 500 ms.

  • MySQL 8.0.2: Versi revisi 8.0.2.2.32 dan lebih baru: Semi-sync dapat diaktifkan, serta mekanisme adaptif dan parameter innodb_polar_wait_slave_reply_max_time juga didukung.

Hal yang Perlu Diperhatikan

RPO dan RTO:

• Dengan replikasi asinkron, alih otomatis lintas zona bersifat lossy. RPO umumnya kurang dari 100 ms dan kurang dari 60 detik dalam skenario terburuk. Evaluasi dampaknya sebelum menggunakan fitur ini.

• Mengaktifkan replikasi semisinkron mengurangi performa sekitar 10%. Waktu tunggu default untuk komit transaksi adalah 500 ms. Jika waktu ini terlampaui, sistem akan beralih ke replikasi asinkron dan tidak lagi menunggu sinkronisasi ke zona secondary. Saat tidak terjadi fallback, RPO bernilai 0.

• RTO kurang dari 30 detik baik untuk replikasi asinkron maupun semisinkron.

Pengujian Performa

Metode pengujian: Pengujian ini membandingkan performa queries per second (QPS) kluster dengan spesifikasi identik dalam tiga mode: PolarDB for MySQL dengan replikasi asinkron, PolarDB for MySQL dengan semi-sync, dan MySQL standar dengan semi-sync.

Tool pengujian: Sysbench (oltp_write_only).

Spesifikasi pengujian: 16-core, 64 GB.

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

Volume data: 10 tabel, masing-masing berisi 10 juta baris.

Hasil menunjukkan bahwa dalam skenario konkurensi tinggi, mengaktifkan replikasi semisinkron mengurangi performa sekitar 10%. Pada semua tingkat konkurensi, performa replikasi semisinkron berbasis redo log di PolarDB for MySQL lebih unggul dibandingkan replikasi semisinkron berbasis binary log di MySQL.

FAQ

Q1: Mengapa performa turun lebih dari 10% setelah saya mengaktifkan semi-sync?

A1: Dalam skenario konkurensi tinggi, penurunan performa terbaik sekitar 10%. Hal ini karena redo log diproses secara batch, yang secara efektif mengurangi overhead akibat latensi jaringan. Dalam skenario konkurensi rendah, manfaat batching kurang signifikan, sehingga penurunan performa bisa lebih parah. Dengan satu thread write, I/O redo tidak dapat dibatch, dan penambahan delay round-trip jaringan akibat mengaktifkan replikasi semisinkron secara signifikan menurunkan performa.

Q2: Mengapa saya tidak melihat parameter innodb_polar_wait_slave_reply_max_time di Konsol? Bagaimana cara menyesuaikannya ke nilai yang sesuai?

A2: Anda hanya dapat mengubah parameter ini pada 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 menemukan parameter tersebut di Konsol, pastikan terlebih dahulu bahwa versi kluster Anda memenuhi persyaratan. Jika tidak, Anda dapat melakukan upgrade versi.

Anda umumnya tidak perlu mengubah parameter ini. Nilai default-nya adalah 500 ms. Jika Anda memiliki kebutuhan khusus—misalnya menjamin bahwa transaksi harus menunggu sinkronisasi ke zona secondary sebelum dikomit—Anda dapat menaikkan nilai ini. Namun, nilai default 500 ms sudah cukup untuk sebagian besar skenario. Jika Anda ingin membatasi waktu tunggu transaksi, Anda dapat menurunkan nilainya. Perhatikan bahwa jika Anda mengatur nilai sangat kecil, seperti 0 atau 1 ms, hal ini dapat menyebabkan mode semi-sync beralih ke replikasi asinkron. Ini karena latensi jaringan antar availability zone biasanya dalam rentang 1 ms, sedangkan replikasi semisinkron memerlukan setidaknya satu round-trip jaringan. Oleh karena itu, pertimbangkan latensi jaringan lingkungan Anda saat mengubah parameter ini.

Q3: Kapan mekanisme adaptif semi-sync mulai berlaku? Apakah saya bisa mengaktifkan semi-sync tetapi menonaktifkan mekanisme adaptif?

A3: Saat ini, ketika Anda mengaktifkan semi-sync, mekanisme adaptif juga diaktifkan secara default. Mekanisme ini secara dinamis memantau status sinkronisasi antara zona primary dan secondary serta melakukan penyesuaian secara real time. Anda tidak dapat menonaktifkan mekanisme adaptif secara terpisah. Jika Anda ingin fitur semi-sync tetap aktif, Anda dapat mengatur parameter innodb_polar_wait_slave_reply_max_time ke nilai yang lebih besar. Mekanisme adaptif menggunakan parameter ini untuk mendeteksi timeout.

Q4: RPO bernilai 0 saat semi-sync tidak mengalami fallback. Apakah "fallback" ini sama dengan saat mekanisme adaptif secara dinamis menonaktifkan semi-sync?

A4: Keduanya merupakan konsep yang berbeda. "Tidak ada fallback" berarti transaksi hanya dikomit setelah redo log-nya berhasil disinkronkan ke zona secondary. Dalam kasus ini, RPO 0 dapat dijamin secara ketat. Namun, mekanisme adaptif memantau pada level paket jaringan, bukan level transaksi. Saat mekanisme adaptif secara dinamis menonaktifkan semi-sync, biasanya karena beberapa transaksi telah dikomit akibat timeout sinkronisasi. Dengan kata lain, meskipun semi-sync diaktifkan dan tidak dinonaktifkan oleh mekanisme adaptif, RPO tidak benar-benar 0. Beberapa transaksi mungkin dikomit akibat timeout sinkronisasi, tetapi kejadian ini jarang terjadi. Oleh karena itu, fitur semi-sync memastikan bahwa RPO mendekati 0.