Saat pemisahan baca/tulis mengarahkan pernyataan SELECT ke node read-only, node tersebut mungkin tertinggal dari node primary akibat replikasi asinkron. PolarDB for PostgreSQL menyediakan dua tingkat konsistensi—konsistensi akhir dan konsistensi sesi (juga dikenal sebagai konsistensi baca tingkat transaksi)—untuk mengontrol cara aplikasi Anda menangani celah replikasi ini.
Cara kerja
PolarDB berjalan dalam arsitektur kluster. Setiap kluster terdiri dari satu node primary dan satu atau lebih node read-only. Anda dapat terhubung ke kluster melalui dua jenis titik akhir:
Cluster endpoint (disarankan): mengarahkan lalu lintas ke semua node dan mengaktifkan pemisahan baca/tulis secara otomatis.
Primary endpoint: mengarahkan seluruh lalu lintas hanya ke node primary.
Lapisan proxy bawaan menangani pemisahan baca/tulis dengan mengurai setiap pernyataan SQL, lalu mengarahkan operasi tulis (INSERT, UPDATE, DELETE, CREATE) ke node primary dan operasi baca (SELECT) ke node read-only.
Replikasi data dari node primary ke node read-only menggunakan replikasi fisik asinkron berbasis write-ahead logging (WAL). Di bawah beban normal, replikasi selesai dalam beberapa milidetik. Di bawah beban ringan, latensi sinkronisasi dapat mencapai kurang dari lima detik. Namun, di bawah beban berat—seperti operasi DDL pada tabel besar atau penyisipan massal—latensi sinkronisasi dapat meningkat secara signifikan.
Karena replikasi bersifat asinkron, pernyataan SELECT yang diarahkan ke node read-only mungkin mengembalikan data yang belum mencerminkan tulisan terbaru di node primary. Dua tingkat konsistensi ini menentukan cara PolarDB menangani celah tersebut.
Tingkat konsistensi
| Eventual consistency | Session consistency | |
|---|---|---|
| Perilaku baca | SELECT diarahkan ke node read-only yang tersedia tanpa menunggu replikasi selesai. | SELECT diteruskan ke node read-only yang telah menyelesaikan replikasi untuk tulisan dalam sesi saat ini. |
| Bacaan usang | Mungkin terjadi—node tersebut mungkin belum memiliki data terbaru. | Tidak mungkin terjadi dalam satu sesi—pembacaan selalu mencerminkan tulisan dari sesi yang sama. |
| Kinerja | Throughput sedikit lebih tinggi; tidak ada waktu tunggu. | Overhead minimal pada sebagian besar beban kerja. |
| Paling cocok untuk | Analitik, pelaporan, dan beban kerja dominan baca di mana jeda replikasi singkat dapat diterima. | Beban kerja transaksional di mana pembacaan harus mencerminkan tulisan terbaru dari sesi yang sama. |
Eventual consistency
Dengan eventual consistency, proxy mengarahkan setiap pernyataan SELECT ke node read-only yang tersedia tanpa memeriksa apakah node tersebut telah menerima data terbaru. Node tersebut langsung mengembalikan hasil.
Artinya, pembacaan yang mengikuti penulisan dalam sesi yang sama mungkin mengembalikan data usang:
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;
-- Mungkin mengembalikan 96 atau NULL jika node read-only belum mereplikasi tulisan tersebutGunakan eventual consistency untuk beban kerja di mana jeda replikasi singkat dapat diterima, seperti pekerjaan terjadwal, kueri analitik, laporan agregat, atau akses read-only oleh pengguna yang tidak melakukan penulisan data.
Session consistency
Dengan session consistency, proxy memastikan bahwa setelah terjadi penulisan dalam suatu sesi, pembacaan berikutnya dalam sesi yang sama hanya diarahkan ke node read-only yang telah menerapkan tulisan tersebut. Pernyataan SELECT diteruskan ke node yang memenuhi syarat dan mengembalikan hasil terkini.
Contoh yang sama akan berperilaku secara prediktabel:
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;
-- Mengembalikan 100, dijaminSession consistency menambahkan overhead minimal pada sebagian besar beban kerja dan mencakup sebagian besar kasus penggunaan transaksional. Gunakan ini sebagai nilai default untuk aplikasi di mana pengguna membaca tulisan terbarunya sendiri.
Cara kerja session consistency
Proxy melacak progres log redo pada setiap node menggunakan nomor urutan log (LSN). Saat sebuah tulisan dikomit di node primary, proxy mencatat LSN dari tulisan tersebut sebagai LSN sesi.
Ketika permintaan baca berikutnya tiba dalam sesi yang sama, proxy membandingkan LSN sesi dengan LSN setiap node read-only. Permintaan baca diteruskan ke node yang LSN-nya lebih besar dari atau sama dengan LSN sesi, sehingga menjamin bahwa node tersebut telah menerapkan tulisan tersebut. Selagi node yang dipilih mengirimkan hasil ke klien, node lain terus mereplikasi di latar belakang.
Mekanisme ini memberikan konsistensi sesi, pemisahan baca/tulis, dan load balancing secara bersamaan.
Praktik terbaik
Gunakan session consistency untuk sebagian besar beban kerja. Dampaknya terhadap kinerja kluster minimal dan menangani kasus umum di mana aplikasi membaca data yang baru saja ditulisnya.
Untuk kueri yang harus membaca data terkini mutlak—terlepas dari batasan sesi—arahkan kueri tersebut ke node primary menggunakan petunjuk FORCE_MASTER:
/*FORCE_MASTER*/ select * from user;Batasi penggunaan FORCE_MASTER hanya untuk kueri tertentu, bukan digunakan secara luas. Mengarahkan seluruh pembacaan ke node primary menghilangkan manfaat pemisahan baca/tulis dan meningkatkan beban pada node primary.