Matlamat utama Patroni adalah untuk menyediakan Ketersediaan Tinggi untuk PostgreSQL. Tetapi Patroni hanyalah templat, bukan alat siap pakai (yang, secara umum, dikatakan dalam dokumentasi). Pada pandangan pertama, setelah menyediakan Patroni dalam makmal ujian, anda dapat melihat betapa hebatnya alat itu dan betapa mudahnya ia mengendalikan percubaan kami untuk memecahkan kluster. Walau bagaimanapun, dalam amalan, dalam persekitaran pengeluaran, segala-galanya tidak selalu berlaku dengan indah dan elegan seperti dalam makmal ujian.
Saya akan memberitahu anda sedikit tentang diri saya. Saya bermula sebagai pentadbir sistem. Bekerja dalam pembangunan web. Saya telah bekerja di Data Egret sejak 2014. Syarikat ini terlibat dalam perundingan dalam bidang Postgres. Dan kami memberi perkhidmatan tepat pada Postgres, dan kami bekerja dengan Postgres setiap hari, jadi kami mempunyai kepakaran berbeza berkaitan operasi.
Dan pada penghujung 2018, kami mula perlahan-lahan menggunakan Patroni. Dan beberapa pengalaman telah terkumpul. Kami entah bagaimana mendiagnosisnya, menalanya, mencapai amalan terbaik kami. Dan dalam laporan ini saya akan bercakap tentang mereka.
Selain daripada Postgres, saya suka Linux. Saya suka mencucuk di dalamnya dan meneroka, saya suka mengumpul teras. Saya suka virtualisasi, bekas, docker, Kubernetes. Semua ini menarik minat saya, kerana tabiat admin lama mempengaruhi. Saya suka berurusan dengan pemantauan. Dan saya suka perkara postgres yang berkaitan dengan pentadbiran, iaitu replikasi, sandaran. Dan pada masa lapang saya menulis dalam Go. Saya bukan jurutera perisian, saya hanya menulis untuk diri saya sendiri dalam Go. Dan ia memberi saya keseronokan.
- Saya rasa ramai di antara anda tahu bahawa Postgres tidak mempunyai HA (Ketersediaan Tinggi) di luar kotak. Untuk mendapatkan HA, anda perlu memasang sesuatu, mengkonfigurasinya, berusaha dan mendapatkannya.
- Terdapat beberapa alat dan Patroni adalah salah satu daripada mereka yang menyelesaikan HA dengan cukup hebat dan sangat baik. Tetapi dengan meletakkan semuanya dalam makmal ujian dan menjalankannya, kita dapat melihat bahawa semuanya berfungsi, kita boleh menghasilkan semula beberapa masalah, lihat bagaimana Patroni melayani mereka. Dan kita akan melihat bahawa semuanya berfungsi dengan baik.
- Tetapi dalam amalan, kami menghadapi masalah yang berbeza. Dan saya akan bercakap tentang masalah ini.
- Saya akan memberitahu anda bagaimana kami mendiagnosisnya, perkara yang kami tweak - sama ada ia membantu kami atau tidak.
- Saya tidak akan memberitahu anda cara memasang Patroni, kerana anda boleh google di Internet, anda boleh melihat fail konfigurasi untuk memahami bagaimana semuanya bermula, bagaimana ia dikonfigurasikan. Anda boleh memahami skema, seni bina, mencari maklumat mengenainya di Internet.
- Saya tidak akan bercakap tentang pengalaman orang lain. Saya hanya akan bercakap tentang masalah yang kami hadapi.
- Dan saya tidak akan bercakap tentang masalah yang berada di luar Patroni dan PostgreSQL. Jika, sebagai contoh, terdapat masalah yang berkaitan dengan pengimbangan, apabila kluster kita telah runtuh, saya tidak akan bercakap mengenainya.
Dan sedikit penafian sebelum kami memulakan laporan kami.
Semua masalah yang kami hadapi ini, kami hadapi dalam 6-7-8 bulan pertama operasi. Lama kelamaan, kami mencapai amalan terbaik dalaman kami. Dan masalah kami hilang. Oleh itu, laporan itu diumumkan kira-kira enam bulan lalu, apabila semuanya segar di kepala saya dan saya mengingati semuanya dengan sempurna.
Dalam penyediaan laporan, saya sudah membangkitkan postmortem lama, melihat log. Dan beberapa butiran boleh dilupakan, atau beberapa butiran tidak dapat disiasat sepenuhnya semasa analisis masalah, jadi pada beberapa ketika ia mungkin kelihatan bahawa masalah itu tidak dipertimbangkan sepenuhnya, atau terdapat kekurangan maklumat. Jadi saya minta awak maafkan saya untuk masa ini.
Apa itu Patroni?
- Ini adalah templat untuk membina HA. Itulah yang dikatakan dalam dokumentasi. Dan dari sudut pandangan saya, ini adalah penjelasan yang sangat betul. Patroni bukanlah peluru perak yang akan menyelesaikan semua masalah anda, iaitu, anda perlu berusaha untuk menjadikannya berfungsi dan membawa manfaat.
- Ini ialah perkhidmatan ejen yang dipasang pada setiap perkhidmatan pangkalan data dan merupakan sejenis sistem init untuk Postgres anda. Ia memulakan Postgres, berhenti, mulakan semula, konfigurasi semula dan menukar topologi kluster anda.
- Sehubungan itu, untuk menyimpan keadaan kluster, perwakilan semasanya, seperti yang kelihatan, beberapa jenis storan diperlukan. Dan dari sudut pandangan ini, Patroni mengambil jalan menyimpan keadaan dalam sistem luaran. Ia adalah sistem storan konfigurasi teragih. Ia boleh jadi Etcd, Consul, ZooKeeper, atau kubernetes Etcd, iaitu salah satu daripada pilihan ini.
- Dan salah satu ciri Patroni ialah anda mendapatkan autofiler daripada kotak, hanya dengan menyediakannya. Jika kita mengambil Repmgr sebagai perbandingan, maka pemfail disertakan di sana. Dengan Repmgr, kami mendapat pertukaran, tetapi jika kami mahukan autofiler, maka kami perlu mengkonfigurasinya tambahan. Patroni sudah mempunyai autofiler di luar kotak.
- Dan ada banyak perkara lain. Sebagai contoh, penyelenggaraan konfigurasi, menuangkan replika baru, sandaran, dll. Tetapi ini di luar skop laporan, saya tidak akan bercakap mengenainya.
Dan keputusan kecil ialah tugas utama Patroni adalah untuk melakukan autofail dengan baik dan boleh dipercayai supaya kluster kami kekal beroperasi dan aplikasi tidak menyedari perubahan dalam topologi kluster.
Tetapi apabila kami mula menggunakan Patroni, sistem kami menjadi sedikit lebih rumit. Jika sebelum ini kita mempunyai Postgres, maka apabila menggunakan Patroni kita mendapat Patroni sendiri, kita mendapat DCS di mana keadaan disimpan. Dan semuanya mesti berfungsi entah bagaimana. Jadi apa yang boleh berlaku?
Boleh pecah:
- Postgres mungkin rosak. Ia boleh menjadi tuan atau replika, salah satu daripadanya mungkin gagal.
- Patroni sendiri mungkin pecah.
- DCS tempat keadaan disimpan mungkin pecah.
- Dan rangkaian boleh pecah.
Semua perkara ini akan saya pertimbangkan dalam laporan.
Saya akan mempertimbangkan kes kerana ia menjadi lebih kompleks, bukan dari sudut kes itu melibatkan banyak komponen. Dan dari sudut perasaan subjektif, bahawa kes ini sukar untuk saya, sukar untuk membukanya ... dan sebaliknya, ada kes yang ringan dan mudah untuk membukanya.
Dan kes pertama adalah yang paling mudah. Ini berlaku apabila kami mengambil kluster pangkalan data dan menggunakan storan DCS kami pada kluster yang sama. Ini adalah kesilapan yang paling biasa. Ini adalah kesilapan dalam membina seni bina, iaitu, menggabungkan komponen yang berbeza di satu tempat.
Jadi, ada seorang fail, mari kita berurusan dengan apa yang berlaku.
Dan di sini kami berminat apabila pemfail berlaku. Iaitu, kami berminat pada saat ini apabila keadaan kluster berubah.
Tetapi pemfail tidak selalu serta-merta, iaitu ia tidak mengambil sebarang unit masa, ia boleh ditangguhkan. Ia boleh tahan lama.
Oleh itu, ia mempunyai masa mula dan masa tamat, iaitu ia adalah peristiwa yang berterusan. Dan kami membahagikan semua acara kepada tiga selang: kami mempunyai masa sebelum pemfail, semasa pemfail dan selepas pemfail. Iaitu, kami mempertimbangkan semua peristiwa dalam garis masa ini.
Dan perkara pertama, apabila pemfail berlaku, kita mencari punca apa yang berlaku, apakah punca apa yang membawa kepada pemfail.
Jika kita melihat log, ia akan menjadi log klasik Patroni. Dia memberitahu kami di dalamnya bahawa pelayan telah menjadi tuan, dan peranan tuan telah berpindah ke nod ini. Di sini ia diserlahkan.
Seterusnya, kita perlu memahami mengapa pemfail berlaku, iaitu peristiwa yang berlaku yang menyebabkan peranan induk berpindah dari satu nod ke nod yang lain. Dan dalam kes ini, semuanya mudah. Kami mempunyai ralat dalam berinteraksi dengan sistem storan. Tuan menyedari bahawa dia tidak boleh bekerja dengan DCS, iaitu, terdapat beberapa masalah dengan interaksi. Dan dia mengatakan bahawa dia tidak lagi boleh menjadi tuan dan meletak jawatan. Baris ini "menurunkan pangkat diri" mengatakan dengan tepat.
Jika kita melihat peristiwa yang mendahului pemfail, kita dapat melihat di sana sebab-sebab yang menjadi masalah untuk penerusan wizard.
Jika kita melihat log Patroni, kita akan melihat bahawa kita mempunyai banyak ralat, tamat masa, iaitu ejen Patroni tidak boleh bekerja dengan DCS. Dalam kes ini, ini ialah ejen Konsul, yang berkomunikasi pada port 8500.
Dan masalahnya di sini ialah Patroni dan pangkalan data berjalan pada hos yang sama. Dan pelayan Konsul telah dilancarkan pada nod yang sama. Dengan membuat beban pada pelayan, kami mencipta masalah untuk pelayan Konsul juga. Mereka tidak dapat berkomunikasi dengan betul.
Selepas beberapa lama, apabila beban berkurangan, Patroni kami dapat berkomunikasi dengan ejen semula. Kerja biasa disambung semula. Dan pelayan Pgdb-2 yang sama menjadi tuan semula. Iaitu, terdapat flip kecil, kerana nod itu meletak jawatan kuasa tuan, dan kemudian mengambilnya semula, iaitu, semuanya kembali seperti semula.
Dan ini boleh dianggap sebagai penggera palsu, atau boleh dianggap bahawa Patroni melakukan segala-galanya dengan betul. Iaitu, dia menyedari bahawa dia tidak dapat mengekalkan keadaan kluster dan menghapuskan kuasanya.
Dan di sini masalah timbul kerana fakta bahawa pelayan Konsul berada pada perkakasan yang sama dengan pangkalan. Sehubungan itu, sebarang beban: sama ada beban pada cakera atau pemproses, ia juga mempengaruhi interaksi dengan kluster Konsul.
Dan kami memutuskan bahawa ia tidak sepatutnya tinggal bersama, kami memperuntukkan kluster berasingan untuk Konsul. Dan Patroni telah pun bekerjasama dengan Konsul yang berasingan, iaitu, terdapat kluster Postgres yang berasingan, kluster Konsul yang berasingan. Ini adalah arahan asas tentang cara membawa dan menyimpan semua perkara ini supaya ia tidak hidup bersama.
Sebagai pilihan, anda boleh memutar parameter ttl, loop_wait, retry_timeout, iaitu cuba bertahan pada puncak beban jangka pendek ini dengan meningkatkan parameter ini. Tetapi ini bukan pilihan yang paling sesuai, kerana beban ini boleh lama dalam masa. Dan kami hanya akan melampaui had parameter ini. Dan itu mungkin tidak benar-benar membantu.
Masalah pertama, seperti yang anda faham, adalah mudah. Kami mengambil dan meletakkan DCS bersama-sama dengan pangkalan, kami mendapat masalah.
Masalah kedua adalah serupa dengan yang pertama. Ia serupa kerana kami sekali lagi mempunyai masalah kebolehoperasian dengan sistem DCS.
Jika kita melihat log, kita akan melihat bahawa kita sekali lagi mempunyai ralat komunikasi. Dan Patroni berkata saya tidak boleh berinteraksi dengan DCS jadi tuan semasa masuk ke mod replika.
Tuan lama menjadi replika, di sini Patroni berfungsi, sebagaimana mestinya. Ia menjalankan pg_rewind untuk memundurkan log transaksi dan kemudian menyambung kepada induk baharu untuk mengejar induk baharu. Di sini Patroni bersenam, seperti yang sepatutnya.
Di sini kita mesti mencari tempat yang mendahului pemfail, iaitu ralat yang menyebabkan kita mempunyai pemfail. Dan dalam hal ini, log Patroni agak mudah untuk digunakan. Dia menulis mesej yang sama pada selang waktu tertentu. Dan jika kita mula menatal log ini dengan cepat, maka kita akan melihat dari log bahawa log telah berubah, yang bermaksud bahawa beberapa masalah telah bermula. Kami segera kembali ke tempat ini, lihat apa yang berlaku.
Dan dalam keadaan biasa, log kelihatan seperti ini. Pemilik kunci diperiksa. Dan jika pemilik, sebagai contoh, telah berubah, maka beberapa peristiwa mungkin berlaku yang Pattroni mesti bertindak balas. Tetapi dalam kes ini, kami baik-baik saja. Kami sedang mencari tempat di mana kesilapan bermula.
Dan setelah menatal ke titik di mana ralat mula muncul, kami melihat bahawa kami telah mengalami auto-failover. Dan kerana kesilapan kami berkaitan dengan interaksi dengan DCS dan dalam kes kami, kami menggunakan Konsul, kami juga melihat log Konsul, apa yang berlaku di sana.
Jika dibandingkan secara kasar masa pemfail dan masa dalam log Konsul, kita lihat jiran kita dalam kelompok Konsul mula meragui kewujudan ahli kelompok Konsul yang lain.
Dan jika anda melihat log ejen Konsul lain, anda juga boleh melihat bahawa terdapat beberapa jenis keruntuhan rangkaian berlaku di sana. Dan semua ahli kluster Konsul meragui kewujudan satu sama lain. Dan ini adalah dorongan untuk pemfail.
Jika anda melihat apa yang berlaku sebelum kesilapan ini, anda boleh melihat bahawa terdapat pelbagai jenis kesilapan, contohnya, tarikh akhir, RPC jatuh, iaitu, jelas terdapat beberapa jenis masalah dalam interaksi ahli kluster Konsul antara satu sama lain. .
Jawapan paling mudah ialah membaiki rangkaian. Tetapi bagi saya, berdiri di atas podium, adalah mudah untuk mengatakan ini. Tetapi keadaan sedemikian tidak selalunya pelanggan mampu untuk membaiki rangkaian. Dia mungkin tinggal di DC dan mungkin tidak dapat membaiki rangkaian, menjejaskan peralatan. Dan beberapa pilihan lain diperlukan.
Terdapat pilihan:
- Pilihan paling mudah, yang ditulis, pada pendapat saya, walaupun dalam dokumentasi, adalah untuk melumpuhkan pemeriksaan Konsul, iaitu, hanya lulus tatasusunan kosong. Dan kami memberitahu ejen Konsul untuk tidak menggunakan sebarang cek. Dengan semakan ini, kita boleh mengabaikan ribut rangkaian ini dan tidak memulakan pemfail.
- Pilihan lain ialah menyemak semula raft_multiplier. Ini adalah parameter pelayan Konsul itu sendiri. Secara lalai, ia ditetapkan kepada 5. Nilai ini disyorkan oleh dokumentasi untuk persekitaran pementasan. Malah, ini menjejaskan kekerapan pemesejan antara ahli rangkaian Konsul. Malah, parameter ini mempengaruhi kelajuan komunikasi perkhidmatan antara ahli kluster Konsul. Dan untuk pengeluaran, sudah disyorkan untuk mengurangkannya supaya nod bertukar mesej dengan lebih kerap.
- Pilihan lain yang kami buat ialah meningkatkan keutamaan proses Konsul antara proses lain untuk penjadual proses sistem pengendalian. Terdapat parameter "bagus", ia hanya menentukan keutamaan proses yang diambil kira oleh penjadual OS semasa menjadualkan. Kami juga telah mengurangkan nilai bagus untuk ejen Konsul, i.e. meningkatkan keutamaan supaya sistem pengendalian memberikan proses Konsul lebih masa untuk bekerja dan melaksanakan kod mereka. Dalam kes kami, ini menyelesaikan masalah kami.
- Pilihan lain ialah tidak menggunakan Konsul. Saya mempunyai seorang kawan yang merupakan penyokong besar Etcd. Dan kami kerap berdebat dengannya yang mana lebih baik Etcd atau Konsul. Tetapi dari segi mana yang lebih baik, kami biasanya bersetuju dengannya bahawa Konsul mempunyai ejen yang sepatutnya berjalan pada setiap nod dengan pangkalan data. Maksudnya, interaksi Patroni dengan kluster Konsul melalui agen ini. Dan ejen ini menjadi penyekat. Jika sesuatu berlaku kepada ejen, maka Patroni tidak boleh lagi bekerja dengan kluster Konsul. Dan inilah masalahnya. Tiada ejen dalam pelan Etcd. Patroni boleh bekerja secara langsung dengan senarai pelayan Etcd dan sudah berkomunikasi dengan mereka. Dalam hal ini, jika anda menggunakan Etcd dalam syarikat anda, maka Etcd mungkin akan menjadi pilihan yang lebih baik daripada Consul. Tetapi kami di pelanggan kami sentiasa terhad oleh apa yang pelanggan telah pilih dan gunakan. Dan kami mempunyai Konsul untuk sebahagian besar untuk semua pelanggan.
- Dan perkara terakhir adalah untuk menyemak nilai parameter. Kami boleh meningkatkan parameter ini dengan harapan bahawa masalah rangkaian jangka pendek kami akan menjadi pendek dan tidak berada di luar julat parameter ini. Dengan cara ini kita boleh mengurangkan keagresifan Patroni untuk memfailkan auto jika beberapa masalah rangkaian berlaku.
Saya rasa ramai yang menggunakan Patroni sudah biasa dengan arahan ini.
Perintah ini menunjukkan keadaan semasa kluster. Dan pada pandangan pertama, gambar ini mungkin kelihatan biasa. Kami ada tuan, kami ada replika, tiada lag replikasi. Tetapi gambar ini adalah normal sehingga kita tahu bahawa kluster ini sepatutnya mempunyai tiga nod, bukan dua.
Oleh itu, terdapat autofail. Dan selepas fail auto ini, replika kami hilang. Kita perlu mengetahui sebab dia menghilang dan membawanya kembali, memulihkannya. Dan kami sekali lagi pergi ke log dan lihat mengapa kami mempunyai auto-failover.
Dalam kes ini, replika kedua menjadi tuan. Semuanya di sini.
Dan kita perlu melihat replika yang jatuh dan yang tiada dalam kelompok. Kami membuka log Patroni dan melihat bahawa kami menghadapi masalah semasa proses menyambung ke kluster pada peringkat pg_rewind. Untuk menyambung kepada kluster, anda perlu memundurkan log transaksi, meminta log transaksi yang diperlukan daripada induk dan menggunakannya untuk mengejar induk.
Dalam kes ini, kami tidak mempunyai log transaksi dan replika tidak boleh dimulakan. Sehubungan itu, kami menghentikan Postgres dengan ralat. Dan oleh itu ia tidak berada dalam kelompok.
Kita perlu memahami mengapa ia tidak berada dalam kelompok dan mengapa tiada log. Kami pergi ke tuan baru dan melihat apa yang dia ada dalam balak. Ternyata apabila pg_rewind dilakukan, pusat pemeriksaan berlaku. Dan beberapa log transaksi lama hanya dinamakan semula. Apabila tuan lama cuba menyambung kepada tuan baharu dan menanyakan log ini, log ini telah dinamakan semula, ia tidak wujud.
Saya membandingkan cap masa apabila peristiwa ini berlaku. Dan perbezaannya ialah secara literal 150 milisaat, iaitu, pusat pemeriksaan selesai dalam 369 milisaat, segmen WAL telah dinamakan semula. Dan secara literal dalam 517, selepas 150 milisaat, putar balik bermula pada replika lama. Iaitu, secara literal 150 milisaat sudah cukup untuk kami supaya replika tidak dapat menyambung dan memperoleh pendapatan.
Apakah pilihan?
Kami pada mulanya menggunakan slot replikasi. Kami fikir ia bagus. Walaupun pada peringkat pertama operasi kami mematikan slot. Nampaknya kami jika slot terkumpul banyak segmen WAL, kami boleh menggugurkan master. Dia akan jatuh. Kami menderita untuk beberapa lama tanpa slot. Dan kami menyedari bahawa kami memerlukan slot, kami memulangkan slot.
Tetapi ada masalah di sini, apabila tuan pergi ke replika, ia memadamkan slot dan memadamkan segmen WAL bersama dengan slot. Dan untuk menghapuskan masalah ini, kami memutuskan untuk menaikkan parameter wal_keep_segments. Ia lalai kepada 8 segmen. Kami menaikkannya kepada 1 dan melihat berapa banyak ruang kosong yang kami ada. Dan kami menderma 000 gigabait untuk wal_keep_segments. Iaitu, apabila menukar, kami sentiasa mempunyai rizab 16 gigabait log transaksi pada semua nod.
Dan tambahan - ia masih relevan untuk tugas penyelenggaraan jangka panjang. Katakan kita perlu mengemas kini salah satu replika. Dan kami mahu mematikannya. Kita perlu mengemas kini perisian, mungkin sistem pengendalian, sesuatu yang lain. Dan apabila kita mematikan replika, slot untuk replika itu juga dialih keluar. Dan jika kita menggunakan segmen wal_keep_segmen, maka dengan ketiadaan replika yang lama, log transaksi akan hilang. Kami akan menaikkan replika, ia akan meminta log urus niaga tersebut di mana ia berhenti, tetapi mereka mungkin tidak berada pada induk. Dan replika itu juga tidak akan dapat disambungkan. Oleh itu, kami menyimpan stok majalah yang besar.
Kami mempunyai pangkalan pengeluaran. Sudah ada projek yang sedang dijalankan.
Terdapat seorang pemfail. Kami masuk dan melihat - semuanya teratur, replika sudah siap, tiada lag replikasi. Tiada ralat dalam log sama ada, semuanya teratur.
Pasukan produk mengatakan bahawa perlu ada beberapa data, tetapi kami melihatnya dari satu sumber, tetapi kami tidak melihatnya dalam pangkalan data. Dan kita perlu memahami apa yang berlaku kepada mereka.
Jelas sekali bahawa pg_rewind merindui mereka. Kami segera memahami perkara ini, tetapi pergi untuk melihat apa yang berlaku.
Dalam log, kita sentiasa boleh mencari apabila pemfail berlaku, siapa yang menjadi tuan, dan kita boleh menentukan siapa tuan lama dan bila dia mahu menjadi replika, iaitu kita memerlukan log ini untuk mengetahui jumlah log transaksi yang telah hilang.
Tuan lama kita telah reboot. Dan Patroni telah didaftarkan dalam autorun. Dilancarkan Patroni. Dia kemudian memulakan Postgres. Lebih tepat lagi, sebelum memulakan Postgres dan sebelum menjadikannya replika, Patroni melancarkan proses pg_rewind. Sehubungan itu, dia memadamkan sebahagian daripada log transaksi, memuat turun yang baharu dan menyambung. Di sini Patroni bekerja dengan bijak, iaitu, seperti yang diharapkan. Kelompok telah dipulihkan. Kami mempunyai 3 nod, selepas pemfail 3 nod - semuanya sejuk.
Kami telah kehilangan beberapa data. Dan kita perlu memahami berapa banyak yang kita telah rugi. Kami sedang mencari saat-saat ketika kami melakukan putar balik. Kita boleh menemuinya dalam catatan jurnal sedemikian. Putar semula bermula, melakukan sesuatu di sana dan berakhir.
Kita perlu mencari kedudukan dalam log transaksi di mana tuan lama berhenti. Dalam kes ini, ini adalah tandanya. Dan kita memerlukan tanda kedua, iaitu, jarak di mana tuan lama berbeza dari yang baru.
Kami mengambil pg_wal_lsn_diff biasa dan membandingkan kedua-dua markah ini. Dan dalam kes ini, kita mendapat 17 megabait. Banyak atau sedikit, semua orang tentukan sendiri. Kerana untuk seseorang 17 megabait tidak banyak, bagi seseorang itu banyak dan tidak boleh diterima. Di sini, setiap individu menentukan sendiri mengikut keperluan perniagaan.
Tetapi apa yang kita dapati sendiri?
Pertama, kita mesti memutuskan sendiri - adakah kita sentiasa memerlukan Patroni untuk autostart selepas but semula sistem? Ia sering berlaku bahawa kita perlu pergi ke tuan lama, lihat sejauh mana dia telah pergi. Mungkin periksa segmen log transaksi, lihat apa yang ada. Dan untuk memahami sama ada kita boleh kehilangan data ini atau sama ada kita perlu menjalankan induk lama dalam mod kendiri untuk mengeluarkan data ini.
Dan hanya selepas itu kita mesti memutuskan sama ada kita boleh membuang data ini atau kita boleh memulihkannya, sambungkan nod ini sebagai replika kepada kluster kami.
Selain itu, terdapat parameter "maximum_lag_on_failover". Secara lalai, jika ingatan saya melayani saya, parameter ini mempunyai nilai 1 megabait.
Bagaimana dia bekerja? Jika replika kami ketinggalan sebanyak 1 megabait data dalam lag replikasi, maka replika ini tidak mengambil bahagian dalam pilihan raya. Dan jika tiba-tiba berlaku fail, Patroni melihat replika mana yang ketinggalan. Jika mereka ketinggalan oleh sejumlah besar log transaksi, mereka tidak boleh menjadi tuan. Ini adalah ciri keselamatan yang sangat baik yang menghalang anda daripada kehilangan banyak data.
Tetapi terdapat masalah kerana ketinggalan replikasi dalam kelompok Patroni dan DCS dikemas kini pada selang waktu tertentu. Saya rasa 30 saat ialah nilai ttl lalai.
Sehubungan itu, mungkin terdapat situasi di mana terdapat satu lag replikasi untuk replika dalam DCS, tetapi sebenarnya mungkin terdapat lag yang sama sekali berbeza atau mungkin tiada lag sama sekali, iaitu perkara ini bukan masa nyata. Dan ia tidak selalu mencerminkan gambaran sebenar. Dan ia tidak berbaloi untuk melakukan logik mewah di atasnya.
Dan risiko kerugian sentiasa kekal. Dan dalam kes yang paling teruk, satu formula, dan dalam kes purata, formula lain. Maksudnya, apabila kita merancang pelaksanaan Patroni dan menilai berapa banyak data yang kita boleh hilang, kita mesti bergantung pada formula ini dan kira-kira berapa banyak data yang boleh kita hilang.
Dan ada berita baik. Apabila tuan lama telah pergi ke hadapan, dia boleh meneruskan kerana beberapa proses latar belakang. Iaitu, terdapat beberapa jenis autovakum, dia menulis data, menyimpannya ke log transaksi. Dan kita boleh mengabaikan dan kehilangan data ini dengan mudah. Tidak ada masalah dalam hal ini.
Dan beginilah rupa log jika maximum_lag_on_failover ditetapkan dan pemfail telah berlaku, dan anda perlu memilih induk baharu. Replika itu menilai dirinya tidak mampu untuk mengambil bahagian dalam pilihan raya. Dan dia enggan mengambil bahagian dalam perlumbaan untuk ketua. Dan dia menunggu seorang tuan baharu dipilih, supaya dia kemudiannya boleh menyambung kepadanya. Ini adalah langkah tambahan terhadap kehilangan data.
Di sini kami mempunyai pasukan produk yang menulis bahawa produk mereka menghadapi masalah dengan Postgres. Pada masa yang sama, induk itu sendiri tidak boleh diakses, kerana ia tidak tersedia melalui SSH. Dan autofile tidak berlaku sama ada.
Hos ini terpaksa but semula. Kerana but semula, fail automatik berlaku, walaupun mungkin untuk melakukan fail auto manual, seperti yang saya faham sekarang. Dan selepas but semula, kita sudah akan melihat apa yang kita ada dengan tuan semasa.
Pada masa yang sama, kami tahu terlebih dahulu bahawa kami mempunyai masalah dengan cakera, iaitu, kami sudah tahu dari memantau di mana untuk menggali dan apa yang perlu dicari.
Kami masuk ke dalam log postgres, mula melihat apa yang berlaku di sana. Kami melihat komitmen yang bertahan di sana selama satu, dua, tiga saat, yang sama sekali tidak normal. Kami melihat bahawa autovakum kami dimulakan dengan sangat perlahan dan pelik. Dan kami melihat fail sementara pada cakera. Iaitu, ini semua adalah penunjuk masalah dengan cakera.
Kami melihat ke dalam sistem dmesg (log kernel). Dan kami melihat bahawa kami mempunyai masalah dengan salah satu cakera. Subsistem cakera ialah Raid perisian. Kami melihat /proc/mdstat dan melihat bahawa kami kehilangan satu pemacu. Iaitu, terdapat Raid 8 cakera, kami kehilangan satu. Jika anda melihat dengan teliti pada slaid, maka dalam output anda dapat melihat bahawa kami tidak mempunyai sde di sana. Pada kami, secara bersyarat, cakera telah tercicir. Ini mencetuskan masalah cakera, dan aplikasi juga mengalami masalah apabila bekerja dengan kelompok Postgres.
Dan dalam kes ini, Patroni tidak akan membantu kami dalam apa cara sekalipun, kerana Patroni tidak mempunyai tugas untuk memantau keadaan pelayan, keadaan cakera. Dan kita mesti memantau situasi sedemikian dengan pemantauan luaran. Kami dengan cepat menambah pemantauan cakera pada pemantauan luaran.
Dan terdapat pemikiran sedemikian - bolehkah perisian pagar atau pengawas membantu kita? Kami menyangka bahawa dia hampir tidak akan membantu kami dalam kes ini, kerana semasa masalah Patroni terus berinteraksi dengan kluster DCS dan tidak melihat sebarang masalah. Iaitu, dari sudut pandangan DCS dan Patroni, semuanya baik-baik saja dengan kluster, walaupun sebenarnya terdapat masalah dengan cakera, terdapat masalah dengan ketersediaan pangkalan data.
Pada pendapat saya, ini adalah salah satu masalah paling pelik yang telah saya selidiki untuk masa yang lama, saya telah membaca banyak log, memilih semula dan memanggilnya simulator kluster.
Masalahnya ialah tuan lama tidak boleh menjadi replika biasa, iaitu Patroni yang memulakannya, Patroni menunjukkan bahawa nod ini hadir sebagai replika, tetapi pada masa yang sama ia bukan replika biasa. Sekarang anda akan melihat mengapa. Inilah yang saya simpan daripada analisis masalah itu.
Dan bagaimana semuanya bermula? Ia bermula, seperti dalam masalah sebelumnya, dengan brek cakera. Kami mempunyai komitmen untuk satu saat, dua.
Terdapat gangguan dalam sambungan, iaitu, pelanggan terkoyak.
Terdapat sekatan dengan keparahan yang berbeza-beza.
Dan, oleh itu, subsistem cakera tidak begitu responsif.
Dan perkara yang paling misteri bagi saya ialah permintaan penutupan segera yang tiba. Postgres mempunyai tiga mod penutupan:
- Sungguh anggun apabila kami menunggu semua pelanggan memutuskan sambungan sendiri.
- Terdapat pantas apabila kami memaksa pelanggan untuk memutuskan sambungan kerana kami akan menutup.
- Dan serta merta. Dalam kes ini, segera tidak memberitahu pelanggan untuk menutup, ia hanya menutup tanpa amaran. Dan kepada semua pelanggan, sistem pengendalian sudah menghantar mesej RST (mesej TCP bahawa sambungan terputus dan pelanggan tidak mempunyai apa-apa lagi untuk ditangkap).
Siapa yang menghantar isyarat ini? Proses latar belakang postgres tidak menghantar isyarat sedemikian kepada satu sama lain, iaitu ini adalah kill-9. Mereka tidak menghantar perkara sedemikian kepada satu sama lain, mereka hanya bertindak balas terhadap perkara sedemikian, iaitu ini adalah permulaan semula kecemasan Postgres. Siapa yang menghantarnya, saya tidak tahu.
Saya melihat arahan "terakhir" dan saya melihat seorang yang turut log masuk pelayan ini dengan kami, tetapi saya terlalu malu untuk bertanya soalan. Mungkin ia membunuh -9. Saya akan melihat membunuh -9 dalam log, kerana Postgres mengatakan ia mengambil membunuh -9, tetapi saya tidak melihatnya dalam log.
Melihat lebih jauh, saya melihat bahawa Patroni tidak menulis ke log untuk masa yang agak lama - 54 saat. Dan jika kita membandingkan dua cap masa, tiada mesej selama kira-kira 54 saat.
Dan pada masa ini terdapat autofile. Patroni melakukan kerja yang hebat di sini sekali lagi. Tuan lama kami tidak ada, sesuatu telah berlaku kepadanya. Dan pemilihan tuan baru bermula. Semuanya berjalan lancar di sini. pgsql01 kami telah menjadi pemimpin baharu.
Kami mempunyai replika yang telah menjadi tuan. Dan terdapat tindak balas kedua. Dan terdapat masalah dengan replika kedua. Dia cuba mengkonfigurasi semula. Seperti yang saya faham, dia cuba menukar recovery.conf, mulakan semula Postgres dan sambungkan kepada induk baharu. Dia menulis mesej setiap 10 saat yang dia cuba, tetapi dia tidak berjaya.
Dan semasa percubaan ini, isyarat tutup segera tiba kepada tuan lama. Master dimulakan semula. Dan juga pemulihan berhenti kerana tuan lama masuk ke but semula. Iaitu, replika tidak boleh menyambung kepadanya, kerana ia berada dalam mod penutupan.
Pada satu ketika, ia berfungsi, tetapi replikasi tidak bermula.
Satu-satunya tekaan saya ialah terdapat alamat induk lama dalam recovery.conf. Dan apabila tuan baru muncul, replika kedua masih cuba menyambung kepada tuan lama.
Apabila Patroni memulakan replika kedua, nod dimulakan tetapi tidak dapat mereplikasi. Dan ketinggalan replikasi telah terbentuk, yang kelihatan seperti ini. Iaitu, ketiga-tiga nod berada di tempatnya, tetapi nod kedua ketinggalan.
Pada masa yang sama, jika anda melihat log yang telah ditulis, anda dapat melihat bahawa replikasi tidak dapat dimulakan kerana log transaksi adalah berbeza. Dan log transaksi yang ditawarkan oleh tuan, yang dinyatakan dalam recovery.conf, tidak sesuai dengan nod semasa kami.
Dan di sini saya membuat kesilapan. Saya terpaksa datang dan melihat apa yang ada dalam pemulihan.conf untuk menguji hipotesis saya bahawa kami menyambung kepada tuan yang salah. Tetapi kemudian saya hanya berurusan dengan ini dan ia tidak berlaku kepada saya, atau saya melihat bahawa replika itu ketinggalan dan perlu diisi semula, iaitu, saya entah bagaimana bekerja dengan cuai. Ini adalah sendi saya.
Selepas 30 minit, admin sudah datang, iaitu saya memulakan semula Patroni pada replika. Saya sudah menamatkannya, saya fikir ia perlu diisi semula. Dan saya fikir - saya akan mulakan semula Patroni, mungkin sesuatu yang baik akan berlaku. Pemulihan bermula. Dan pangkalan itu dibuka, ia bersedia untuk menerima sambungan.
Replikasi telah bermula. Tetapi seminit kemudian dia jatuh dengan ralat bahawa log transaksi tidak sesuai untuknya.
Saya fikir saya akan mulakan semula. Saya memulakan semula Patroni sekali lagi, dan saya tidak memulakan semula Postgres, tetapi memulakan semula Patroni dengan harapan ia akan memulakan pangkalan data secara ajaib.
Replikasi dimulakan semula, tetapi tanda dalam log urus niaga berbeza, ia tidak sama dengan percubaan mula sebelumnya. Replikasi berhenti lagi. Dan mesejnya sudah berbeza sedikit. Dan ia tidak begitu bermaklumat untuk saya.
Dan kemudian ia berlaku kepada saya - bagaimana jika saya memulakan semula Postgres, pada masa ini saya membuat pusat pemeriksaan pada induk semasa untuk memindahkan titik dalam log transaksi sedikit ke hadapan supaya pemulihan bermula dari saat yang lain? Tambahan pula, kami masih mempunyai stok WAL.
Saya memulakan semula Patroni, melakukan beberapa pusat pemeriksaan pada master, beberapa titik mula semula pada replika apabila ia dibuka. Dan ia membantu. Saya berfikir untuk masa yang lama mengapa ia membantu dan bagaimana ia berfungsi. Dan replika itu bermula. Dan replikasi tidak lagi koyak.
Masalah seperti itu bagi saya adalah salah satu masalah yang lebih misteri, yang mana saya masih berteka-teki tentang apa yang sebenarnya berlaku di sana.
Apakah implikasi di sini? Patroni boleh bekerja seperti yang dimaksudkan dan tanpa sebarang kesilapan. Tetapi pada masa yang sama, ini bukan jaminan 100% bahawa semuanya baik-baik saja dengan kami. Replika mungkin bermula, tetapi ia mungkin dalam keadaan separuh berfungsi, dan aplikasi tidak boleh berfungsi dengan replika sedemikian, kerana akan ada data lama.
Dan selepas pemfail, anda sentiasa perlu menyemak sama ada semuanya teratur dengan kluster, iaitu, terdapat bilangan replika yang diperlukan, tidak ada lag replikasi.
Dan semasa kita melalui isu ini, saya akan membuat cadangan. Saya cuba menggabungkannya menjadi dua slaid. Mungkin, semua cerita boleh digabungkan menjadi dua slaid dan hanya diceritakan.
Apabila anda menggunakan Patroni, anda mesti mempunyai pemantauan. Anda harus sentiasa tahu bila autofileover berlaku, kerana jika anda tidak tahu anda mempunyai autofileover, anda tidak mempunyai kawalan ke atas kluster. Dan itu buruk.
Selepas setiap pemfail, kami sentiasa perlu menyemak kluster secara manual. Kami perlu memastikan bahawa kami sentiasa mempunyai bilangan replika yang terkini, tiada lag replikasi, tiada ralat dalam log yang berkaitan dengan replikasi penstriman, dengan Patroni, dengan sistem DCS.
Automasi boleh berfungsi dengan jayanya, Patroni ialah alat yang sangat baik. Ia boleh berfungsi, tetapi ini tidak akan membawa kluster ke keadaan yang dikehendaki. Dan jika kita tidak mengetahuinya, kita akan menghadapi masalah.
Dan Patroni bukan peluru perak. Kita masih perlu memahami cara Postgres berfungsi, cara replikasi berfungsi dan cara Patroni berfungsi dengan Postgres, dan cara komunikasi antara nod disediakan. Ini adalah perlu untuk dapat menyelesaikan masalah dengan tangan anda.
Bagaimanakah cara saya mendekati isu diagnosis? Kebetulan kami bekerja dengan pelanggan yang berbeza dan tiada siapa yang mempunyai timbunan ELK, dan kami perlu menyusun log dengan membuka 6 konsol dan 2 tab. Dalam satu tab, ini ialah log Patroni untuk setiap nod, dalam tab lain, ini ialah log Konsul, atau Postgres jika perlu. Sangat sukar untuk mendiagnosis ini.
Apakah pendekatan yang telah saya ambil? Pertama, saya sentiasa melihat apabila fail telah tiba. Dan bagi saya ini adalah kawasan tadahan air. Saya melihat apa yang berlaku sebelum pemfail, semasa pemfail dan selepas pemfail. Pengalihan fail mempunyai dua tanda: ini ialah masa mula dan tamat.
Seterusnya, saya melihat dalam log untuk peristiwa sebelum pemfail, yang mendahului pemfail, iaitu saya mencari sebab mengapa pemfail berlaku.
Dan ini memberikan gambaran memahami apa yang berlaku dan apa yang boleh dilakukan pada masa hadapan supaya keadaan sedemikian tidak berlaku (dan akibatnya, tidak ada pemfail).
Dan di manakah kita biasanya mencari? Saya melihat:
- Pertama, kepada log Patroni.
- Seterusnya, saya melihat log Postgres, atau log DCS, bergantung pada apa yang ditemui dalam log Patroni.
- Dan log sistem juga kadang-kadang memberi pemahaman tentang apa yang menyebabkan pemfail.
Apakah perasaan saya tentang Patroni? Saya mempunyai hubungan yang sangat baik dengan Patroni. Pada pendapat saya, ini adalah yang terbaik hari ini. Saya tahu banyak produk lain. Ini ialah Stolon, Repmgr, Pg_auto_failover, PAF. 4 alatan. Saya mencuba semuanya. Patroni adalah kegemaran saya.
Jika mereka bertanya kepada saya: "Adakah saya mengesyorkan Patroni?". Saya akan katakan ya, kerana saya suka Patroni. Dan saya rasa saya belajar cara memasaknya.
Jika anda berminat untuk melihat masalah lain yang ada dengan Patroni selain masalah yang saya nyatakan, anda sentiasa boleh menyemak halaman pada GitHub. Terdapat banyak cerita yang berbeza dan banyak isu menarik dibincangkan di sana. Dan akibatnya, beberapa pepijat telah diperkenalkan dan diselesaikan, iaitu, ini adalah bacaan yang menarik.
Terdapat beberapa cerita menarik tentang orang yang menembak diri mereka di kaki. Sangat bermaklumat. Anda membaca dan memahami bahawa tidak perlu berbuat demikian. Saya terdetik sendiri.
Dan saya ingin mengucapkan ribuan terima kasih kepada Zalando kerana membangunkan projek ini, iaitu Alexander Kukushkin dan Alexey Klyukin. Aleksey Klyukin adalah salah seorang pengarang bersama, dia tidak lagi bekerja di Zalando, tetapi ini adalah dua orang yang mula bekerja dengan produk ini.
Dan saya fikir Patroni adalah perkara yang sangat keren. Saya gembira bahawa dia wujud, ia menarik dengannya. Dan terima kasih yang tidak terhingga kepada semua penyumbang yang menulis patch kepada Patroni. Saya berharap Patroni akan menjadi lebih matang, cool dan cekap mengikut usia. Ia sudah berfungsi, tetapi saya harap ia akan menjadi lebih baik. Oleh itu, jika anda bercadang untuk menggunakan Patroni, maka jangan takut. Ini adalah penyelesaian yang baik, ia boleh dilaksanakan dan digunakan.
Itu sahaja. Jika anda mempunyai soalan, tanya.
soalan
Terima kasih atas laporan itu! Jika selepas pemfail anda masih perlu melihat di sana dengan teliti, maka mengapa kita memerlukan pemfail automatik?
Kerana ia adalah barangan baru. Kami baru setahun bersamanya. Lebih baik selamat. Kami mahu masuk dan melihat bahawa segala-galanya benar-benar berjalan seperti yang sepatutnya. Ini adalah tahap ketidakpercayaan orang dewasa - lebih baik semak semula dan lihat.
Sebagai contoh, kita pergi pada waktu pagi dan melihat, bukan?
Tidak pada waktu pagi, kami biasanya mengetahui tentang autofail dengan serta-merta. Kami menerima pemberitahuan, kami melihat bahawa fail auto telah berlaku. Kami segera pergi dan melihat. Tetapi semua semakan ini harus dibawa ke peringkat pemantauan. Jika anda mengakses Patroni melalui REST API, terdapat sejarahnya. Mengikut sejarah anda boleh melihat cap masa apabila pemfail berlaku. Berdasarkan ini, pemantauan boleh dilakukan. Anda boleh melihat sejarah, berapa banyak peristiwa yang berlaku. Jika kita mempunyai lebih banyak peristiwa, maka fail auto telah berlaku. Anda boleh pergi dan lihat. Atau automasi pemantauan kami menyemak bahawa kami mempunyai semua replika di tempatnya, tiada lag dan semuanya baik-baik saja.
Thank you!
Terima kasih banyak untuk cerita yang hebat! Jika kita memindahkan kluster DCS ke suatu tempat yang jauh dari kluster Postgres, maka kluster ini juga perlu diservis secara berkala? Apakah amalan terbaik yang beberapa bahagian kluster DCS perlu dimatikan, ada kaitan dengannya, dsb.? Bagaimanakah keseluruhan struktur ini dapat bertahan? Dan bagaimana anda melakukan perkara-perkara ini?
Untuk satu syarikat, adalah perlu untuk membuat matriks masalah, apa yang berlaku jika salah satu komponen atau beberapa komponen gagal. Menurut matriks ini, kami meneliti semua komponen secara berurutan dan membina senario sekiranya berlaku kegagalan komponen ini. Sehubungan itu, untuk setiap senario kegagalan, anda boleh mempunyai pelan tindakan untuk pemulihan. Dan dalam kes DCS, ia datang sebagai sebahagian daripada infrastruktur standard. Dan pentadbir mentadbirnya, dan kami sudah bergantung pada pentadbir yang mentadbirnya dan keupayaan mereka untuk membetulkannya sekiranya berlaku kemalangan. Jika tiada DCS sama sekali, maka kami mengerahkannya, tetapi pada masa yang sama kami tidak memantaunya secara khusus, kerana kami tidak bertanggungjawab ke atas infrastruktur, tetapi kami memberi cadangan tentang cara dan perkara yang perlu dipantau.
Iaitu, adakah saya faham dengan betul bahawa saya perlu melumpuhkan Patroni, melumpuhkan pemfail, melumpuhkan segala-galanya sebelum melakukan apa-apa dengan hos?
Ia bergantung pada bilangan nod yang kita ada dalam kelompok DCS. Jika terdapat banyak nod dan jika kita melumpuhkan hanya satu daripada nod (replika), maka kluster mengekalkan kuorum. Dan Patroni kekal beroperasi. Dan tiada apa yang dicetuskan. Jika kita mempunyai beberapa operasi kompleks yang mempengaruhi lebih banyak nod, ketiadaannya boleh merosakkan kuorum, maka - ya, mungkin masuk akal untuk meletakkan Patroni dijeda. Ia mempunyai arahan yang sepadan - patronictl pause, patronictl resume. Kami hanya menjeda dan autofiler tidak berfungsi pada masa itu. Kami melakukan penyelenggaraan pada kluster DCS, kemudian kami melepas jeda dan terus hidup.
Terima kasih banyak!
Terima kasih banyak atas laporan anda! Apakah perasaan pasukan produk tentang kehilangan data?
Pasukan produk tidak peduli dan ketua pasukan bimbang.
Apakah jaminan yang ada?
Jaminan sangat sukar. Alexander Kukushkin mempunyai laporan "Cara mengira RPO dan RTO", iaitu masa pemulihan dan berapa banyak data yang boleh hilang. Saya rasa kita perlu mencari slaid ini dan mengkajinya. Seingat saya, ada langkah-langkah khusus untuk mengira perkara-perkara ini. Berapa banyak transaksi yang boleh kita hilang, berapa banyak data yang kita boleh hilang. Sebagai pilihan, kita boleh menggunakan replikasi segerak pada peringkat Patroni, tetapi ini adalah pedang bermata dua: kita sama ada mempunyai kebolehpercayaan data, atau kita kehilangan kelajuan. Terdapat replikasi segerak, tetapi ia juga tidak menjamin perlindungan 100% terhadap kehilangan data.
Alexey, terima kasih atas laporan yang hebat! Sebarang pengalaman menggunakan Patroni untuk perlindungan tahap sifar? Iaitu, bersempena dengan siap sedia segerak? Ini adalah soalan pertama. Dan soalan kedua. Anda telah menggunakan penyelesaian yang berbeza. Kami menggunakan Repmgr, tetapi tanpa autofiler, dan kini kami merancang untuk memasukkan autofiler. Dan kami menganggap Patroni sebagai penyelesaian alternatif. Apa yang boleh anda katakan sebagai kelebihan berbanding Repmgr?
Soalan pertama ialah mengenai replika segerak. Tiada siapa yang menggunakan replikasi segerak di sini, kerana semua orang takut (Beberapa pelanggan sudah menggunakannya, pada dasarnya, mereka tidak menyedari masalah prestasi - Nota penceramah). Tetapi kami telah membangunkan peraturan untuk diri kami sendiri bahawa sekurang-kurangnya tiga nod dalam kelompok replikasi segerak, kerana jika kami mempunyai dua nod dan jika induk atau replika gagal, maka Patroni menukar nod ini kepada mod Standalone supaya aplikasi terus kerja. Dalam kes ini, terdapat risiko kehilangan data.
Mengenai soalan kedua, kami telah menggunakan Repmgr dan masih melakukannya dengan beberapa pelanggan atas sebab sejarah. Apa yang boleh dikatakan? Patroni datang dengan autofiler di luar kotak, Repmgr datang dengan autofiler sebagai ciri tambahan yang perlu didayakan. Kita perlu menjalankan daemon Repmgr pada setiap nod dan kemudian kita boleh mengkonfigurasi autofiler.
Repmgr menyemak sama ada nod Postgres masih hidup. Proses Repmgr menyemak kewujudan satu sama lain, ini bukan pendekatan yang sangat cekap. mungkin terdapat kes kompleks pengasingan rangkaian di mana gugusan Repmgr yang besar boleh berpecah kepada beberapa yang lebih kecil dan terus berfungsi. Saya sudah lama tidak mengikuti Repmgr, mungkin ia telah diperbaiki ... atau mungkin tidak. Tetapi penyingkiran maklumat tentang keadaan kluster di DCS, seperti yang dilakukan oleh Stolon, Patroni, adalah pilihan yang paling berdaya maju.
Alexey, saya ada soalan, mungkin soalan lamer. Dalam salah satu contoh pertama, anda mengalihkan DCS dari mesin tempatan ke hos jauh. Kami faham bahawa rangkaian adalah satu perkara yang mempunyai ciri-ciri tersendiri, ia hidup dengan sendiri. Dan apakah yang berlaku jika atas sebab tertentu kluster DCS menjadi tidak tersedia? Saya tidak akan memberitahu sebab-sebabnya, mungkin terdapat banyak daripada mereka: dari tangan bengkok rangkaian kepada masalah sebenar.
Saya tidak menyatakannya dengan lantang, tetapi kluster DCS juga mestilah failover, iaitu bilangan nod yang ganjil, agar kuorum dapat dipenuhi. Apakah yang berlaku jika gugusan DCS menjadi tidak tersedia, atau kuorum tidak dapat dipenuhi, iaitu sejenis perpecahan rangkaian atau kegagalan nod? Dalam kes ini, kluster Patroni masuk ke mod baca sahaja. Kluster Patroni tidak dapat menentukan keadaan kluster dan perkara yang perlu dilakukan. Ia tidak boleh menghubungi DCS dan menyimpan keadaan kluster baharu di sana, jadi keseluruhan kluster masuk ke baca sahaja. Dan menunggu sama ada campur tangan manual daripada pengendali atau DCS pulih.
Secara kasarnya, DCS menjadi perkhidmatan untuk kita sama pentingnya dengan pangkalan itu sendiri?
Ya Ya. Dalam banyak syarikat moden, Penemuan Perkhidmatan adalah sebahagian daripada infrastruktur. Ia sedang dilaksanakan walaupun sebelum terdapat pangkalan data dalam infrastruktur. Secara relatifnya, infrastruktur telah dilancarkan, digunakan di DC, dan kami serta-merta mempunyai Penemuan Perkhidmatan. Jika ia adalah Konsul, maka DNS boleh dibina di atasnya. Jika ini adalah Etcd, maka mungkin terdapat sebahagian daripada gugusan Kubernetes, di mana semua yang lain akan digunakan. Nampaknya pada saya Service Discovery sudah menjadi sebahagian daripada infrastruktur moden. Dan mereka memikirkannya lebih awal daripada tentang pangkalan data.
Thank you!
Sumber: www.habr.com