Terjemahan artikel disediakan khusus untuk pelajar kursus tersebut "Pangkalan data". Berminat untuk berkembang ke arah ini? Kami menjemput anda untuk Hari terbuka, di mana kita bercakap secara terperinci tentang program, ciri format dalam talian, kecekapan dan prospek kerjaya yang menanti graduan selepas latihan.

Tetapan ketekalan tulis PostgreSQL dan sambungan khusus
Di Compose, kami berurusan dengan banyak pangkalan data, yang memberi kami peluang untuk menjadi lebih biasa dengan fungsi dan kekurangannya. Sambil kita belajar untuk menyukai ciri pangkalan data baharu, kadangkala kita mula terfikir alangkah baiknya jika ciri serupa terdapat dalam alatan yang lebih matang yang telah kami gunakan untuk sekian lama. Salah satu ciri baharu yang saya ingin lihat dalam PostgreSQL ialah konsistensi penulisan boleh dikonfigurasikan bagi setiap sambungan merentas keseluruhan kluster. Dan ternyata, kami sudah memilikinya, dan hari ini kami ingin berkongsi dengan anda maklumat tentang cara anda boleh menggunakannya.

Mengapa saya memerlukannya?

Bagaimana kluster harus bertindak bergantung pada aplikasi anda. Ambil, sebagai contoh, aplikasi pembayaran bil. Anda memerlukan ketekalan XNUMX% merentas kluster, jadi anda perlu mendayakan komit segerak supaya pangkalan data anda menunggu semua perubahan dibuat. Walau bagaimanapun, jika aplikasi anda adalah rangkaian sosial yang berkembang pesat, maka anda mungkin lebih suka respons pantas berbanding XNUMX% konsisten. Untuk mencapai matlamat ini, anda boleh menggunakan komit tak segerak dalam kelompok anda.

Temui kompromi

Anda perlu membuat pertukaran antara ketekalan data dan prestasi. PostgreSQL beralih daripada konsistensi kerana konfigurasi lalai kemudiannya boleh diramal dan tanpa kejutan yang tidak dijangka. Sekarang mari kita lihat kompromi.

Tradeoff 1: Prestasi

Jika kluster PostgreSQL tidak memerlukan konsistensi, ia boleh dijalankan secara tidak segerak. Tulisan dibuat kepada ketua kluster dan kemas kini akan dihantar ke replikanya beberapa milisaat kemudian. Apabila kluster PostgreSQL memerlukan konsistensi, ia mesti berjalan serentak. Tulisan akan dibuat kepada ketua kluster, yang akan menghantar kemas kini kepada replika dan menunggu pengesahan yang masing-masing telah menulis sebelum menghantar pengesahan kepada pelanggan yang memulakan penulisan bahawa ia berjaya. Perbezaan praktikal antara pendekatan ini ialah kaedah tak segerak memerlukan dua hop rangkaian, manakala kaedah segerak memerlukan empat.

Tradeoff 2: Ketekalan

Keputusan sekiranya berlaku kegagalan pemimpin dalam kedua-dua pendekatan ini juga akan berbeza. Jika kerja dilakukan secara tidak segerak, maka jika ralat sedemikian berlaku, tidak semua rekod akan dilakukan oleh replika. Berapa banyak yang akan hilang? Bergantung pada aplikasi itu sendiri dan kecekapan replikasi. Karang replikasi akan menghalang replika daripada menjadi ketua jika jumlah maklumat di dalamnya adalah 1 MB kurang daripada dalam ketua, iaitu sehingga 1 MB rekod berpotensi hilang semasa operasi tak segerak.

Ini tidak berlaku dalam mod segerak. Jika ketua gagal, semua replika dikemas kini, kerana sebarang tulisan yang disahkan pada pemimpin mesti disahkan pada replika. Ini adalah konsistensi.

Tingkah laku segerak masuk akal dalam aplikasi pengebilan di mana konsistensi mempunyai kelebihan yang jelas dalam pertukaran antara konsistensi dan prestasi. Perkara yang paling penting untuk aplikasi sedemikian adalah data yang sah. Sekarang fikirkan tentang rangkaian sosial di mana tugas utamanya adalah untuk mengekalkan perhatian pengguna dengan membalas permintaan secepat mungkin. Dalam kes ini, prestasi dengan kurang lompatan rangkaian dan kurang menunggu komit akan menjadi keutamaan. Walau bagaimanapun, pertukaran antara prestasi dan konsistensi bukanlah satu-satunya yang perlu anda fikirkan.

Tukar ganti 3: Ranap

Adalah sangat penting untuk memahami bagaimana kluster berkelakuan semasa kegagalan. Pertimbangkan situasi di mana satu atau lebih replika gagal. Apabila komit diproses secara tidak segerak, pemimpin akan terus berfungsi, iaitu menerima dan memproses penulisan, tanpa menunggu replika yang hilang. Apabila replika kembali ke kluster, mereka mengejar ketua. Dengan replikasi segerak, jika replika tidak bertindak balas, maka ketua tidak mempunyai pilihan dan akan terus menunggu pengesahan komit sehingga replika kembali ke kluster dan boleh menerima dan melakukan penulisan.

Satu sambungan setiap transaksi?

Setiap aplikasi memerlukan jenis gabungan konsistensi dan prestasi yang berbeza. Melainkan, sudah tentu, ia adalah apl pembayar bil kami, yang kami bayangkan konsisten sepenuhnya, atau apl rangkaian sosial kami yang hampir tidak lama lagi. Dalam semua kes lain, akan ada kalanya sesetengah operasi mesti segerak dan sesetengahnya mesti tak segerak. Anda mungkin tidak mahu sistem menunggu sehingga mesej yang dihantar ke sembang dilakukan, tetapi jika pembayaran diproses dalam aplikasi yang sama, maka anda perlu menunggu.

