PolarDB for MySQL mengintegrasikan kernel database dengan jaringan RDMA untuk menyediakan PolarDB-SCC, yaitu mode kluster konsistensi kuat (SCC). SCC menjamin konsistensi data global sekaligus membatasi penurunan kinerja maksimal 10% dibandingkan dengan konsistensi akhir.
Versi yang Didukung
Untuk mengaktifkan SCC, kluster edisi enterprise PolarDB for MySQL Anda harus memenuhi salah satu persyaratan versi berikut:
Versi engine adalah 8.0.2 dengan revisi versi 8.0.2.2.19 atau lebih baru.
Versi engine adalah 8.0.1 dengan revisi versi 8.0.1.1.29 atau lebih baru.
Versi engine adalah 5.7 dengan revisi versi 5.7.1.0.26 atau lebih baru.
Untuk informasi lebih lanjut tentang cara memeriksa versi kluster, lihat bagian "Query the engine version" pada topik Engine versions.
Catatan Penggunaan
Secara default, SCC diaktifkan untuk semua node read-only pada serverless cluster.
SCC tidak dapat diaktifkan untuk node read-only pada kluster sekunder dalam global database network (GDN).
SCC kompatibel dengan fitur fast query cache. Namun, jika optimisasi modification tracking table (MTT) diaktifkan untuk SCC dan Anda mengaktifkan fitur fast query cache serta SCC secara bersamaan, optimisasi MTT menjadi tidak berlaku.
Solusi Teknis SCC
SCC didasarkan pada PolarTrans, yaitu sistem transaksi berbasis timestamp yang dirancang ulang untuk menggantikan metode manajemen transaksi tradisional berbasis jumlah transaksi aktif di MySQL native. Sistem ini tidak hanya mendukung ekspansi transaksi terdistribusi, tetapi juga secara signifikan meningkatkan kinerja kluster tunggal.
Gambar berikut menunjukkan implementasi SCC. Jaringan RDMA digunakan untuk membangun sinkronisasi informasi primary/secondary yang interaktif dan multidimensi. Pendekatan ini menggantikan arsitektur replikasi log primary/secondary tradisional dengan menggunakan algoritma timestamp Lamport linear untuk mengurangi frekuensi permintaan timestamp oleh node read-only serta mencegah waktu tunggu yang tidak perlu selama replay log.
Timestamp Lamport linear: Untuk mengoptimalkan efisiensi node read-only dalam memperoleh timestamp modifikasi terbaru, digunakan timestamp Lamport linear. Dalam metode tradisional, node read-only perlu meminta timestamp dari node primary setiap kali memproses permintaan, yang menimbulkan overhead signifikan meskipun kecepatan jaringan tinggi. Keunggulan timestamp Lamport linear adalah node read-only dapat menyimpan secara lokal timestamp yang diperoleh dari node primary. Untuk permintaan yang tiba di node read-only lebih awal daripada timestamp yang tersimpan secara lokal, node tersebut dapat langsung menggunakan timestamp lokal tanpa meminta timestamp baru dari node primary. Pendekatan ini secara efektif mengurangi overhead akibat permintaan timestamp yang sering terjadi di bawah beban tinggi serta meningkatkan kinerja node read-only.
Pelacakan modifikasi detail halus bertingkat: Untuk mengoptimalkan kinerja node read-only, tiga tingkat timestamp digunakan pada node primary: timestamp global, timestamp tingkat tabel, dan timestamp tingkat halaman. Saat node read-only memproses permintaan, pertama-tama ia memperoleh timestamp global. Jika timestamp global lebih baru daripada timestamp yang dihasilkan saat node read-only melakukan replay log, node tersebut tidak langsung masuk ke status menunggu. Sebaliknya, node read-only melanjutkan pemeriksaan timestamp tabel dan halaman yang diakses oleh permintaan tersebut. Node read-only hanya akan menunggu hingga replay log selesai jika timestamp tingkat halaman dari permintaan tersebut tidak memenuhi kondisi. Pendekatan ini secara efektif mencegah waktu tunggu yang tidak perlu selama replay log dan meningkatkan kecepatan respons node read-only.
Pengiriman log berbasis RDMA: SCC menggunakan antarmuka RDMA satu sisi (one-sided) untuk mengirimkan log dari node primary ke node read-only, yang secara signifikan meningkatkan kecepatan pengiriman log dan mengurangi overhead CPU akibat proses tersebut.
Timestamp Lamport Linear
Node read-only dapat menggunakan timestamp Lamport linear untuk mengurangi latensi permintaan baca dan konsumsi bandwidth. Saat permintaan tiba di node read-only, jika node tersebut mendeteksi bahwa timestamp telah diperoleh dari node primary untuk permintaan lain, node tersebut langsung menggunakan kembali timestamp tersebut untuk mencegah permintaan timestamp berulang ke node primary, sehingga menjamin konsistensi data kuat sekaligus meningkatkan kinerja.
Pada gambar di atas, dua permintaan baca konkuren r<sub>1</sub> dan r<sub>2</sub> tiba di node read-only. Node read-only mengirim permintaan ke node primary pada t<sub>2</sub> untuk memperoleh timestamp bagi r<sub>2</sub> dan menerima timestamp TS<sup>3</sup><sub>rw</sub> dari node primary pada t<sub>3</sub>. Hubungan antar kejadian tersebut dapat dipahami sebagai: e<sub>2</sub>TS<sup>3 </sup><sub>rw </sub>e<sub>3</sub>. r<sub>1</sub> tiba di node read-only pada t<sub>1</sub>. Dengan memberikan timestamp pada setiap kejadian di node read-only, urutan kejadian tersebut dapat ditentukan. Jika t<sub>1</sub> lebih awal daripada t<sub>2</sub>, maka hubungan kejadiannya menjadi: e<sub>1</sub>e<sub>2</sub>TS<sup>3 </sup><sub>rw </sub>e<sub>3</sub>. Artinya, timestamp yang diperoleh untuk r<sub>2</sub> sudah mencakup semua pembaruan sebelum r<sub>1</sub> tiba di node read-only. Dalam kasus ini, timestamp untuk r<sub>2</sub> dapat langsung digunakan untuk r<sub>1</sub> tanpa perlu meminta timestamp baru. Berdasarkan prinsip ini, setiap kali node read-only memperoleh timestamp dari node primary, node tersebut menyimpannya secara lokal dan mencatat waktu saat timestamp tersebut diperoleh. Jika waktu kedatangan permintaan lebih awal daripada waktu saat timestamp yang disimpan secara lokal diperoleh, timestamp tersebut dapat langsung digunakan untuk permintaan tersebut.
Pelacakan Modifikasi Detail Halus Bertingkat
Untuk menerapkan konsistensi kuat pada pembacaan data, node read-only pertama-tama harus memperoleh timestamp terbaru yang dikomit oleh transaksi saat ini di node primary, melakukan replay log hingga mencapai timestamp tersebut, lalu memproses permintaan baca. Namun, selama replay log, data yang diminta mungkin sudah merupakan data terbaru sehingga node read-only tidak perlu menunggu hingga replay log selesai. Untuk mencegah waktu tunggu yang tidak perlu, SCC menggunakan pelacakan modifikasi yang lebih detail halus. Tiga tingkat informasi modifikasi dipertahankan di node primary: timestamp global, timestamp tingkat tabel, dan timestamp tingkat halaman.
Saat node read-only memproses permintaan baca, pertama-tama ia memperoleh timestamp global untuk memeriksa konsistensi data. Jika timestamp global tidak memenuhi kondisi, node read-only memperoleh timestamp lokal tabel tujuan untuk verifikasi yang lebih detail halus. Jika timestamp tingkat tabel masih tidak memenuhi kondisi, node read-only memperoleh timestamp halaman tujuan untuk verifikasi lebih lanjut. Hanya jika timestamp halaman saat ini lebih baru daripada timestamp saat node read-only melakukan replay log, node tersebut perlu menunggu hingga replay log selesai untuk memastikan data terbaru dibaca.
Untuk mengurangi penggunaan memori, ketiga tingkat timestamp tersebut disimpan dalam tabel hash di memori. Untuk mengoptimalkan penggunaan memori lebih lanjut, timestamp dari beberapa tabel atau halaman dapat dipetakan ke tabel hash yang sama. Untuk menjamin konsistensi, hanya timestamp yang lebih baru yang diperbolehkan menggantikan timestamp yang lebih lama. Desain ini memastikan konsistensi tidak rusak bahkan jika node read-only memperoleh timestamp yang lebih baru. Gambar berikut menunjukkan prinsip tersebut. Pada gambar ini, TID menunjukkan ID tabel dan PID menunjukkan ID halaman. Timestamp yang diperoleh oleh node read-only di-cache secara lokal berdasarkan desain timestamp Lamport linear untuk permintaan lain yang memenuhi syarat.
Pengiriman Log Berbasis RDMA
Dalam SCC, node primary menulis log secara remote ke cache node read-only melalui RDMA satu sisi (one-sided). Proses ini tidak mengonsumsi resource CPU node read-only dan menjamin latensi rendah. Seperti yang ditunjukkan pada gambar berikut, baik node read-only maupun node primary mempertahankan buffer log dengan ukuran yang sama. Thread latar belakang node primary menulis buffer log node primary ke buffer log node read-only melalui RDMA. Node read-only membaca buffer log lokal alih-alih membaca file untuk mempercepat sinkronisasi replikasi.
Untuk informasi lebih lanjut tentang pengiriman log berbasis RDMA, lihat RDMA-based log shipment.
Aktifkan SCC
Masuk ke PolarDB console. Pada halaman Clusters, temukan kluster yang ingin Anda kelola dan klik ID-nya untuk membuka halaman detail kluster. Di bagian Database Connections pada halaman Basic Information, arahkan pointer ke titik akhir tempat Anda ingin mengaktifkan SCC, lalu klik Configure. Untuk informasi lebih lanjut, lihat Configure PolarProxy.
Konsistensi global (mode berkinerja-tinggi) berlaku untuk semua titik akhir kluster setelah diaktifkan. Jika Anda mengaktifkan mode ini untuk satu titik akhir kluster, mode ini akan diaktifkan untuk semua titik akhir lainnya dalam kluster tersebut.
Perbandingan Kinerja
Lingkungan pengujian
Kluster PolarDB for MySQL 8.0 dari Cluster Edition dengan 8 core CPU dan memori 32 GB.
Tool pengujian
Sysbench
Ukuran data pengujian
25 tabel dengan masing-masing 250.000 baris
Hasil pengujian
Kinerja baca dan tulis
Ikhtisar grafik
qps: jumlah permintaan per detik (QPS) dalam hasil pengujian sysbench.
threads: jumlah thread sysbench konkuren yang digunakan dalam pengujian.
RW: QPS pada node primary. Jika node read-only tidak dapat menyediakan operasi baca yang konsisten secara global, semua operasi baca dan tulis dikirim ke node primary.
Konsistensi global: QPS dengan konsistensi global diaktifkan.
SCC: QPS dengan konsistensi akhir dan SCC diaktifkan.
Konsistensi akhir: QPS dengan konsistensi akhir diaktifkan untuk operasi baca dan SCC dinonaktifkan.
Dalam skenario pengujian kinerja baca-tulis antara dua kluster, dibandingkan dengan kluster yang mengaktifkan konsistensi akhir, penurunan kinerja keseluruhan kluster dengan SCC diaktifkan berada dalam batas 10%.
