Dalam ceramahnya, Andrey Borodin akan memberi tahu Anda bagaimana mereka memperhitungkan pengalaman penskalaan PgBouncer saat merancang kumpulan koneksi , bagaimana mereka meluncurkannya dalam produksi. Selain itu, kami akan membahas fungsi pooler apa yang ingin kami lihat di versi baru: penting bagi kami tidak hanya untuk memenuhi kebutuhan kami, tetapi juga untuk mengembangkan komunitas pengguna .
Video:
Halo semua! Nama saya Andrew.
Di Yandex, saya sedang mengembangkan database sumber terbuka. Dan hari ini kita memiliki topik tentang koneksi pooler koneksi.
Jika Anda tahu cara memanggil pooler koneksi dalam bahasa Rusia, beri tahu saya. Saya benar-benar ingin menemukan istilah teknis yang bagus yang harus ditetapkan dalam literatur teknis.
Topiknya cukup rumit, karena di banyak database, kumpulan koneksi sudah terpasang dan Anda bahkan tidak perlu mengetahuinya. Beberapa pengaturan, tentu saja, ada di mana-mana, tetapi di Postgres ini tidak berfungsi. Dan secara paralel (di HighLoad++ 2019) ada laporan dari Nikolai Samokhvalov tentang menyiapkan kueri di Postgres. Dan saya mengerti bahwa orang-orang datang ke sini yang telah mengonfigurasi permintaan dengan sempurna, dan ini adalah orang-orang yang menghadapi masalah sistem yang lebih jarang terkait dengan jaringan, pemanfaatan sumber daya. Dan di beberapa tempat bisa sangat sulit dalam artian masalahnya tidak jelas.
Yandex memiliki Postgres. Banyak layanan Yandex tinggal di Yandex.Cloud. Dan kami memiliki beberapa petabyte data yang menghasilkan setidaknya satu juta permintaan per detik di Postgres.
Dan kami menyediakan cluster yang cukup tipikal untuk semua layanan - ini adalah node utama utama dari node, dua replika biasa (sinkron dan asinkron), cadangan, penskalaan permintaan membaca pada replika.
Setiap node cluster adalah Postgres, di mana, selain Postgres dan sistem pemantauan, kumpulan koneksi juga dipasang. Pooler koneksi digunakan untuk pagar dan untuk tujuan utamanya.
Apa tujuan utama dari pooler koneksi?
Postgres mengadopsi model proses untuk bekerja dengan database. Ini berarti bahwa satu koneksi adalah satu proses, satu backend Postgres. Dan ada banyak cache berbeda di backend ini, yang cukup mahal untuk dibuat berbeda untuk koneksi yang berbeda.
Juga, ada sebuah array dalam kode Postgres yang disebut procArray. Ini berisi data dasar tentang koneksi jaringan. Dan hampir semua algoritma pemrosesan procArray memiliki kompleksitas linier, mereka berjalan melalui seluruh rangkaian koneksi jaringan. Ini siklus yang cukup cepat, tetapi dengan lebih banyak koneksi jaringan yang masuk, semuanya menjadi sedikit lebih mahal. Dan ketika segalanya menjadi sedikit lebih mahal, Anda akhirnya membayar harga yang sangat tinggi untuk sejumlah besar koneksi jaringan.
Ada 3 pendekatan yang mungkin:
- Di sisi aplikasi.
- Di sisi basis data.
- Dan di antara, yaitu, semua kemungkinan kombinasi.
Sayangnya, pooler bawaan saat ini sedang dalam pengembangan. Teman-teman di PostgreSQL Professional kebanyakan melakukan ini. Kapan akan muncul sulit diprediksi. Dan nyatanya, kami memiliki dua solusi untuk pemilihan seorang arsitek. Ini adalah kumpulan sisi aplikasi dan kumpulan proxy.
Kumpulan sisi aplikasi adalah cara termudah. Dan hampir semua driver klien memberi Anda cara: untuk merepresentasikan jutaan koneksi Anda dalam kode sebagai lusinan koneksi ke database.
Ada masalah dengan fakta bahwa pada titik tertentu Anda ingin menskalakan backend, Anda ingin menerapkannya ke banyak mesin virtual.
Kemudian Anda masih menyadari bahwa Anda memiliki beberapa zona ketersediaan lagi, beberapa pusat data. Dan pendekatan penyatuan sisi klien menghasilkan angka yang besar. Yang besar sekitar 10 sambungan. Ini adalah keunggulan yang dapat bekerja dengan baik.
Jika kita berbicara tentang kumpulan proxy, maka ada dua kumpulan yang dapat melakukan banyak hal. Mereka bukan hanya pooler. Mereka adalah kumpulan + fungsionalitas yang lebih keren. Ini ΠΈ .
Namun sayangnya, tidak semua orang membutuhkan fungsi tambahan ini. Dan itu mengarah pada fakta bahwa pooler hanya mendukung pengumpulan sesi, mis. satu klien masuk, satu klien keluar ke database.
Ini sangat tidak cocok untuk tugas kami, jadi kami menggunakan PgBouncer, yang mengimplementasikan penggabungan transaksi, yaitu koneksi server dipetakan ke koneksi klien hanya selama durasi transaksi.
Dan pada beban kami - itu benar. Tetapi ada beberapa masalah.
Masalah dimulai saat Anda ingin mendiagnosis suatu sesi, karena semua koneksi masuk bersifat lokal. Semua orang datang dengan loopback dan entah bagaimana menjadi sulit untuk melacak sesi.
Tentu saja Anda dapat menggunakan application_name_add_host. Ini adalah cara sisi Bouncer untuk menambahkan alamat IP ke application_name. Tapi application_name diatur oleh koneksi tambahan.
Pada grafik ini, di mana garis kuning adalah permintaan nyata, dan di mana garis biru adalah permintaan yang masuk ke database. Dan perbedaan ini justru pada setting application_name, yang hanya dibutuhkan untuk tracing, tapi sama sekali tidak gratis.
Selain itu, Bouncer tidak dapat membatasi satu kumpulan, yaitu jumlah koneksi basis data per pengguna, per basis data.
Apa yang menyebabkan hal ini? Anda memiliki layanan dimuat yang ditulis dalam C ++ dan di suatu tempat di dekatnya ada layanan kecil di node yang tidak melakukan kesalahan dengan basisnya, tetapi drivernya menjadi gila. Ini membuka 20 koneksi dan yang lainnya akan menunggu. Bahkan kode Anda sudah benar.
Tentu saja, kami menulis tambalan kecil untuk Bouncer yang menambahkan pengaturan ini, yaitu membatasi klien ke kumpulan.
Dimungkinkan untuk melakukan ini di sisi Postgres, yaitu membatasi peran dalam database ke jumlah koneksi.
Tetapi kemudian Anda kehilangan kemampuan untuk memahami mengapa Anda tidak memiliki koneksi ke server. PgBouncer tidak membuang kesalahan koneksi, selalu mengembalikan informasi yang sama. Dan Anda tidak dapat mengerti: mungkin kata sandi Anda telah berubah, mungkin databasenya baru saja turun, mungkin ada yang salah. Tapi tidak ada diagnosa. Jika sesi tidak dapat dibuat, Anda tidak akan tahu mengapa sesi tersebut tidak dapat dilakukan.
Pada titik tertentu, Anda melihat grafik aplikasi dan melihat bahwa aplikasi tersebut tidak berfungsi.
Lihat di atas dan lihat bahwa Bouncer adalah single-threaded. Ini adalah titik balik dalam kehidupan pelayanan. Anda memahami bahwa Anda sedang bersiap untuk menskalakan database dalam satu setengah tahun, dan Anda perlu menskalakan pooler.
Kami sampai pada kesimpulan bahwa kami membutuhkan lebih banyak PgBouncer.
Bouncer telah sedikit ditambal.
Dan mereka membuatnya sehingga beberapa Penjaga dapat dinaikkan dengan penggunaan kembali port TCP. Dan sistem operasi sudah secara otomatis mentransfer koneksi TCP yang masuk di antara mereka secara round-robin'om.
Ini transparan untuk klien, yaitu sepertinya Anda memiliki satu Bouncer, tetapi Anda memiliki fragmentasi koneksi menganggur antara menjalankan Bouncer.
Dan pada titik tertentu, Anda mungkin memperhatikan bahwa 3 Penjaga ini masing-masing memakan intinya sebesar 100%. Anda membutuhkan beberapa Bouncer. Mengapa?
Karena Anda memiliki TLS. Anda memiliki koneksi terenkripsi. Dan jika Anda membandingkan Postgres dengan dan tanpa TLS, Anda akan menemukan bahwa jumlah koneksi yang dibuat turun hampir dua kali lipat dengan enkripsi diaktifkan, karena jabat tangan TLS menghabiskan sumber daya CPU.
Dan di bagian atas, Anda dapat melihat beberapa fungsi kriptografi yang dijalankan selama gelombang koneksi masuk. Karena primer kami dapat beralih di antara zona ketersediaan, gelombang koneksi masuk adalah situasi yang cukup umum. Artinya, karena alasan tertentu, primer lama tidak tersedia, seluruh muatan dikirim ke pusat data lain. Mereka semua akan datang untuk menyapa TLS pada saat yang bersamaan.
Dan sejumlah besar jabat tangan TLS mungkin belum menyapa Bouncer, tetapi meremas tenggorokannya. Gelombang koneksi yang masuk mungkin menjadi tidak teredam karena waktu habis. Jika Anda memiliki percobaan ulang ke pangkalan tanpa kemunduran eksponensial, mereka tidak akan kembali lagi dan lagi dalam gelombang yang koheren.
Berikut adalah contoh 16 PgBouncer yang memuat 16 inti pada 100%.
Kami telah tiba di PgBouncer yang mengalir. Ini adalah konfigurasi terbaik yang dapat kami capai pada muatan Bouncer kami. Bouncer eksternal kami berfungsi untuk jabat tangan TCP, dan Bouncer internal berfungsi untuk penyatuan nyata, agar tidak terlalu memecah koneksi eksternal.
Dalam konfigurasi ini, soft restart dimungkinkan. Anda dapat memulai ulang semua 18 Penjaga ini satu per satu. Tetapi mempertahankan konfigurasi seperti itu cukup sulit. Administrator sistem, DevOps, dan orang-orang yang benar-benar bertanggung jawab atas server ini tidak akan senang dengan skema ini.
Tampaknya semua peningkatan kami dapat dipromosikan dalam sumber terbuka, tetapi Bouncer tidak mendukung dengan baik. Misalnya, kemampuan untuk menjalankan beberapa PgBouncer pada port yang sama dilakukan sebulan yang lalu. Permintaan tarik dengan fitur ini beberapa tahun yang lalu.
Atau satu contoh lagi. Di Postgres, Anda dapat membatalkan permintaan yang sedang berjalan dengan mengirimkan rahasia ke koneksi lain tanpa otentikasi tambahan. Tetapi beberapa klien hanya mengirim reset TCP, mis. mereka memutuskan koneksi jaringan. Apa yang akan dilakukan Bouncer dengan ini? Dia tidak akan melakukan apapun. Itu akan terus mengeksekusi permintaan. Jika Anda telah menerima sejumlah besar koneksi yang telah meletakkan basis dengan permintaan kecil, maka memutuskan koneksi dari Bouncer saja tidak akan cukup, Anda masih harus menyelesaikan permintaan yang berjalan di database.
Ini telah ditambal dan masalahnya masih belum digabungkan ke upstream Bouncer.
Jadi kami sampai pada kesimpulan bahwa kami memerlukan kumpulan koneksi kami sendiri, yang akan dikembangkan, ditambal, yang memungkinkan untuk memperbaiki masalah dengan cepat dan yang, tentu saja, harus multi-utas.
Kami menetapkan multithreading sebagai tugas utama. Kita harus bisa menangani gelombang koneksi TLS yang masuk dengan baik.
Untuk melakukan ini, kami harus mengembangkan perpustakaan terpisah yang disebut Machinarium, yang dirancang untuk mendeskripsikan status mesin dari koneksi jaringan sebagai kode serial. Jika Anda melihat kode sumber libpq, Anda akan melihat panggilan yang cukup rumit yang dapat memberikan hasil kepada Anda dan berkata, "Telepon saya nanti. Saat ini saya memiliki IO untuk saat ini, tetapi ketika IO lewat, saya memiliki beban pada prosesor. Dan ini adalah skema multi-level. Interaksi jaringan biasanya dijelaskan oleh mesin negara. Banyak aturan seperti "Jika sebelumnya saya menerima header paket ukuran N, maka sekarang saya sedang menunggu N byte", "Jika saya mengirim paket SYNC, maka sekarang saya sedang menunggu paket dengan metadata hasil." Ternyata kode kontra-intuitif yang agak sulit, seolah-olah labirin diubah menjadi pemindaian garis. Kami membuatnya sehingga alih-alih mesin negara, programmer menggambarkan jalur interaksi utama dalam bentuk kode imperatif biasa. Hanya dalam kode penting ini, Anda perlu memasukkan tempat-tempat di mana urutan eksekusi perlu diinterupsi dengan menunggu data dari jaringan, meneruskan konteks eksekusi ke coroutine lain (utas hijau). Pendekatan ini mirip dengan fakta bahwa kami menuliskan jalur yang paling diharapkan di labirin secara berurutan, lalu menambahkan cabang ke sana.
Hasilnya, kami memiliki satu utas yang membuat TCP menerima dan round-robin meneruskan koneksi TPC ke banyak pekerja.
Dalam hal ini, setiap koneksi klien selalu berjalan pada satu prosesor. Dan ini memungkinkan Anda membuatnya ramah-cache.
Selain itu, kami telah sedikit meningkatkan pengumpulan paket kecil menjadi satu paket besar untuk membongkar tumpukan sistem TCP.
Selain itu, kami telah meningkatkan pooling transaksional dalam arti bahwa Odyssey, ketika dikonfigurasi, dapat mengirim CANCEL dan ROLLBACK jika terjadi kegagalan koneksi jaringan, yaitu jika tidak ada yang menunggu permintaan, Odyssey akan memberi tahu database untuk tidak mencoba memenuhi permintaan yang dapat menghabiskan sumber daya berharga.
Dan jika memungkinkan, kami menjaga koneksi ke klien yang sama. Ini menghindari keharusan menginstal ulang application_name_add_host. Jika memungkinkan, kami tidak memiliki reset tambahan dari parameter yang diperlukan untuk diagnostik.
Kami bekerja untuk kepentingan Yandex.Cloud. Dan jika Anda menggunakan PostgreSQL terkelola dan Anda memiliki penyatuan koneksi terinstal, Anda dapat membuat replikasi logis ke luar, yaitu tinggalkan kami jika Anda mau, menggunakan replikasi logis. Bouncer di luar aliran replikasi logis tidak akan memberikan.
Ini adalah contoh pengaturan replikasi logis.
Selain itu, kami memiliki dukungan untuk replikasi fisik ke luar. Di Cloud, tentu saja, tidak mungkin, karena cluster akan memberi Anda terlalu banyak informasi tentang dirinya sendiri. Namun dalam instalasi Anda, jika Anda memerlukan replikasi fisik melalui penyatuan koneksi di Odyssey, itu mungkin.
Odyssey memiliki pemantauan yang sepenuhnya kompatibel dengan PgBouncer. Kami memiliki konsol yang sama yang menjalankan hampir semua perintah yang sama. Jika ada yang kurang, kirim permintaan penarikan, atau setidaknya ada masalah di GitHub, kami akan menyelesaikan perintah yang diperlukan. Tapi kami sudah memiliki fungsi utama dari konsol PgBouncer.
Dan tentu saja kami memiliki penerusan kesalahan. Kami akan mengembalikan kesalahan yang dilaporkan oleh pangkalan. Anda akan mendapatkan informasi mengapa Anda tidak berada di pangkalan, bukan hanya karena Anda tidak berada di dalamnya.
Fitur ini dinonaktifkan jika Anda memerlukan kompatibilitas 100% dengan PgBouncer. Kita bisa bersikap seperti Bouncer, untuk berjaga-jaga.
Pembangunan
Beberapa kata tentang kode sumber Odyssey.
Misalnya, ada perintah "Pause / Resume". Mereka biasanya digunakan untuk memperbarui database. Jika Anda perlu memutakhirkan Postgres, Anda dapat menjedanya di kumpulan koneksi, melakukan pg_upgrade, lalu melanjutkan. Dan dari sisi klien, sepertinya database baru saja melambat. Fungsionalitas ini diberikan kepada kami oleh orang-orang dari komunitas. Dia belum mati, tapi semuanya akan segera terjadi. (sudah meninggal)
- sudah meninggal
Selain itu, salah satu fitur baru di PgBouncer adalah dukungan Otentikasi SCRAM, yang juga dibawakan kepada kami oleh orang yang tidak bekerja di Yandex.Cloud. Keduanya adalah fungsi yang kompleks dan penting.
Oleh karena itu, saya ingin memberi tahu Anda terbuat dari apa Odyssey, jika Anda juga ingin menulis sedikit kode sekarang.
Anda memiliki basis Odyssey asli, yang mengandalkan dua pustaka utama. Perpustakaan Kiwi adalah implementasi dari protokol pesan Postgres. Artinya, proto 3 asli Postgres adalah pesan standar yang dapat dipertukarkan oleh frontend dan backend. Mereka diimplementasikan di perpustakaan Kiwi.
Pustaka Machinarium adalah pustaka implementasi utas. Sebuah fragmen kecil dari Machinarium ini ditulis dalam assembler. Tapi jangan khawatir, hanya ada 15 baris.
arsitektur Pengembaraan. Ada mesin utama yang menjalankan coroutine. Mesin ini mengimplementasikan menerima koneksi TCP yang masuk dan mendistribusikan di antara pekerja.
Dalam satu pekerja, seorang penangan untuk beberapa klien dapat bekerja. Dan juga di utas utama, konsol dan pemrosesan tugas crone untuk menghapus koneksi yang tidak lagi diperlukan di kumpulan sedang berputar.
Odyssey diuji menggunakan test suite Postgres standar. Kami baru saja menjalankan pemeriksaan instal melalui Bouncer dan melalui Odyssey, kami mendapatkan div nol. Ada beberapa pengujian terkait pemformatan tanggal yang gagal sama persis di Bouncer dan Odyssey.
Selain itu, ada banyak driver yang memiliki pengujian sendiri. Dan kami menggunakan tes mereka untuk menguji Odyssey.
Juga, karena konfigurasi cascading kami, kami harus menguji berbagai bundel: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey untuk memastikan bahwa jika Odyssey ada di salah satu bagian dalam kaskade, itu juga masih berfungsi seperti yang diharapkan .
Menyapu
Kami menggunakan Odyssey dalam produksi. Dan tidak adil jika saya mengatakan bahwa semuanya berjalan begitu saja. Tidak, yaitu ya, tapi tidak selalu. Misalnya, dalam produksi semuanya berfungsi, kemudian teman kami dari PostgreSQL Professional datang dan mengatakan bahwa kami mengalami kebocoran memori. Mereka benar-benar, kami memperbaikinya. Tapi itu sederhana.
Kemudian kami menemukan bahwa kumpulan koneksi memiliki koneksi TLS masuk dan koneksi TLS keluar. Dan koneksi memerlukan sertifikat klien dan sertifikat server.
Sertifikat server Bouncer dan Odyssey dibaca ulang oleh pcache, tetapi sertifikat klien tidak perlu dibaca ulang dari pcache, karena Odyssey yang dapat diskalakan kami pada akhirnya bergantung pada kinerja sistem membaca sertifikat ini. Ini mengejutkan kami, karena dia tidak segera beristirahat. Pada awalnya, ini diskalakan secara linier, dan setelah 20 koneksi simultan yang masuk, masalah ini muncul dengan sendirinya.
Metode Otentikasi Pluggable adalah kemampuan untuk mengautentikasi dengan alat lunux bawaan. Di PgBouncer, ini diimplementasikan sedemikian rupa sehingga ada utas terpisah yang menunggu tanggapan dari PAM dan ada utas PgBouncer utama yang melayani koneksi saat ini dan dapat meminta mereka untuk tinggal di utas PAM.
Kami tidak menerapkan ini karena satu alasan sederhana. Kami memiliki banyak aliran. Mengapa kita membutuhkannya?
Akibatnya, hal ini dapat menimbulkan masalah karena jika Anda memiliki otentikasi PAM dan otentikasi non-PAM, gelombang besar otentikasi PAM dapat menunda otentikasi non-PAM secara signifikan. Itu salah satu hal yang belum kami perbaiki. Tetapi jika Anda ingin memperbaikinya, Anda bisa melakukan ini.
Penggaruk lainnya adalah fakta bahwa kami memiliki satu utas yang menerima semua koneksi masuk. Dan kemudian mereka dipindahkan ke kumpulan pekerja, tempat jabat tangan TLS akan berlangsung.
Akibatnya, jika Anda memiliki gelombang koheren dari 20 koneksi jaringan, semuanya akan diterima. Dan di sisi klien, libpq akan mulai melaporkan waktu tunggu. Secara default, ini seperti 000 detik di sana.
Jika mereka semua tidak dapat memasuki basis pada saat yang sama, maka mereka tidak dapat memasuki basis, karena semua ini dapat dicakup oleh percobaan ulang non-eksponensial.
Kami akhirnya menyalin skema PgBouncer di sini sehingga kami membatasi jumlah koneksi TCP yang kami terima.
Jika kami melihat bahwa kami menerima koneksi, tetapi pada akhirnya mereka tidak punya waktu untuk berjabat tangan, kami memasukkannya ke dalam antrian sehingga mereka tidak menghabiskan sumber daya CPU. Ini mengarah pada fakta bahwa jabat tangan secara bersamaan mungkin tidak dilakukan untuk semua koneksi yang telah tiba. Tapi setidaknya seseorang akan masuk ke database, meski bebannya cukup kuat.
Rencana Kerja
Apa yang ingin Anda lihat di masa depan di Odyssey? Apa yang siap kita kembangkan sendiri dan apa yang kita harapkan dari masyarakat?
Untuk Agustus 2019.
Seperti inilah peta jalan Odyssey di bulan Agustus:
- Kami menginginkan autentikasi SCRAM dan PAM.
- Kami ingin meneruskan permintaan baca ke standby.
- Saya ingin online-restart.
- Dan kemampuan untuk menjeda di server.
Setengah dari peta jalan ini sudah selesai, dan bukan oleh kami. Dan ini bagus. Jadi mari kita bahas apa yang tersisa dan tambahkan lagi.
? Kami memiliki replika yang, tanpa memenuhi permintaan, hanya akan memanaskan udara. Kami membutuhkan mereka untuk menyediakan failover dan peralihan. Jika ada masalah di salah satu pusat data, saya ingin menyibukkannya dengan beberapa pekerjaan yang bermanfaat. Karena kami tidak dapat mengonfigurasi prosesor pusat yang sama, memori yang sama dengan cara yang berbeda, karena replikasi tidak akan berfungsi sebaliknya.
Pada prinsipnya, di Postgres, mulai dari 10, dimungkinkan untuk menentukan session_attrs saat menghubungkan. Anda dapat membuat daftar semua host basis data dalam koneksi dan mengatakan mengapa Anda pergi ke basis data: tulis atau baca saja. Dan pengemudi itu sendiri akan memilih host pertama dalam daftar yang paling disukainya, yang memenuhi persyaratan session_attrs.
Tetapi masalah dengan pendekatan ini adalah tidak mengontrol kelambatan replikasi. Anda mungkin memiliki semacam replika yang tertinggal oleh waktu yang tidak dapat diterima untuk layanan Anda. Untuk membuat eksekusi permintaan baca berfitur lengkap pada replika, pada kenyataannya, kami perlu mendukung di Odyssey kemampuan untuk tidak berfungsi saat tidak mungkin membaca.
Odyssey harus pergi ke database dari waktu ke waktu dan menanyakan jarak replikasi dari primer. Dan jika sudah mencapai batasnya, jangan biarkan permintaan baru masuk ke database, beri tahu klien bahwa Anda perlu memulai kembali koneksi dan, mungkin, pilih host lain untuk menjalankan permintaan. Ini akan memungkinkan database untuk memulihkan kelambatan replikasi dengan cepat dan kembali lagi untuk merespons dengan kueri.
Sulit untuk menyebutkan tanggal pelaksanaannya, karena bersifat open source. Tapi, saya harap, bukan 2,5 tahun seperti rekan-rekan dari PgBouncer. Ini adalah fitur yang ingin saya lihat di Odyssey.
. Sekarang Anda dapat membuat pernyataan yang telah disiapkan dengan dua cara. Pertama, Anda dapat menjalankan perintah SQL, yaitu "disiapkan". Untuk memahami perintah SQL ini, kita perlu mempelajari cara memahami SQL di sisi Bouncer. Ini akan berlebihan karena berlebihan karena kita membutuhkan seluruh parser. Kami tidak dapat mengurai setiap perintah SQL.
Tapi ada pernyataan yang disiapkan di tingkat protokol pesan di proto3. Dan di sinilah informasi bahwa pernyataan yang disiapkan sedang dibuat datang dalam bentuk terstruktur. Dan kami dapat mendukung pemahaman bahwa pada beberapa koneksi server, klien diminta untuk membuat pernyataan yang telah disiapkan. Dan meskipun transaksi ditutup, kita tetap perlu menjaga koneksi server dan klien.
Tetapi di sini ada perbedaan dalam dialog, karena seseorang mengatakan bahwa Anda perlu memahami pernyataan yang disiapkan yang dibuat oleh klien dan berbagi koneksi server antara semua klien yang membuat koneksi server ini, yaitu siapa yang membuat pernyataan yang disiapkan tersebut.
Andres Freund mengatakan bahwa jika klien mendatangi Anda yang telah membuat pernyataan yang disiapkan seperti itu di koneksi server lain, buatlah untuknya. Tetapi tampaknya agak salah untuk mengeksekusi kueri di database alih-alih klien, tetapi dari sudut pandang pengembang yang menulis protokol untuk berinteraksi dengan database, akan lebih mudah jika dia hanya diberi koneksi jaringan. yang memiliki permintaan yang disiapkan seperti itu.
Dan satu fitur lagi yang perlu kita terapkan. Kami sekarang memiliki pemantauan yang kompatibel dengan PgBouncer. Kami dapat mengembalikan waktu eksekusi kueri rata-rata. Tetapi waktu rata-rata adalah suhu rata-rata di rumah sakit: seseorang kedinginan, seseorang hangat - rata-rata semua orang sehat. Itu tidak benar.
Kami perlu mengimplementasikan dukungan untuk persentil, yang akan menunjukkan bahwa ada permintaan lambat yang menghabiskan sumber daya dan akan membuat pemantauan lebih dapat diterima.
Yang paling penting adalah saya ingin versi 1.0 (Versi 1.1 sudah dirilis). Faktanya sekarang Odyssey ada di versi 1.0rc, yaitu kandidat rilis. Dan semua penggaruk yang saya daftarkan diperbaiki persis dengan versi yang sama, kecuali kebocoran memori.
Apa arti versi 1.0 bagi kita? Kami meluncurkan Odyssey ke markas kami. Itu sudah berjalan di database kami, tetapi ketika mencapai titik 1 permintaan per detik, maka kami dapat mengatakan bahwa ini adalah versi rilis dan ini adalah versi yang dapat disebut 000.
Beberapa orang di komunitas telah meminta lebih banyak jeda dan SCRAM di versi 1.0. Tetapi ini berarti bahwa kami perlu meluncurkan versi produksi berikutnya, karena baik SCRAM maupun jeda belum digabungkan. Tapi, kemungkinan besar, masalah ini akan diselesaikan dengan cukup cepat.
Saya menunggu permintaan penarikan Anda. Dan saya juga ingin mendengar masalah apa yang Anda hadapi dengan Bouncer. Mari kita bahas. Mungkin kami dapat mengimplementasikan beberapa fungsi yang Anda butuhkan.
Ini menyimpulkan bagian saya, saya ingin mendengar dari Anda. Terima kasih!
pertanyaan
Jika saya memasukkan application_name saya sendiri, apakah itu akan dibuang dengan benar, termasuk dalam penggabungan transaksi di Odyssey?
Odyssey atau Bouncer?
Di Pengembaraan. Bouncer dilempar.
Kami akan membuat satu set.
Dan jika koneksi saya yang sebenarnya melompati koneksi lain, apakah akan ditransmisikan?
Kami akan membuat satu set semua parameter yang terdaftar. Saya tidak tahu apakah application_name ada dalam daftar ini. Sepertinya dia melihatnya di sana. Kami akan mengatur semua parameter yang sama. Dengan satu permintaan, set akan melakukan semua yang diinstal oleh klien selama startup.
Terima kasih Andrey atas laporannya! Laporan bagus! Saya senang Odyssey berkembang semakin cepat setiap menit. Saya ingin melanjutkan hal yang sama. Kami telah meminta Anda untuk memiliki koneksi multi sumber data sehingga Odyssey dapat terhubung ke database yang berbeda pada saat yang sama, yaitu master slave, dan kemudian secara otomatis terhubung ke master baru setelah kegagalan.
Ya, sepertinya saya ingat diskusi itu. Sekarang ada beberapa gudang. Tapi tidak ada peralihan di antara mereka. Di pihak kami, kami harus menanyakan server yang masih hidup dan memahami bahwa telah terjadi failover, siapa yang akan memanggil pg_recovery. Saya memiliki cara standar untuk memahami bahwa kami tidak datang ke master. Dan kita harus mengerti entah dari kesalahan atau bagaimana? Artinya, idenya menarik, sedang dibahas. Tulis lebih banyak komentar. Jika Anda memiliki tangan yang bekerja yang tahu C, maka ini umumnya luar biasa.
Masalah penskalaan lintas replika juga menarik bagi kami, karena kami ingin membuat penerapan klaster yang direplikasi sesederhana mungkin untuk pengembang aplikasi. Tapi di sini saya ingin lebih banyak komentar, yaitu bagaimana melakukannya, bagaimana melakukannya dengan baik.
Pertanyaannya juga tentang replika. Ternyata Anda memiliki master dan beberapa replika. Dan jelas bahwa mereka lebih jarang pergi ke replika daripada ke master untuk koneksi, karena mereka mungkin memiliki perbedaan. Anda mengatakan bahwa perbedaan data mungkin sedemikian rupa sehingga bisnis Anda tidak akan memuaskan dan Anda tidak akan pergi ke sana sampai direplikasi. Pada saat yang sama, jika Anda tidak pergi ke sana dalam waktu lama, lalu mulai pergi, maka data yang Anda butuhkan tidak akan langsung tersedia. Artinya, jika kita terus-menerus pergi ke master, maka cache dihangatkan di sana, dan cache sedikit tertinggal di replika.
Ya itu benar. Tidak akan ada blok data di pcache yang Anda inginkan, di cache nyata tidak akan ada informasi tentang tabel yang Anda inginkan, tidak akan ada kueri yang diuraikan dalam paket, tidak ada sama sekali.
Dan ketika Anda memiliki semacam cluster, dan Anda menambahkan replika baru di sana, saat itu dimulai, semuanya buruk di dalamnya, mis.
Saya mendapat ide. Pendekatan yang benar adalah menjalankan sebagian kecil kueri pada replika terlebih dahulu, yang akan menghangatkan cache. Secara kasar, kami memiliki syarat bahwa kami tidak boleh lebih dari 10 detik di belakang master. Dan kondisi ini tidak boleh masuk dalam satu gelombang, tetapi lancar untuk beberapa klien.
Ya, menambah berat badan.
Ini ide yang bagus. Tetapi pertama-tama Anda perlu mengimplementasikan shutdown ini. Pertama kita perlu mematikan, lalu kita akan memikirkan cara menghidupkannya. Ini adalah fitur hebat untuk dihidupkan dengan lancar.
nginx memiliki opsi ini slowly start dalam cluster untuk server. Dan dia secara bertahap menambah beban.
Ya, ide bagus, kami akan mencobanya saat kami mendapatkannya.
Sumber: www.habr.com