Semua keputusan ini, sudah tentu, dibuat oleh pembangun aplikasi. Membuat keputusan yang betul tentang masa untuk menggunakan setiap pendekatan akan membantu anda memanfaatkan kluster anda sepenuhnya. Adalah penting bahawa pembangun boleh bertukar antara mereka di peringkat SQL untuk sambungan dan untuk transaksi.

Memastikan kawalan dalam amalan

Secara lalai, PostgreSQL menyediakan konsistensi. Ini dikawal oleh parameter pelayan synchronous_commit. Secara lalai ia berada dalam kedudukan on, tetapi ia mempunyai tiga pilihan lain: local, remote_write atau off.

Apabila menetapkan parameter kepada off semua komit segerak dihentikan, walaupun pada sistem tempatan. Parameter tempatan menentukan mod segerak untuk sistem tempatan, tetapi menulis kepada replika dilakukan secara tidak segerak. Remote_write pergi lebih jauh: menulis kepada replika dibuat secara tidak segerak, tetapi dikembalikan apabila replika telah menerima tulis tetapi tidak menulisnya ke cakera.

Dengan mempertimbangkan julat pilihan yang tersedia, kami memilih tingkah laku dan, dengan mengingatinya on – ini adalah rakaman segerak, kami akan pilih local untuk komit tak segerak melalui rangkaian, sambil membiarkan komit tempatan segerak.

Sekarang, kami akan memberitahu anda cara untuk menyediakan ini dalam seketika, tetapi bayangkan bahawa kami telah menyediakan synchronous_commit в local untuk pelayan. Kami tertanya-tanya sama ada ia mungkin untuk menukar parameter synchronous_commit dengan cepat, dan ternyata ia bukan sahaja mungkin, malah terdapat dua cara untuk melakukan ini. Yang pertama ialah menetapkan sesi sambungan anda seperti berikut:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

Semua penulisan berikutnya dalam sesi akan mengakui penulisan kepada replika sebelum mengembalikan hasil positif kepada klien yang disambungkan. Melainkan sudah tentu anda menukar tetapan synchronous_commit sekali lagi. Anda boleh meninggalkan sebahagian SESSION dalam arahan kerana ia akan berada dalam nilai lalai.

Kaedah kedua adalah baik apabila anda hanya mahu memastikan anda mendapat replikasi segerak untuk satu transaksi. Dalam kebanyakan pangkalan data penjanaan NoSQL konsep transaksi tidak wujud, tetapi ia wujud dalam PostgreSQL. Dalam kes ini anda memulakan transaksi dan kemudian menetapkan synchronous_commit в on sebelum melaksanakan entri untuk transaksi. COMMIT akan melakukan transaksi menggunakan sebarang nilai parameter synchronous_commit, yang telah ditetapkan pada masa itu, walaupun adalah lebih baik untuk menetapkan pembolehubah terlebih dahulu untuk memastikan pembangun lain memahami bahawa penulisan tidak segerak.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

Semua komitmen transaksi kini akan disahkan sebagai ditulis kepada replika sebelum pangkalan data mengembalikan respons positif kepada pelanggan yang disambungkan.

Menyediakan PostgreSQL

Sebelum ini, kami membayangkan sistem PostgreSQL dengan synchronous_commit, dipasang di local. Untuk menjadikan ini realistik pada bahagian pelayan, anda perlu menetapkan dua pilihan konfigurasi pelayan. Satu lagi parameter synchronous_standby_names akan datang sendiri apabila synchronous_commit akan masuk on. Ia menentukan replika yang layak untuk komit segerak, dan kami akan menetapkannya *, yang bermaksud bahawa semua replika terlibat. Nilai ini biasanya dikonfigurasikan dalam fail konfigurasi dengan menambah:

synchronous_commit = local  
synchronous_standby_names='*'

Dengan menetapkan parameter synchronous_commit menjadi makna local, kami mencipta sistem di mana cakera tempatan kekal segerak, tetapi komit replika rangkaian adalah tidak segerak secara lalai. Melainkan, sudah tentu, kami memutuskan untuk membuat komit ini segerak, seperti yang ditunjukkan di atas.

Jika anda telah mengikuti perkembangan tersebut Projek Gabenor, anda mungkin perasan beberapa perubahan terkini (1, 2), yang membenarkan pengguna Gabenor menguji parameter ini dan memantau ketekalannya.

Beberapa perkataan lagi...

Hanya seminggu yang lalu, saya akan memberitahu anda bahawa adalah mustahil untuk memperhalusi PostgreSQL dengan begitu halus. Ketika itulah Kurt, ahli pasukan platform Compose, menegaskan bahawa peluang sedemikian wujud. Dia menenangkan bantahan saya dan mendapati dalam dokumentasi PostgreSQL yang berikut:

Tetapan ini boleh ditukar pada bila-bila masa. Tingkah laku untuk sebarang transaksi ditentukan oleh tetapan yang berkuat kuasa pada masa komitmen. Oleh itu, adalah mungkin dan berguna untuk sesetengah transaksi dilakukan secara serentak dan untuk yang lain secara tidak segerak. Sebagai contoh, untuk memaksa satu multistatement transaksi untuk membuat komit secara tak segerak apabila nilai lalai parameter adalah bertentangan, tetapkan SET LOCAL synchronous_commit TO OFF dalam sesuatu transaksi.

Dengan pengubahsuaian kecil pada fail konfigurasi ini, kami memberi pengguna kawalan ke atas konsistensi dan prestasi mereka.

Sumber: www.habr.com