Baru-baru ini, kami mengundang Alexei Lesovsky dari Data Egret untuk menyiarkan Zinc Sale . Percakapan itu ternyata menarik dan informatif, jadi saya menawarkan transkrip masalah ini kepada Anda. Karena volume yang mengesankan, itu perlu untuk memecah teks menjadi beberapa bagian. Jika Anda terlalu malas untuk menunggu kelanjutannya, Anda bisa mendengarkan versi audio di sini .
Halo semuanya, ini adalah masalah keempat puluh dari podcast Zinc Prod, dan Anton Okolelov, Nikita Vasilchenko dan Oleg Gritsak adalah tuan rumah permanen bersama kami di studio.
Anton : Jadi, hari ini kita punya tamu, Alexey Lesovsky. Lesha, tolong perkenalkan diri Anda, siapa Anda, apa yang Anda lakukan, dan sebagainya.
Alexei : Halo semuanya, namaku Alexei Lesovsky, karena Antokha sudah mengenalkanku. Saya mengelola Postgres, Saya PostgreSQL DBA (administrator database), saya bekerja dengan login setiap hari, 7 hari seminggu, dan mengelola basis data klien. Kami memiliki kantor - ini adalah perusahaan konsultan, yang bergerak di bidang administrasi, dukungan dan dukungan. Dan orang-orang yang sangat berbeda datang kepada kami dengan database mereka, sebagai aturan ini adalah perusahaan - kecil, besar, kecil, semua jenis berbeda - mereka memiliki masalah dengan database, kami menganalisis masalah ini dan entah bagaimana mencoba memperbaikinya. Sebenarnya, kami memecahkan masalah orang lain, perusahaan lain. Sesuatu seperti itu.
Ya, di waktu senggang saya suka melakukan hal-hal yang berbeda, berjalan melalui hutan, bermain seluncur salju, hiking, minum bir
Anton : minum bir asap
Nikita : sebelum rilis, Lyokha berbicara tentang merokok
Alexei : ya, merokok, ada yang enak, saya sarankan. Rauchbier Merzen.
Anton : ok, tolong beri tahu saya, Anda dbshnik, Anda telah bekerja untuk waktu yang lama, beberapa tahun. Seberapa sulit? Mereka memanggil Anda pada malam hari dan meminta Anda untuk memperbaiki pangkalan. Saya menelepon Anda jam lima pagi sekitar satu setengah tahun yang lalu.
Alexei : ya, itu, itu masalah.
Anton : bagaimana Anda bertahan hidup, katakan padaku
Alexey : dengarkan, saya sudah bekerja sejak 2014. Hingga 2014, saya bekerja sebagai administrator Linux dalam pengembangan web. Admin memiliki banyak hal, kami memiliki virtualisasi kvm, ada banyak Linux, ada semua jenis Ruby-on-rails, nginxs, php, rails ...
Oleg : Docker sudah?
Alexey : buruh pelabuhan baru saja mulai, kami belum memperkenalkannya di mana pun dalam produksi, tetapi kecenderungan untuk ini sudah dimulai.
Dan ada banyak postgres di kantor kami. Kemudian saya mengejar rubel yang panjang dan memutuskan bahwa saya bisa mengerjakan dua pekerjaan pada saat yang sama. Dan dia mulai bekerja sebagai administrator jarak jauh di kantor Moskow. Saya menggabungkan dua karya, hanya ada database yang dikelola oleh konsultasi Postgresql. Ada Max Boguk, Ilya Kosmodemyansky, dan sebagai administrator, saya mulai melakukan bagian dari tugas yang terkait dengan kedutaan. Ya, yaitu Aku mulai diam-diam mengambil roti mereka. Dan pada suatu saat Max mengatakan ini padaku: dengarkan, dan biarkan kamu pergi bekerja bersama kami. Anda akan meninggalkan semua pekerjaan Anda, pekerjaan paruh waktu, Anda akan datang kepada kami untuk waktu penuh.
Yah, saya setuju, saya tidak ragu, pada prinsipnya saya ditawari gaji yang sebanding, dan saya mendapat pekerjaan dan mulai bekerja dari rumah, dan sekarang sejak 2014, ternyata, saya telah bekerja selama 5 tahun, saya bekerja secara khusus dengan tuan, ya, dalam mode lama semua jenis tema admin, saya bekerja dengan mereka karena kebiasaan. Yaitu jika di perusahaan kami ada masalah dengan sesuatu untuk dipahami dari sisi admin, mereka mengusir saya, saya mengerti
Anton : Tapi secara umum, perlukah mengetahui hal-hal admin ini? Bukan hanya di sana, pangkalan berada dalam ruang hampa, berputar di suatu tempat, Anda perlu mengkonfigurasi sistem operasi, kan?
Alexei : ya, ya, itu persis karena dia umumnya sangat bergantung pada subsistem sistem operasi, memori virtual, dan manajemen disk, mis. seolah-olah dia sendiri tidak secara langsung mengoperasikan sumber daya, dia seolah-olah membongkar semua pekerjaan ini ke sistem operasi, dan itu sendiri mengelola disk I / O, manajemen halaman memori, itu saja, proses switching, dan karenanya, jika Anda menemukan shutdown postgres, Anda perlu ada juga sedikit peretasan di sistem operasi, cara kerja semuanya di sana dan cara kerjanya di antarmuka dengan postgres.
Misalnya, jika dibandingkan dengan Oracle, Oracle memiliki, misalnya, subsistemnya sendiri yang bekerja dengan input-output, mis. mereka melewati sistem operasi, mereka dapat bekerja secara langsung dengan disk, tetapi dalam Posgres ini tidak, Anda perlu tahu bagaimana sistem operasi bekerja dengan database.
Oleg : apakah Anda harus mendukung postgres di Windows?
Alexei : ya, saya harus, kami punya klien, mereka dengan Windows, kami melayani semacam kantor St. Petersburg, melakukan audit terhadap database untuk mereka. Basis mereka ada di Windows, umumnya menakutkan, kami terhubung ke beberapa protokol melalui protokol terminal, Remote Desktop dibuka, kami meluncurkan beberapa hal yang berkaitan dengan merekam kinerja di sana. Singkatnya, itu sulit, menakutkan, bagaimana mimpi mengerikan sekarang diingat. Dan sekarang pelanggan pada dasarnya semua duduk di Linux. Sebenarnya tidak ada orang di Windows.
Oleg : apa rasa sakit utama pada Postgre yang bisa dilihat semua orang?
Alexey : banyak orang menginginkan filer otomatis dan multi-master. Nah, multimaster, tentu saja, hal seperti itu, tidak mungkin tercapai. Tetapi semua orang bekerja dengan Galera (dengan Mysql), dan mereka berkata: mengapa, kami juga menginginkan multimaster sedang berlangsung.
Nah, dalam perkembangannya ada hal-hal seperti itu, tetapi tidak dalam inti progresif itu sendiri, ada hal-hal seperti itu yang menerapkan jenis multi-master, tetapi belum diproduksi sama sekali. Tetapi orang-orang menginginkan multimaster. Dan orang-orang juga menginginkan filer otomatis. Tapi sekarang, terima kasih Tuhan Patroni telah muncul, di Patroni Anda dapat melakukan auto-filer, orang-orang secara perlahan memperkenalkannya. Secara umum, dari sudut pandang saya, Patroni telah menjadi standar de facto. Banyak perusahaan besar sudah menerapkannya. Gitlab yang sama, mereka baru-baru ini membuat laporan, mereka menggunakan Patroni, mereka senang dengan segalanya, semua orang senang.
Anton : Dengar, bisakah Anda memberi tahu kami secara singkat, apa itu patron untuk programmer sederhana? Kami terutama mendengarkan para pemimpin tim dan programmer
Nikita : tunggu, bolehkah aku membunuhmu, dan aku akan meminta lebih banyak lagi bagi yang bukan programmer untuk menjelaskan apa itu multimaster
Alexei : lihat, bayangkan sekarang, Antokha adalah seorang programmer, dia menulis aplikasi, dan aplikasi perlu menyimpan datanya di suatu tempat. Dia menempatkan mereka di pangkalan, di kedutaan. Pada titik tertentu, database terletak pada satu server, dan kemudian server sekali - dan berhenti bekerja. Catu daya terbakar, dan aplikasi harus terus bekerja dengan pangkalan. Dan di sini muncul opsi bahwa kita perlu memiliki semacam salinan database dan terus bekerja dengannya. Dan baik beralih ke itu, dan idealnya, jangan melakukan peralihan sehingga aplikasi kita tahu tentang basis kedua ini dan terus menulis untuk itu.
Ini sebenarnya multimaster, ketika kami memiliki beberapa node yang tersedia untuk membaca dan menulis, dan aplikasi kami dapat bekerja secara bersamaan dengan mereka dan menulis data ke salah satu node ini dan membaca data dari node ini, tetapi sifatnya diatur sedemikian rupa sehingga tidak cukup ideal dicapai, dan ada pro dan kontra, ada kerugian, kasus penggunaannya sendiri untuk menggunakan multimaster. Contoh paling umum adalah bahwa Anda tidak dapat menulis data yang sama, secara relatif, menjadi dua contoh, misalnya bekerja dengan tabel yang sama, menulis ke tabel yang sama melalui dua server, akan ada konflik dan mereka perlu diselesaikan, ini adalah masalah oleh karena itu perlu untuk menulis jika kita menulis dalam satu tabel, maka kita hanya menulis melalui satu server.
Nikita : dan ini berhubungan langsung dengan kipas-otomatis, ya, apakah itu terhubung?
Alexei : ya, dan ini karena auto-fielder, di sini, seolah-olah, satu mengikuti dari yang lain. Jika kita tidak mampu membeli multimaster, maka kita menginginkan semacam mekanisme transparan yang akan mengalihkan node cadangan ke mode master, yaitu. kami memiliki aplikasi, ini berfungsi, dan segera setelah aplikasi tersebut dihilangkan dari database, pengembang tidak ingin mengubah konfigurasi aplikasi ini dan menunjukkan alamat database baru di sana, restart aplikasi, terutama jika ada banyak aplikasi. Saya ingin semacam mekanisme transparan yang akan bekerja di suatu tempat di bawah tenda, beralih database, dan aplikasi kita akan bekerja dengan alamat yang sama dan terus membaca dari database ini. Untuk melakukan ini, Anda sudah memerlukan filer otomatis yang secara transparan mengalihkan node cadangan ke mode penyihir, dan untuk Patroni ini hanya digunakan
Anton : Apakah Patroni saklar murni atau garpu postgres, semacam tambahan?
Alexei : ini, bisa dikatakan, adalah layanan terpisah, proses terpisah yang berjalan pada host dengan database. Dan dia memantau keadaan post-cluster cluster. Dua tujuan dikejar di sini - autofailover dan manajemen klaster. Tetapi dalam kasus ini kami mendapatkan cluster terdistribusi, tetapi kami memiliki beberapa node di cluster, master dan beberapa replika. Oleh karena itu, Anda perlu terus memantau keadaan cluster, terus-menerus melihat apakah master masih hidup. Jika dia tiba-tiba mati - Anda harus beralih ke peran "master" server lain. Dan untuk ini digunakan, secara umum, ada dua pendekatan, bagaimana mendukung cluster view ini, representasi dalam cluster tentang bagaimana ia harus hidup saat ini. Ada opsi ketika masing-masing node cluster - mereka memeriksa satu sama lain. Dan Anda dapat menyimpan keadaan ini di luar, mis. Di luar cluster. Dan hanya Patroni yang menggunakan pendekatan ini, ia mengambil dan menyimpan status cluster dalam sistem ketiga. Ini biasanya semacam DCS (konfigurasi sistem penyimpanan terdistribusi). Itu bisa menjadi etcd, consul, atau bisa juga kuberenetesovsky etcd. Yaitu tergantung pada infrastrukturnya. Dengan baik dan sesuai Patroni hanya menyimpan negara cluster dalam sistem DCS ini dan memperbaruinya.
Jika tiba-tiba salah satu node tiba-tiba gagal, node baru dipilih. Jika master ini, misalnya, jatuh, master baru dipilih, dan status ini diperbarui lagi di DCS. Dan di sini dengan mengorbankan DCS Patroni mendukung kesehatan cluster.
Anton : Dan jika jaringan berkedip antara Patroni dan pangkalan?
Alexei : Begini, ada database, entah itu semacam server, atau, katakanlah, di Kubernet itu bisa berupa sub. Pertimbangkan kasus sederhana, katakanlah ini adalah server. Di server yang sama, kami memiliki database yang berjalan, dan pada server yang sama kami menjalankan agen Patroni. Ini adalah proses yang ringan, mereka bekerja pada host yang sama dan berkomunikasi secara relatif di localhost. Jaringan kami mungkin berkedip antara repositori DCS dan host tempat basis dan Patroni bekerja.
Mungkin ada opsi yang berbeda. Bergantung pada seberapa parah kedipan jaringan ini terjadi. Itu terjadi jika itu adalah seorang master, dan ia ternyata terisolasi, maka node lain akan menemukan bahwa master itu sudah pergi. Mereka hanya akan memilih master baru, dan dia akan melihat master lama bahwa dia terisolasi, dan Patroni akan memulai kembali dalam mode hanya baca. Nah, agar tidak ada otak yang terbelah. Sangat buruk jika aplikasi kita menulis ke dua node secara bersamaan. Maka pengembang harus menyapu data, dan ini pekerjaan yang sangat sulit - untuk mengumpulkan data ini dalam bentuk yang konsisten. Oleh karena itu, chuck hanya me-restart node dalam read only dan hanya itu, dan itu berfungsi. Segera setelah jaringan dipulihkan, Patroni akan dapat mencapai DCS, mereka akan mengoordinasikan pandangan gugus lebih jauh di sana dan akan datang ke beberapa jenis solusi yang disepakati. Kemungkinan besar simpul yang terisolasi ini, yang merupakan master lama, akan terhubung sebagai replika ke master baru ...
Anton . Nah, dalam praktiknya, bagaimana cara kerjanya? Apakah ada masalah, jebakan. Agar Oleg mengambil dan mengimplementasikan, misalnya, Patroni, ia perlu membuat keputusan untuk ini.
Oleg . Ya, segera
Alexey . Begini, kami telah menggunakan Patroni dengan pelanggan sejak tahun lalu. Klien pertama kami muncul menurut pendapat saya pada November 2018. Dan pada saat itu kami tidak memiliki ide yang sangat bagus tentang bagaimana bekerja dengan ini, tetapi untuk tahun ini kami bekerja, pada prinsipnya, semuanya cocok untuk kami. Kami belajar cara memasaknya. Pada prinsipnya, untuk mengingatkan, secara umum, itu tidak benar-benar membutuhkan banyak langkah, secara harfiah dua atau tiga tindakan dari sisi postgres, dari sisi konfigurasi patron, dan semua ini bekerja dengan cukup baik.
Sepotong itu dapat diandalkan. Pertama-tama sederhana, ditulis dengan Python, memakan sedikit memori dan bekerja secara andal. Satu-satunya hal dalam infrastruktur adalah DCS ini. Tetapi sebagai aturan itu perlu baik Konsul atau etcd. Tetapi bagi banyak perusahaan, benda ini sudah digunakan untuk semua jenis penemuan layanan yang berbeda, oleh karena itu, sebagai suatu peraturan, tidak ada masalah dengan ini.
Dan masalah apa yang muncul: masalah paling mendasar yang tidak langsung dirasakan orang adalah kita bisa kehilangan sebagian data dengan pengarsipan otomatis
Oleg : karena lag replikasi?
Alexei : bayangkan sebuah situasi di mana pengarsipan otomatis terjadi selama replikasi, master tua menjadi offline, tetapi kami masih menulis beberapa bagian dari data ke dalamnya. Misalkan ada semacam replikasi lag, master baru dipilih dari replika lain. Master baru dinaikkan dan jika Patroni dikonfigurasi sedemikian rupa sehingga simpul yang jatuh secara otomatis dimasukkan dalam cluster, misalnya, autostart layanan dihidupkan, maka ketika master lama naik, ia melihat bahwa ia tidak lagi master, ia di belakang, ia akan mencoba untuk terhubung ke master baru dan menjadi isyaratnya. Dan pada saat itu dia menjalankan perintah pg_rewind.
Perintah ini memundurkan log transaksi pada node lama (master lama) hingga dapat terhubung ke master baru, yaitu, log transaksi ditimpa. Pada titik ini, kami mungkin kehilangan sebagian data. Di Patroni sendiri ada sedikit perlindungan, ada beberapa tikungan yang memungkinkan replika untuk tidak mengambil bagian dalam pemilihan dengan tumpukan besar. Jika, misalnya, semua replika memiliki kelambatan besar, maka pemilihan tidak akan dimulai, dan kemudian intervensi manual administrator diperlukan bagi admin untuk masuk dan memulai file otomatis dengan tangan. Atau mereka semua akan menunggu sampai tuan tua naik. Sampai karyanya dipulihkan. Dan mereka sudah terhubung dengan itu dan akan terus menangkapnya.
Yaitu, di Patroni ada mekanisme yang memungkinkan Anda untuk tidak kehilangan data, tetapi ada risiko, jadi Anda harus hati-hati
Anton : bagaimana dengan replikasi sinkron?
Alexei : replikasi sinkron, Anda tahu, ketika kita menggunakan replikasi sinkron, kita kehilangan kinerja. Tidak semua orang bisa melakukan kesepakatan ini. Tetapi jika kita menggunakan replikasi sinkron, risiko kehilangan data berkurang. Tetapi jika kita menggunakan beberapa node, katakanlah lebih dari dua, maka kita masih perlu mempertimbangkan opsi ketika kita mengalami kecelakaan baik pada master dan pada replika sinkron. Dan kami masih memiliki replika kedua, dan mungkin ternyata kami dapat menjebaknya dan kehilangan beberapa data lagi. Pilihan yang berbeda dimungkinkan, mereka perlu dievaluasi, dilihat dan dipahami apakah perilaku seperti itu cocok untuk kita atau tidak.
Anton : dengarkan, hanya ada dua server yang jatuh - itu seperti menyediakan invasi alien
Aleksey : dan ada pukulan keras pada wanita tua itu
Oleg : apakah kamu ingat panggilan yang sama pada jam lima pagi ke Lesha untuk terakhir kalinya, apa hubungannya dengan hal yang menarik, Anton, dan bukannya kita segera kehilangan dua pangkalan?
Anton : itu faktor manusia. Ya, itu terjadi.
Alexey : ngomong-ngomong, saya tidak ingat alasan panggilan itu
Anton : kami mentransfer dua server di sana, mereka bekerja secara paralel, mencatat data, itu tidak masalah. Dan sistem dapat bekerja pada satu, tetapi satu ditransfer ke pusat data lain, dihidupkan. Yang kedua diangkut sejauh ini, dan ada semacam kabel yang disentuh pada saat instalasi, dan yang lama juga dihancurkan - mereka mencampur sesuatu. Secara umum, kami dua server jatuh, mulai naik, dan karena mereka dikonfigurasi secara kaku untuk merekam, mereka memiliki pos pemeriksaan yang sangat jarang atau sesuatu seperti itu. Itu dimulai untuk waktu yang lama, kami tidak mengerti apa yang terjadi
Oleg : seratus pertunjukan wal-log
Anton : kami tidak mengerti apa yang terjadi, mengapa itu tidak dimulai, dan akibatnya saya harus menelepon. Sebenarnya tidak ada yang istimewa yang harus dilakukan ...
Alexei : well, ada satu-satunya hal yang mungkin kita sambungkan, kita telah melihat bahwa semuanya beres
Oleg : mengkonfirmasi kematian pasien
Anton : sebenarnya, Anda hanya harus menunggu, pada umumnya.
Alexey . Ya, ini masalah yang diketahui. Dengan beberapa pengaturan, pos-pos pemeriksaannya panjang. Ada masalah seperti itu.
Tetapi secara umum, jika Anda mengingat panggilan malam ini, dalam praktiknya kami jarang menelepon pada malam hari, kami memiliki otomatisasi khusus yang diatur - bertugas, semuanya sebagaimana mestinya, dipilih sesuai dengan jadwal khusus. Jadi, jika Anda ingat, mungkin sekali setiap enam bulan seseorang akan menelepon
Oleg : semuanya dari perusahaan kami mungkin
Alexey : tidak, berbeda
Anton : Oleg, teleponlah lebih sering
Oleg : kami akan melakukan peralihan hari ini, saya mungkin akan menelepon
Alexey : kita punya teman, waktu malam mereka sudah tutup, mereka hanya akan bekerja
Anton : dengarkan, Lech, Anda mengatakan bahwa Patroni memiliki beberapa analog. Bagaimana mereka berbeda, apa yang ada
Alexey : pada dasarnya ada dua opsi, ada repmgr, hal ini muncul sejak lama, sekitar 10 tahun yang lalu. Ini mengimplementasikan mekanisme ketika node dari post-grace cluster saling memeriksa, siapa yang hidup, siapa yang tidak hidup. Tapi menurut saya ini tidak terlalu, saya tidak terlalu suka skema kerja ini.
Dan tidak ada auto-filer di luar kotak, repmgr awalnya dipertajam khusus untuk mengelola cluster dan untuk beralih manual, untuk peralihan tersebut. Dan jika Anda ingin langsung melakukan auto-filer, maka Anda perlu menginstal demo repmgrd secara terpisah, dan, ternyata, file otomatis dimulai di sini. Masalahnya nyaman, bagus, tapi ya - kami tidak memiliki filer otomatis di luar kotak. Anda harus meletakkannya secara terpisah. Secara umum, masalahnya bagus, nyaman, dalam arti dapat dikonfigurasi dengan baik, nyaman untuk mempertahankan cluster berbasis cluster. Dia sangat fleksibel, dapat disesuaikan. Replika dapat dituangkan dalam berbagai cara. Dari backup, dari replika untuk menuangkan yang lain, dari master. Singkatnya, hal yang fleksibel, karena 10 tahun. Dan banyak fitur yang berbeda didorong ke dalamnya, itu sangat bagus.
Dan opsi lain adalah Stolon. Dia muncul pada waktu yang hampir bersamaan dengan Patroni, beberapa saat kemudian. Itu ditulis di Go.
Tetapi memiliki arsitektur yang lebih bercabang. Jika Anda membuka situs web proyek, akan ada gambar, dan Stolon sendiri terdiri dari beberapa komponen. Dia memiliki node penjaga yang bekerja dengan database yang meningkatkan Postges. Lalu ada yang disebut simpul Sentinel. Mereka memantau keadaan cluster, memeriksa ketersediaannya, memverifikasi bahwa node itu hidup atau tidak hidup. Mereka mengelola keadaan cluster dan mengkonfigurasi ulang jika terjadi sesuatu.
Dan ada yang disebut node proxy, semua lalu lintas melewati mereka. Aplikasi klien berfungsi dengan proksi. -, - , . Yaitu . , , Stolon DCS, consul, etcd. - .
, - , bare metal , , - , . . ( -) , , .
, . . , . , . oltp- . Stolon , .
, 6 8, . , , . , — wal_keep_segments — - , , , . , - . , . . Yaitu , . , , . , — . .
: , , - Citus? , .
: Citus — . Citus , CitusDB, -. , , ,
: ?
: , , . . , pg autofailover. , . , , . , , . , , . , , . Yaitu .
: Citus. , , . — , ...
: , ,
: , , , , ,
: , , . , , , . "in the wild" . , .
Dekripsi lebih lanjut dari masalah ini akan diposting di Habr dalam waktu dekat, tetapi untuk sekarang berlangganan podcast Zinc Prod , ada banyak hal menarik di depan!