PolarDB untuk PostgreSQL (Kompatibel dengan Oracle) menyediakan dua tingkat konsistensi — konsistensi sesi dan konsistensi akhir — untuk mengatasi skenario pemisahan baca/tulis di mana latensi replikasi dapat menyebabkan pembacaan data kedaluwarsa. Konsistensi di sini merujuk pada huruf C dalam ACID (atomicity, consistency, isolation, durability).
Cara kerja
PolarDB mereplikasi data dari node primary ke node read-only dengan mentransfer secara asinkron write-ahead logs (WALs). Proksi Polar menangani pemisahan baca/tulis: mengarahkan operasi tulis (INSERT, UPDATE, DELETE, CREATE) ke node primary dan pernyataan SELECT ke node read-only.
Replikasi bersifat asinkron, sehingga node read-only mungkin untuk sementara melayani data yang belum selaras dengan node primary. Latensi ini biasanya hanya beberapa milidetik, tetapi meningkat saat beban tulis tinggi—misalnya, selama operasi DDL yang menambahkan kolom ke tabel besar atau penyisipan data massal. Latensi inilah yang menjadi akar penyebab inkonsistensi data.
Proksi Polar melacak redo log yang diterapkan di setiap node dan mencatat setiap nomor urutan log (LSN). Saat node primary memproses operasi tulis, Proksi Polar mencatat LSN dari tulisan tersebut sebagai session LSN. Untuk pembacaan berikutnya dalam sesi yang sama, Proksi Polar membandingkan session LSN dengan LSN di setiap node yang tersedia dan mengarahkan permintaan ke node yang LSN-nya lebih besar dari atau sama dengan session LSN.
Agar replikasi tetap efisien, PolarDB terus mereplikasi data ke node read-only lainnya sambil node yang dipilih mengembalikan hasil ke klien. Pada saat permintaan baca berikutnya tiba, node-node tersebut umumnya sudah mutakhir. Dalam sebagian besar workload, operasi baca jauh lebih banyak daripada tulis, sehingga pendekatan ini mempertahankan konsistensi sesi sekaligus mendukung pemisahan baca/tulis dan penyeimbangan beban.
Tingkatan secara sekilas
| Tingkat | Perilaku | Gunakan saat |
|---|---|---|
| Konsistensi sesi | Pembacaan dalam satu sesi selalu mencerminkan tulisan yang dilakukan oleh sesi tersebut. Proksi Polar menunggu hingga tersedia node read-only dengan LSN yang cukup mutakhir sebelum mengarahkan permintaan. | Sebagian besar skenario aplikasi—menyeimbangkan konsistensi dengan overhead kinerja minimal. |
| Konsistensi akhir | Pembacaan dapat mengembalikan data dari titik waktu apa pun sebelum tulisan terakhir yang dikomit. Perintah SELECT berbeda dalam sesi yang sama mungkin menghasilkan nilai berbeda tergantung pada latensi replikasi. | Workload yang didominasi baca, di mana pengalihan beban baca ke node read-only lebih penting daripada jaminan konsistensi baca-setelah-tulis. |
Konsistensi sesi
Konsistensi sesi (juga disebut konsistensi kausal) memastikan bahwa data yang ditulis sebelum permintaan baca dalam suatu sesi selalu terlihat dalam respons. Diberikan urutan berikut:
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;Perintah SELECT selalu mengembalikan 100 dalam sesi yang sama, terlepas dari latensi replikasi di node lain.
Konsistensi sesi memberikan tekanan routing yang lebih besar pada kluster dibandingkan konsistensi akhir, tetapi overhead-nya minimal. Tingkat ini memenuhi kebutuhan konsistensi sebagian besar skenario aplikasi dan direkomendasikan sebagai pengaturan default.
Konsistensi akhir
Dalam konsistensi akhir, setiap perintah SELECT diarahkan ke node read-only mana pun yang tersedia, tanpa mempertimbangkan apakah node tersebut telah menerapkan WAL terbaru. Dengan urutan yang sama:
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;Perintah SELECT mungkin mengembalikan 96 atau 100, tergantung pada besarnya latensi replikasi pada saat kueri dieksekusi. Pembacaan berulang dalam sesi yang sama dapat menghasilkan nilai berbeda.
Gunakan konsistensi akhir ketika prioritas utama adalah mengurangi beban pada node primary dan aplikasi Anda dapat mentoleransi ketidakkonsistenan singkat antara baca-setelah-tulis.
Praktik terbaik
Gunakan konsistensi sesi untuk sebagian besar skenario. Tingkat ini memenuhi kebutuhan konsistensi mayoritas aplikasi dengan dampak minimal terhadap kinerja kluster.
Untuk konsistensi lintas-sesi yang ketat, gunakan petunjuk (hint) untuk memaksa kueri tertentu diarahkan ke node primary:
/*FORCE_MASTER*/ select * from user;Petunjuk memiliki prioritas routing tertinggi dan mengesampingkan kedua tingkat konsistensi serta pemisahan transaksi. Evaluasi dampaknya terhadap workload Anda sebelum menggunakannya. Petunjuk tidak boleh berisi pernyataan yang mengubah variabel lingkungan—misalnya, /*FORCE_SLAVE*/ set names utf8; akan menyebabkan error.
Langkah berikutnya
Untuk mengubah tingkat konsistensi kluster Anda, lihat Konfigurasikan Proksi Polar.