PostgreSQL adalah proyek yang luar biasa dan berkembang dengan kecepatan yang luar biasa. Kami akan fokus pada evolusi kemampuan toleransi kesalahan di PostgreSQL di seluruh versinya dengan serangkaian posting blog. Ini adalah postingan keempat dari seri ini dan kita akan membicarakan tentang synchronous commit dan pengaruhnya terhadap toleransi kesalahan dan ketergantungan PostgreSQL.
Jika Anda ingin menyaksikan kemajuan evolusi dari awal, silakan periksa tiga posting blog pertama dari seri di bawah ini. Setiap postingan bersifat independen, jadi Anda sebenarnya tidak perlu membaca satu postingan untuk memahami postingan lainnya.
- Evolusi Toleransi Kesalahan di PostgreSQL
- Evolusi Fault Tolerance di PostgreSQL:Fase Replikasi
- Evolusi Toleransi Kesalahan di PostgreSQL:Perjalanan Waktu
Komit Sinkron
Secara default, PostgreSQL mengimplementasikan replikasi asinkron, di mana data dialirkan keluar kapan pun nyaman untuk server. Ini bisa berarti kehilangan data jika terjadi failover. Dimungkinkan untuk meminta Postgres untuk meminta satu (atau lebih) siaga untuk mengakui replikasi data sebelum melakukan, ini disebut replikasi sinkron (komit sinkron ) .
Dengan replikasi sinkron, penundaan replikasi langsung mempengaruhi waktu yang telah berlalu dari transaksi pada master. Dengan replikasi asinkron, master dapat melanjutkan dengan kecepatan penuh.
Replikasi sinkron menjamin bahwa data ditulis ke setidaknya dua node sebelum pengguna atau aplikasi diberitahu bahwa transaksi telah dilakukan.
Pengguna dapat memilih mode komit dari setiap transaksi , sehingga memungkinkan transaksi komit sinkron dan asinkron berjalan secara bersamaan.
Hal ini memungkinkan pertukaran yang fleksibel antara kinerja dan kepastian ketahanan transaksi.
Mengonfigurasi Komitmen Sinkron
Untuk menyiapkan replikasi sinkron di Postgres, kita perlu mengonfigurasi synchronous_commit parameter di postgresql.conf.
Parameter menentukan apakah komit transaksi akan menunggu catatan WAL ditulis ke disk sebelum perintah mengembalikan berhasil indikasi kepada klien. Nilai yang valid adalah aktif , remote_apply , tulis_jarak jauh , lokal , dan nonaktif . Kami akan membahas cara kerja dalam hal replikasi sinkron saat kami menyiapkan synchronous_commit parameter dengan masing-masing nilai yang ditentukan.
Mari kita mulai dengan dokumentasi Postgres (9.6):
Di sini kami memahami konsep komit sinkron, seperti yang kami jelaskan di bagian pengantar posting, Anda bebas mengatur replikasi sinkron tetapi jika tidak, selalu ada risiko kehilangan data. Tetapi tanpa risiko menciptakan inkonsistensi basis data, tidak seperti mematikan fsync off – namun itu adalah topik untuk posting lain -. Terakhir, kami menyimpulkan bahwa jika kami tidak ingin kehilangan data apa pun di antara penundaan replikasi dan ingin memastikan bahwa data ditulis ke setidaknya dua node sebelum pengguna/aplikasi diinformasikan bahwa transaksi telah dilakukan , kita harus menerima kehilangan performa.
Mari kita lihat bagaimana pengaturan yang berbeda bekerja untuk tingkat sinkronisasi yang berbeda. Sebelum kita mulai, mari kita bicara bagaimana komit diproses oleh replikasi PostgreSQL. Klien mengeksekusi kueri pada node master, perubahan ditulis ke log transaksi (WAL) dan disalin melalui jaringan ke WAL pada node siaga. Proses pemulihan pada node siaga kemudian membaca perubahan dari WAL dan menerapkannya ke file data seperti saat pemulihan macet. Jika standby dalam hot standby mode, klien dapat mengeluarkan kueri hanya-baca pada node saat ini terjadi. Untuk detail selengkapnya tentang cara kerja replikasi, Anda dapat melihat entri blog replikasi dalam seri ini.
Gbr.1 Cara kerja replikasi
synchronous_commit =nonaktif
Saat kita menyetel sychronous_commit = off, COMMIT tidak menunggu catatan transaksi di-flush ke disk. Ini disorot pada Gbr.2 di bawah.
Gbr.2 synchronous_commit =nonaktif
synchronous_commit =lokal
Saat kita menyetel synchronous_commit = local, COMMIT menunggu hingga catatan transaksi di-flush ke disk lokal. Ini disorot pada Gbr.3 di bawah.
Gbr.3 synchronous_commit =lokal
synchronous_commit =aktif (default)
Saat kita menyetel synchronous_commit = on, COMMIT akan menunggu hingga server yang ditentukan oleh synchronous_standby_names konfirmasi bahwa catatan transaksi telah ditulis dengan aman ke disk. Ini disorot pada Gbr.4 di bawah.
Catatan: Saat synchronous_standby_names kosong, setelan ini berperilaku sama dengan synchronous_commit = local .
Gbr.4 synchronous_commit =aktif
synchronous_commit =remote_write
Saat kita menyetel synchronous_commit = remote_write, COMMIT akan menunggu hingga server yang ditentukan oleh synchronous_standby_names mengkonfirmasi penulisan catatan transaksi ke sistem operasi tetapi belum tentu mencapai disk. Ini disorot pada Gbr.5 di bawah ini.
Gbr.5 synchronous_commit =remote_write
synchronous_commit =remote_apply
Saat kita menyetel synchronous_commit = remote_apply, COMMIT akan menunggu hingga server yang ditentukan oleh synchronous_standby_names mengkonfirmasi bahwa catatan transaksi telah diterapkan ke database. Ini disorot pada Gbr.6 di bawah ini.
Gbr.6 synchronous_commit =remote_apply
Sekarang, mari kita lihat sychronous_standby_names parameter secara detail, yang dirujuk di atas saat menyetel synchronous_commit sebagai on , remote_apply atau remote_write .
synchronous_standby_names =‘nama_siaga [, …]’
Komit sinkron akan menunggu balasan dari salah satu siaga yang terdaftar dalam urutan prioritas. Ini berarti bahwa jika standby pertama terhubung dan streaming, komit sinkron akan selalu menunggu balasan darinya meskipun standby kedua sudah menjawab. Nilai khusus * dapat digunakan sebagai stanby_name yang akan cocok dengan standby yang terhubung.
synchronous_standby_names =‘num (standby_name [, …])’
Komit sinkron akan menunggu balasan dari setidaknya num jumlah siaga terdaftar dalam urutan prioritas. Aturan yang sama seperti di atas berlaku. Jadi, misalnya pengaturan synchronous_standby_names = '2 (*)' akan membuat komit sinkron menunggu balasan dari 2 server siaga mana pun.
synchronous_standby_names kosong
Jika parameter ini kosong seperti yang ditunjukkan, ia mengubah perilaku pengaturan synchronous_commit ke on , remote_write atau remote_apply berperilaku sama seperti local (yaitu, COMMIT hanya akan menunggu pembilasan ke disk lokal).
Kesimpulan
Dalam posting blog ini, kami membahas replikasi sinkron dan menjelaskan berbagai tingkat perlindungan yang tersedia di Postgres. Kami akan melanjutkan dengan replikasi logis di entri blog berikutnya.
Referensi
Terima kasih khusus kepada rekan saya Petr Jelinek karena telah memberi saya ide untuk ilustrasi.
Dokumentasi PostgreSQL
Buku Masak Administrasi PostgreSQL 9 – Edisi Kedua
