Dalam ceramahnya, Andrey Borodin akan memberitahu anda bagaimana mereka mengambil kira pengalaman penskalaan PgBouncer semasa mereka bentuk pengumpul sambungan , bagaimana mereka melancarkannya dalam pengeluaran. Di samping itu, kami akan membincangkan fungsi pengumpul yang kami ingin lihat dalam versi baharu: adalah penting bagi kami bukan sahaja untuk menampung keperluan kami, tetapi untuk membangunkan komuniti pengguna .
Video:
Hai semua! Nama saya Andrew.
Di Yandex, saya sedang membangunkan pangkalan data sumber terbuka. Dan hari ini kita mempunyai topik mengenai sambungan pengumpul sambungan.
Jika anda tahu cara memanggil pengumpul sambungan dalam bahasa Rusia, beritahu saya. Saya benar-benar ingin mencari istilah teknikal yang baik yang harus diwujudkan dalam literatur teknikal.
Topik ini agak rumit, kerana dalam banyak pangkalan data pengumpul sambungan terbina dalam dan anda tidak perlu tahu mengenainya. Sesetengah tetapan, sudah tentu, ada di mana-mana, tetapi dalam Postgres ini tidak berfungsi. Dan selari (di HighLoad++ 2019) terdapat laporan oleh Nikolai Samokhvalov tentang menyediakan pertanyaan dalam Postgres. Dan saya faham bahawa orang telah datang ke sini yang telah mengkonfigurasi permintaan dengan sempurna, dan mereka ini adalah orang yang berhadapan dengan masalah sistem yang lebih jarang berkaitan dengan rangkaian, penggunaan sumber. Dan di beberapa tempat ia boleh menjadi agak sukar dalam erti kata bahawa masalahnya tidak jelas.
Yandex mempunyai Postgres. Banyak perkhidmatan Yandex hidup di Yandex.Cloud. Dan kami mempunyai beberapa petabait data yang menjana sekurang-kurangnya satu juta permintaan sesaat dalam Postgres.
Dan kami menyediakan kluster yang agak tipikal untuk semua perkhidmatan - ini adalah nod utama utama nod, dua replika biasa (segerak dan tak segerak), sandaran, penskalaan permintaan bacaan pada replika.
Setiap nod kluster ialah Postgres, di mana, sebagai tambahan kepada Postgres dan sistem pemantauan, pengumpul sambungan juga dipasang. Pengumpul sambungan digunakan untuk pagar dan untuk tujuan utamanya.
Apakah tujuan utama pengumpul sambungan?
Postgres menggunakan model proses untuk bekerja dengan pangkalan data. Ini bermakna satu sambungan adalah satu proses, satu bahagian belakang Postgres. Dan terdapat banyak cache berbeza dalam bahagian belakang ini, yang agak mahal untuk dibuat berbeza untuk sambungan yang berbeza.
Juga, terdapat tatasusunan dalam kod Postgres yang dipanggil procArray. Ia mengandungi data asas tentang sambungan rangkaian. Dan hampir semua algoritma pemprosesan procArray mempunyai kerumitan linear, ia dijalankan melalui keseluruhan rangkaian sambungan rangkaian. Ia adalah kitaran yang agak pantas, tetapi dengan lebih banyak sambungan rangkaian masuk, keadaan menjadi lebih mahal. Dan apabila keadaan menjadi lebih mahal, anda akhirnya membayar harga yang sangat tinggi untuk sejumlah besar sambungan rangkaian.
Terdapat 3 pendekatan yang mungkin:
- Di bahagian aplikasi.
- Di bahagian pangkalan data.
- Dan antara, iaitu, semua kombinasi yang mungkin.
Malangnya, pooler terbina dalam sedang dibangunkan. Rakan-rakan di PostgreSQL Professional melakukan ini kebanyakannya. Bila ia akan muncul sukar untuk diramalkan. Dan sebenarnya, kami mempunyai dua penyelesaian untuk pilihan arkitek. Ini ialah kumpulan sisi aplikasi dan kumpulan proksi.
Kolam sebelah aplikasi adalah cara paling mudah. Dan hampir semua pemacu pelanggan memberi anda cara: untuk mewakili berjuta-juta sambungan anda dalam kod sebagai beberapa berpuluh-puluh sambungan ke pangkalan data.
Terdapat masalah dengan fakta bahawa pada satu ketika anda ingin menskala bahagian belakang, anda ingin menggunakan ia ke banyak mesin maya.
Kemudian anda masih menyedari bahawa anda mempunyai beberapa lagi zon ketersediaan, beberapa pusat data. Dan pendekatan pengumpulan sisi pelanggan membawa kepada jumlah yang besar. Yang besar adalah kira-kira 10 sambungan. Ini adalah kelebihan yang boleh berfungsi dengan baik.
Jika kita bercakap tentang pengumpul proksi, maka terdapat dua pengumpul yang boleh melakukan banyak perkara. Mereka bukan sahaja pengumpul. Mereka adalah pengumpul + fungsi yang lebih hebat. ini ΠΈ .
Tetapi, malangnya, tidak semua orang memerlukan fungsi tambahan ini. Dan ini membawa kepada fakta bahawa pengumpul hanya menyokong pengumpulan sesi, iaitu satu pelanggan masuk, satu pelanggan keluar ke pangkalan data.
Ini tidak begitu sesuai untuk tugas kami, jadi kami menggunakan PgBouncer, yang melaksanakan pengumpulan transaksi, iaitu sambungan pelayan dipetakan kepada sambungan pelanggan hanya untuk tempoh transaksi.
Dan pada beban kami - ia adalah benar. Tetapi terdapat beberapa masalah.
Masalah bermula apabila anda ingin mendiagnosis sesi, kerana semua sambungan masuk adalah setempat. Semua orang datang dengan loopback dan entah bagaimana ia menjadi sukar untuk mengesan sesi.
Sudah tentu anda boleh menggunakan application_name_add_host. Ini ialah cara sampingan Bouncer untuk menambah alamat IP pada application_name. Tetapi application_name ditetapkan oleh sambungan tambahan.
Pada carta ini, garis kuning adalah permintaan sebenar dan garis biru adalah permintaan yang terbang ke pangkalan data. Dan perbezaan ini adalah tepat tetapan nama_aplikasi, yang hanya diperlukan untuk mengesan, tetapi ia tidak sama sekali percuma.
Selain itu, Bouncer tidak boleh mengehadkan satu kumpulan, iaitu bilangan sambungan pangkalan data bagi setiap pengguna, bagi setiap pangkalan data.
Ini membawa kepada apa? Anda mempunyai perkhidmatan dimuatkan yang ditulis dalam C ++ dan di suatu tempat berdekatan perkhidmatan kecil pada nod yang tidak melakukan kesalahan dengan pangkalan, tetapi pemandunya menjadi gila. Ia membuka 20 sambungan dan segala-galanya akan menunggu. Malah kod anda adalah betul.
Sudah tentu, kami menulis tampung kecil untuk Bouncer yang menambahkan tetapan ini, iaitu mengehadkan pelanggan kepada kumpulan.
Ia mungkin untuk melakukan ini di sebelah Postgres, iaitu mengehadkan peranan dalam pangkalan data kepada bilangan sambungan.
Tetapi kemudian anda kehilangan keupayaan untuk memahami mengapa anda tidak mempunyai sambungan ke pelayan. PgBouncer tidak membuang ralat sambungan, ia sentiasa mengembalikan maklumat yang sama. Dan anda tidak boleh faham: mungkin kata laluan anda telah berubah, mungkin pangkalan data baru sahaja turun, mungkin ada sesuatu yang salah. Tetapi tiada diagnosis. Jika sesi tidak dapat ditubuhkan, anda tidak akan tahu mengapa ia tidak boleh dilakukan.
Pada satu ketika, anda melihat graf aplikasi dan melihat bahawa aplikasi itu tidak berfungsi.
Lihat bahagian atas dan lihat bahawa Bouncer adalah satu benang. Ini adalah titik perubahan dalam kehidupan perkhidmatan. Anda faham bahawa anda sedang bersedia untuk menskalakan pangkalan data dalam masa satu setengah tahun, dan anda perlu menskalakan pengumpul.
Kami telah membuat kesimpulan bahawa kami memerlukan lebih banyak PgBouncers.
Bouncer telah ditampal sedikit.
Dan mereka membuatnya supaya beberapa Bouncer boleh dinaikkan dengan penggunaan semula port TCP. Dan sistem pengendalian secara automatik memindahkan sambungan TCP masuk antara mereka dengan round-robin'om.
Ini adalah telus kepada pelanggan, iaitu nampaknya anda mempunyai satu Bouncer, tetapi anda mempunyai pemecahan sambungan terbiar antara menjalankan Bouncer.
Dan pada satu ketika, anda mungkin perasan bahawa 3 Bouncer ini masing-masing memakan inti mereka sebanyak 100%. Anda memerlukan beberapa Bouncer. kenapa?
Kerana anda mempunyai TLS. Anda mempunyai sambungan yang disulitkan. Dan jika anda menanda aras Postgres dengan dan tanpa TLS, anda akan mendapati bahawa bilangan sambungan yang telah ditetapkan menurun sebanyak hampir dua urutan magnitud dengan penyulitan didayakan, kerana jabat tangan TLS menggunakan sumber CPU.
Dan di bahagian atas, anda boleh melihat beberapa fungsi kriptografi yang dilaksanakan semasa gelombang sambungan masuk. Memandangkan utama kami boleh bertukar antara zon ketersediaan, gelombang sambungan masuk adalah situasi yang agak tipikal. Iaitu, atas sebab tertentu, primer lama tidak tersedia, keseluruhan beban telah dihantar ke pusat data lain. Mereka semua akan datang untuk bertanya khabar kepada TLS pada masa yang sama.
Dan sebilangan besar jabat tangan TLS mungkin belum menyambut Bouncer, tetapi memerah tekaknya. Gelombang sambungan masuk mungkin tidak terendam disebabkan oleh tamat masa. Jika anda mencuba semula ke pangkalan tanpa mundur eksponen, mereka tidak akan kembali berulang kali dalam gelombang yang koheren.
Berikut ialah contoh 16 PgBouncers yang memuatkan 16 teras pada 100%.
Kami telah tiba di PgBouncer yang melata. Ini ialah konfigurasi terbaik yang boleh kami capai pada beban Bouncer kami. Bouncer luaran kami berfungsi untuk jabat tangan TCP, dan Bouncer dalaman berfungsi untuk pengumpulan sebenar, agar tidak memecah-belah sambungan luaran dengan banyak.
Dalam konfigurasi ini, mula semula lembut boleh dilakukan. Anda boleh memulakan semula semua 18 Bouncer ini satu demi satu. Tetapi mengekalkan konfigurasi sedemikian agak sukar. Pentadbir sistem, DevOps, dan orang yang benar-benar bertanggungjawab untuk pelayan ini tidak akan gembira dengan skim ini.
Nampaknya semua penambahbaikan kami boleh dipromosikan dalam sumber terbuka, tetapi Bouncer tidak menyokong dengan baik. Sebagai contoh, keupayaan untuk menjalankan berbilang PgBouncers pada port yang sama telah dilakukan sebulan yang lalu. Permintaan tarik dengan ciri ini adalah beberapa tahun yang lalu.
Atau satu lagi contoh. Dalam Postgres, anda boleh membatalkan permintaan yang sedang berjalan dengan menghantar rahsia ke sambungan lain tanpa pengesahan tambahan. Tetapi sesetengah pelanggan hanya menghantar TCP-set, iaitu mereka memutuskan sambungan rangkaian. Apakah yang akan dilakukan oleh Bouncer dengan ini? Dia takkan buat apa-apa. Ia akan terus melaksanakan permintaan itu. Jika anda telah menerima sejumlah besar sambungan yang telah meletakkan asas dengan permintaan kecil, maka hanya memutuskan sambungan daripada Bouncer tidak akan mencukupi, anda juga perlu melengkapkan permintaan tersebut yang berjalan dalam pangkalan data.
Ini telah ditambal dan isu itu masih belum digabungkan ke hulu Bouncer.
Jadi kami sampai pada kesimpulan bahawa kami memerlukan penyambung sambungan kami sendiri, yang akan dibangunkan, ditampal, di mana ia akan menjadi mungkin untuk menyelesaikan masalah dengan cepat dan yang, tentu saja, mesti berbilang benang.
Kami menetapkan multithreading sebagai tugas utama. Kita perlu dapat mengendalikan gelombang sambungan TLS yang masuk dengan baik.
Untuk melakukan ini, kami perlu membangunkan perpustakaan berasingan yang dipanggil Machinarium, yang direka untuk menerangkan keadaan mesin sambungan rangkaian sebagai kod bersiri. Jika anda melihat kod sumber libpq, anda akan melihat panggilan yang agak rumit yang boleh mengembalikan hasil kepada anda dan berkata, "Hubungi saya sebentar lagi. Sekarang saya mempunyai IO buat masa ini, tetapi apabila IO berlalu, saya mempunyai beban pada pemproses. Dan ini adalah skim pelbagai peringkat. Interaksi rangkaian biasanya diterangkan oleh mesin keadaan. Banyak peraturan seperti "Jika sebelum ini saya menerima pengepala paket saiz N, maka sekarang saya sedang menunggu N bait", "Jika saya menghantar paket SYNC, maka sekarang saya sedang menunggu paket dengan metadata hasil." Ternyata kod balas intuitif yang agak sukar, seolah-olah maze telah ditukar menjadi imbasan garisan. Kami membuatnya supaya bukannya mesin keadaan, pengaturcara menerangkan laluan interaksi utama dalam bentuk kod imperatif biasa. Hanya dalam kod imperatif ini, anda perlu memasukkan tempat di mana urutan pelaksanaan perlu diganggu dengan menunggu data daripada rangkaian, menghantar konteks pelaksanaan kepada coroutine lain (benang hijau). Pendekatan ini serupa dengan fakta bahawa kita menulis laluan yang paling dijangka dalam mez berturut-turut, dan kemudian menambah cawangan kepadanya.
Akibatnya, kami mempunyai satu urutan yang membuat TCP menerima dan round-robin menghantar sambungan TPC kepada ramai pekerja.
Dalam kes ini, setiap sambungan pelanggan sentiasa berjalan pada satu pemproses. Dan ini membolehkan anda menjadikannya mesra cache.
Selain itu, kami telah menambah baik sedikit pengumpulan paket kecil ke dalam satu paket besar untuk memunggah susunan TCP sistem.
Selain itu, kami telah menambah baik pengumpulan transaksi dalam erti kata bahawa Odyssey, apabila dikonfigurasikan, boleh menghantar BATAL dan BALIK sekiranya berlaku kegagalan sambungan rangkaian, iaitu jika tiada sesiapa menunggu permintaan itu, Odyssey akan memberitahu pangkalan data untuk tidak cuba memenuhi permintaan yang boleh membazirkan sumber yang berharga.
Dan apabila boleh, kami mengekalkan sambungan kepada pelanggan yang sama. Ini mengelakkan daripada memasang semula application_name_add_host. Jika boleh, maka kami tidak mempunyai tetapan semula tambahan bagi parameter yang diperlukan untuk diagnostik.
Kami bekerja untuk kepentingan Yandex.Cloud. Dan jika anda menggunakan PostgreSQL terurus dan anda memasang penyambung sambungan, anda boleh membuat replikasi logik ke luar, iaitu tinggalkan kami jika anda mahu, menggunakan replikasi logik. Bouncer di luar aliran replikasi logik tidak akan memberi.
Ini adalah contoh menyediakan replikasi logik.
Di samping itu, kami mempunyai sokongan untuk replikasi fizikal ke luar. Di Cloud, tentu saja, adalah mustahil, kerana kluster itu akan memberi anda terlalu banyak maklumat tentang dirinya. Tetapi dalam pemasangan anda, jika anda memerlukan replikasi fizikal melalui pengumpul sambungan dalam Odyssey, ia boleh dilakukan.
Odyssey mempunyai pemantauan yang serasi sepenuhnya dengan PgBouncer. Kami mempunyai konsol yang sama yang melaksanakan hampir semua arahan yang sama. Jika ada sesuatu yang hilang, hantar permintaan tarik atau sekurang-kurangnya isu pada GitHub, kami akan melengkapkan arahan yang diperlukan. Tetapi kami sudah mempunyai fungsi utama konsol PgBouncer.
Dan sudah tentu kami mempunyai ralat pemajuan. Kami akan mengembalikan ralat yang dilaporkan oleh pangkalan. Anda akan mendapat maklumat mengapa anda tidak berada di pangkalan, bukan hanya kerana anda tidak berada di dalamnya.
Ciri ini dilumpuhkan sekiranya anda memerlukan keserasian 100% dengan PgBouncer. Kita boleh berkelakuan seperti Bouncer, untuk berjaga-jaga.
Pembangunan
Beberapa perkataan tentang kod sumber Odyssey.
Sebagai contoh, terdapat arahan "Jeda / Sambung semula". Mereka biasanya digunakan untuk mengemas kini pangkalan data. Jika anda perlu menaik taraf Postgres, anda boleh menjedanya dalam pengumpul sambungan, lakukan pg_upgrade, kemudian sambung semula. Dan dari sisi pelanggan, ia akan kelihatan seperti pangkalan data hanya perlahan. Fungsi ini dibawakan kepada kami oleh orang daripada komuniti. Dia belum mati, tetapi tidak lama lagi semuanya akan berlaku. (sudah mati)
- sudah mati
Selain itu, salah satu ciri baharu dalam PgBouncer ialah sokongan Pengesahan SCRAM, yang turut dibawakan kepada kami oleh seseorang yang tidak bekerja dalam Yandex.Cloud. Kedua-duanya adalah fungsi yang kompleks dan penting.
Oleh itu, saya ingin memberitahu anda tentang apa Odyssey dibuat, sekiranya anda juga ingin menulis beberapa kod sekarang.
Anda mempunyai pangkalan Odyssey asal, yang bergantung pada dua perpustakaan utama. Pustaka Kiwi ialah pelaksanaan protokol mesej Postgres. Maksudnya, proto 3 asli Postgres ialah mesej standard yang boleh bertukar-tukar bahagian hadapan dan hujung belakang. Ia dilaksanakan di perpustakaan Kiwi.
Perpustakaan Machinarium ialah perpustakaan pelaksanaan benang. Serpihan kecil Machinarium ini ditulis dalam pemasang. Tapi jangan risau, ada 15 baris sahaja.
Seni bina Odyssey. Terdapat mesin utama yang menjalankan coroutine. Mesin ini melaksanakan penerimaan sambungan TCP masuk dan pengedaran di kalangan pekerja.
Dalam satu pekerja, pengendali untuk beberapa pelanggan boleh bekerja. Dan juga dalam utas utama, konsol dan pemprosesan tugas crone untuk mengalih keluar sambungan yang tidak lagi diperlukan dalam kolam berputar.
Odyssey diuji menggunakan suite ujian Postgres standard. Kami hanya menjalankan semakan pemasangan melalui Bouncer dan melalui Odyssey, kami mendapat div nol. Terdapat beberapa ujian yang berkaitan dengan pemformatan tarikh yang gagal sama dalam Bouncer dan Odyssey.
Di samping itu, terdapat banyak pemandu yang mempunyai ujian mereka sendiri. Dan kami menggunakan ujian mereka untuk menguji Odyssey.
Selain itu, disebabkan konfigurasi lata kami, kami perlu menguji pelbagai berkas: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey untuk memastikan bahawa jika Odyssey berada dalam mana-mana bahagian dalam lata, ia juga masih berfungsi seperti yang diharapkan .
Rake
Kami menggunakan Odyssey dalam pengeluaran. Dan tidak adil jika saya mengatakan bahawa semuanya berfungsi. Tidak, iaitu ya, tetapi tidak selalu. Sebagai contoh, dalam pengeluaran semuanya hanya berfungsi, kemudian rakan-rakan kami dari PostgreSQL Professional datang dan mengatakan bahawa kami mengalami kebocoran memori. Mereka benar-benar, kami membetulkannya. Tetapi ia adalah mudah.
Kemudian kami mendapati bahawa pengumpul sambungan mempunyai sambungan TLS masuk dan sambungan TLS keluar. Dan sambungan memerlukan sijil pelanggan dan sijil pelayan.
Sijil pelayan Bouncer dan Odyssey dibaca semula oleh pcache, tetapi sijil pelanggan tidak perlu dibaca semula daripada pcache, kerana Odyssey berskala kami akhirnya bergantung pada prestasi sistem membaca sijil ini. Ini mengejutkan kami, kerana dia tidak segera berehat. Pada mulanya, ia berskala secara linear, dan selepas 20 sambungan serentak masuk, masalah ini nyata.
Kaedah Pengesahan Boleh Palam ialah keupayaan untuk mengesahkan dengan alat lunux terbina dalam. Dalam PgBouncer, ia dilaksanakan sedemikian rupa sehingga terdapat utas berasingan menunggu respons daripada PAM dan terdapat utas PgBouncer utama yang menyediakan sambungan semasa dan boleh meminta mereka untuk hidup dalam utas PAM.
Kami tidak melaksanakan ini untuk satu sebab mudah. Kami mempunyai banyak aliran. Mengapa kita memerlukannya?
Akibatnya, ini boleh menimbulkan masalah kerana jika anda mempunyai pengesahan PAM dan pengesahan bukan PAM, maka gelombang besar pengesahan PAM boleh melambatkan pengesahan bukan PAM dengan ketara. Ia adalah salah satu perkara yang belum kami selesaikan. Tetapi jika anda ingin memperbaikinya, anda boleh melakukan ini.
Satu lagi rake adalah dengan fakta bahawa kami mempunyai satu benang yang menerima semua sambungan masuk. Dan kemudian mereka dipindahkan ke kumpulan pekerja, di mana jabat tangan TLS akan berlaku.
Akibatnya, jika anda mempunyai gelombang koheren 20 sambungan rangkaian, semuanya akan diterima. Dan di sisi pelanggan, libpq akan mula melaporkan tamat masa. Secara lalai, ia seperti 000 saat di sana.
Jika mereka semua tidak boleh memasuki pangkalan pada masa yang sama, maka mereka tidak boleh memasuki pangkalan, kerana semua ini boleh dilindungi oleh percubaan semula bukan eksponen.
Kami akhirnya menyalin skema PgBouncer di sini supaya kami telah mengecilkan bilangan sambungan TCP yang kami terima.
Jika kami melihat bahawa kami menerima sambungan, tetapi mereka tidak mempunyai masa untuk berjabat tangan pada akhirnya, kami meletakkannya dalam baris gilir supaya mereka tidak menggunakan sumber CPU. Ini membawa kepada fakta bahawa jabat tangan serentak mungkin tidak dilakukan untuk semua sambungan yang telah tiba. Tetapi sekurang-kurangnya seseorang akan memasuki pangkalan data, walaupun bebannya cukup kuat.
Roadmap
Apakah yang anda ingin lihat pada masa hadapan di Odyssey? Apakah yang kita bersedia untuk memajukan diri dan apa yang kita harapkan daripada masyarakat?
Untuk Ogos 2019.
Inilah rupa peta jalan Odyssey pada bulan Ogos:
- Kami mahukan pengesahan SCRAM dan PAM.
- Kami mahu memajukan permintaan baca kepada siap sedia.
- Saya ingin semula dalam talian.
- Dan keupayaan untuk berhenti seketika pada pelayan.
Separuh daripada peta jalan ini dilakukan, dan bukan oleh kami. Dan ini bagus. Jadi mari kita bincangkan apa yang tinggal dan tambah lagi.
? Kami mempunyai replika yang, tanpa memenuhi permintaan, hanya akan memanaskan udara. Kami memerlukan mereka untuk menyediakan failover dan switchover. Sekiranya terdapat masalah di salah satu pusat data, saya ingin menyibukkannya dengan beberapa kerja yang berguna. Kerana kita tidak boleh mengkonfigurasi pemproses pusat yang sama, memori yang sama dengan cara yang berbeza, kerana replikasi tidak akan berfungsi sebaliknya.
Pada dasarnya, dalam Postgres, bermula dari 10, adalah mungkin untuk menentukan session_attrs apabila menyambung. Anda boleh menyenaraikan semua hos pangkalan data dalam sambungan dan sebut sebab anda pergi ke pangkalan data: tulis atau baca sahaja. Dan pemandu itu sendiri akan memilih hos pertama dalam senarai yang paling disukainya, yang memenuhi keperluan session_attrs.
Tetapi masalah dengan pendekatan ini ialah ia tidak mengawal lag replikasi. Anda mungkin mempunyai sejenis replika yang tertinggal oleh masa yang tidak boleh diterima untuk perkhidmatan anda. Untuk membuat pelaksanaan berciri penuh permintaan baca pada replika, sebenarnya, kami perlu menyokong dalam Odyssey keupayaan untuk tidak berfungsi apabila ia adalah mustahil untuk dibaca.
Odyssey perlu pergi ke pangkalan data dari semasa ke semasa dan meminta jarak replikasi dari asas. Dan jika ia telah mencapai had, jangan biarkan permintaan baharu ke dalam pangkalan data, beritahu pelanggan bahawa anda perlu memulakan semula sambungan dan, mungkin, pilih hos lain untuk melaksanakan permintaan. Ini akan membolehkan pangkalan data memulihkan lag replikasi dengan cepat dan kembali semula untuk membalas dengan pertanyaan.
Sukar untuk menamakan tarikh pelaksanaan, kerana ia adalah sumber terbuka. Tetapi, saya harap, bukan 2,5 tahun seperti rakan sekerja dari PgBouncer. Inilah ciri yang saya ingin lihat dalam Odyssey.
. Kini anda boleh membuat pernyataan yang disediakan dalam dua cara. Pertama, anda boleh melaksanakan arahan SQL, iaitu "disediakan". Untuk memahami arahan SQL ini, kita perlu belajar cara memahami SQL pada bahagian Bouncer. Ini akan menjadi berlebihan kerana ia berlebihan kerana kita memerlukan keseluruhan parser. Kami tidak boleh menghuraikan setiap arahan SQL.
Tetapi terdapat kenyataan yang disediakan di peringkat protokol mesej pada proto3. Dan ini adalah tempat apabila maklumat bahawa pernyataan yang disediakan sedang dibuat datang dalam bentuk berstruktur. Dan kami boleh menyokong pemahaman bahawa pada beberapa sambungan pelayan pelanggan meminta untuk membuat kenyataan yang disediakan. Dan walaupun transaksi ditutup, kami masih perlu memastikan pelayan dan pelanggan disambungkan.
Tetapi di sini percanggahan timbul dalam dialog, kerana seseorang mengatakan bahawa anda perlu memahami pernyataan yang disediakan oleh pelanggan dan berkongsi sambungan pelayan antara semua pelanggan yang mencipta sambungan pelayan ini, iaitu, yang mencipta kenyataan yang disediakan sedemikian.
Andres Freund berkata bahawa jika pelanggan datang kepada anda yang telah mencipta kenyataan yang disediakan sedemikian dalam sambungan pelayan lain, kemudian buat untuknya. Tetapi nampaknya agak salah untuk melaksanakan pertanyaan dalam pangkalan data dan bukannya klien, tetapi dari sudut pandangan pemaju yang menulis protokol untuk berinteraksi dengan pangkalan data, adalah mudah jika dia hanya diberi sambungan rangkaian. yang mempunyai permintaan yang disediakan sedemikian.
Dan satu lagi ciri yang perlu kita laksanakan. Kami kini mempunyai pemantauan yang serasi dengan PgBouncer. Kami boleh mengembalikan purata masa pelaksanaan pertanyaan. Tetapi masa purata ialah suhu purata di hospital: seseorang sejuk, seseorang panas - secara purata semua orang sihat. Ianya tidak betul.
Kami perlu melaksanakan sokongan untuk persentil, yang akan menunjukkan bahawa terdapat permintaan perlahan yang menggunakan sumber dan akan menjadikan pemantauan lebih boleh diterima.
Perkara yang paling penting ialah saya mahu versi 1.0 (Versi 1.1 telah pun dikeluarkan). Hakikatnya kini Odyssey berada dalam versi 1.0rc, iaitu calon keluaran. Dan semua rake yang saya senaraikan telah diperbaiki dengan versi yang sama, kecuali kebocoran memori.
Apakah maksud versi 1.0 untuk kita? Kami sedang melancarkan Odyssey ke pangkalan kami. Ia sudah berjalan pada pangkalan data kami, tetapi apabila ia mencapai tahap 1 permintaan sesaat, maka kita boleh mengatakan bahawa ini adalah versi keluaran dan ini adalah versi yang boleh dipanggil 000.
Beberapa orang dalam komuniti telah meminta lebih banyak jeda dan SCRAM dalam versi 1.0. Tetapi ini bermakna kami perlu melancarkan versi seterusnya kepada pengeluaran, kerana SCRAM mahupun jeda belum digabungkan lagi. Tetapi, kemungkinan besar, isu ini akan diselesaikan dengan cepat.
Saya menunggu permintaan tarik awak. Dan saya juga ingin mendengar masalah yang anda hadapi dengan Bouncer. Mari kita bincangkan mereka. Mungkin kami boleh melaksanakan beberapa fungsi yang anda perlukan.
Ini menyimpulkan bahagian saya, saya ingin mendengar daripada anda. Terima kasih!
soalan
Jika saya meletakkan nama_aplikasi saya sendiri, adakah ia akan dilemparkan dengan betul, termasuk dalam pengumpulan transaksi dalam Odyssey?
Odyssey atau Bouncer?
Dalam Odyssey. Bouncer dilemparkan.
Kami akan membuat satu set.
Dan jika sambungan sebenar saya melompat ke atas sambungan lain, adakah ia akan dihantar?
Kami akan membuat satu set semua parameter yang disenaraikan. Saya tidak dapat mengetahui sama ada application_name ada dalam senarai ini. Nampaknya dia ternampak dia di situ. Kami akan menetapkan semua parameter yang sama. Dengan satu permintaan, set akan melakukan semua yang telah dipasang oleh pelanggan semasa permulaan.
Terima kasih Andrey atas laporan itu! Laporan yang bagus! Saya gembira kerana Odyssey berkembang lebih pantas dan lebih pantas setiap minit. Saya ingin meneruskan perkara yang sama. Kami telah meminta anda untuk mempunyai sambungan berbilang sumber data supaya Odyssey boleh menyambung ke pangkalan data yang berbeza pada masa yang sama, iaitu tuan hamba, dan kemudian menyambung secara automatik kepada tuan baharu selepas failover.
Ya, saya nampaknya masih ingat perbincangan itu. Kini terdapat beberapa storan. Tetapi tidak ada pertukaran antara mereka. Di pihak kami, kami mesti menanyakan pelayan bahawa ia masih hidup dan memahami bahawa failover telah berlaku, yang akan memanggil pg_recovery. Saya mempunyai cara standard untuk memahami bahawa kami tidak datang kepada tuan. Dan kita mesti faham entah bagaimana dari kesilapan atau bagaimana? Iaitu, idea itu menarik, ia sedang dibincangkan. Tulis lebih banyak komen. Jika anda mempunyai tangan kerja yang tahu C, maka ini secara amnya bagus.
Isu penskalaan merentas replika juga menarik minat kami, kerana kami ingin menjadikan penggunaan kluster yang direplikasi semudah mungkin untuk pembangun aplikasi. Tetapi di sini saya ingin lebih banyak komen, iaitu, bagaimana untuk melakukannya, bagaimana untuk melakukannya dengan baik.
Soalannya juga mengenai replika. Ternyata anda mempunyai tuan dan beberapa replika. Dan jelas bahawa mereka pergi ke replika kurang kerap daripada kepada tuan untuk sambungan, kerana mereka mungkin mempunyai perbezaan. Anda mengatakan bahawa perbezaan dalam data mungkin sedemikian rupa sehingga perniagaan anda tidak akan memuaskan dan anda tidak akan pergi ke sana sehingga ia direplikasi. Pada masa yang sama, jika anda tidak pergi ke sana untuk masa yang lama, dan kemudian mula pergi, maka data yang anda perlukan tidak akan tersedia dengan serta-merta. Iaitu, jika kita sentiasa pergi ke master, maka cache dipanaskan di sana, dan cache berada di belakang sedikit dalam replika.
Ya memang benar. Tidak akan ada blok data dalam pcache yang anda inginkan, dalam cache sebenar tidak akan ada maklumat tentang jadual yang anda inginkan, tidak akan ada pertanyaan yang dihuraikan dalam rancangan, tiada apa-apa sama sekali.
Dan apabila anda mempunyai beberapa jenis kluster, dan anda menambah replika baharu di sana, maka semasa ia bermula, semuanya buruk di dalamnya, iaitu ia menumbuhkan cachenya.
Saya mendapat idea. Pendekatan yang betul ialah menjalankan peratusan kecil pertanyaan pada replika terlebih dahulu, yang akan memanaskan cache. Secara kasar, kita mempunyai syarat bahawa kita mesti berada tidak lebih daripada 10 saat di belakang tuan. Dan syarat ini tidak sepatutnya dimasukkan dalam satu gelombang, tetapi lancar untuk sesetengah pelanggan.
Ya, tambah berat badan.
Ini adalah idea yang baik. Tetapi pertama-tama anda perlu melaksanakan penutupan ini. Mula-mula kita perlu mematikan, dan kemudian kita akan memikirkan cara untuk menghidupkan. Ini adalah ciri yang hebat untuk dihidupkan dengan lancar.
nginx mempunyai pilihan ini slowly start dalam kelompok untuk pelayan. Dan dia secara beransur-ansur membina beban.
Ya, idea yang bagus, kami akan mencubanya apabila kami mencapainya.
Sumber: www.habr.com