Pengenalan

Beberapa ketika dahulu saya telah diberi tugas untuk membangunkan kluster failover untuk PostgreSQL, beroperasi di beberapa pusat data yang disambungkan oleh gentian optik dalam satu bandar, dan mampu menahan kegagalan (contohnya, pemadaman) satu pusat data. Sebagai perisian yang bertanggungjawab untuk toleransi kesalahan, saya memilih Pacemakerkerana ini adalah penyelesaian rasmi daripada RedHat untuk mencipta kluster failover. Ia bagus kerana RedHat menyediakan sokongan untuknya, dan kerana penyelesaian ini bersifat universal (modular). Dengan bantuannya, adalah mungkin untuk memastikan toleransi kesalahan bukan sahaja PostgreSQL, tetapi juga perkhidmatan lain, sama ada menggunakan modul standard atau menciptanya untuk keperluan khusus.

Keputusan ini menimbulkan persoalan yang munasabah: sejauh manakah gugusan failover akan bertoleransi? Untuk menyiasat perkara ini, saya membangunkan bangku ujian yang mensimulasikan pelbagai kegagalan pada nod kluster, menunggu perkhidmatan dipulihkan, memulihkan nod yang gagal dan meneruskan ujian dalam gelung. Projek ini pada asalnya dipanggil hapgsql, tetapi lama kelamaan saya bosan dengan nama itu, yang hanya mempunyai satu vokal. Oleh itu, saya mula memanggil pangkalan data toleran kesalahan (dan IP terapung menunjuk kepada mereka) krogan (watak daripada permainan komputer di mana semua organ penting diduplikasi), dan nod, kelompok dan projek itu sendiri adalah tuchanka (planet tempat tinggal Krogan).

Kini pihak pengurusan telah membenarkan buka projek kepada komuniti sumber terbuka di bawah lesen MIT. README tidak lama lagi akan diterjemahkan ke dalam bahasa Inggeris (kerana dijangka pengguna utama adalah pembangun Perentak Jantung dan PostgreSQL), dan saya memutuskan untuk membentangkan README versi Rusia lama (sebahagiannya) dalam bentuk artikel ini.

Kelompok digunakan pada mesin maya VirtualBox. Sebanyak 12 mesin maya (jumlah 36GiB) akan digunakan, yang membentuk 4 kluster tahan kerosakan (pilihan yang berbeza). Dua kelompok pertama terdiri daripada dua pelayan PostgreSQL, yang terletak di pusat data yang berbeza, dan pelayan biasa Menyaksikan c peranti kuorum (dihoskan pada mesin maya murah di pusat data ketiga), yang menyelesaikan ketidakpastian 50% / 50%, memberikan undi anda kepada salah satu parti. Kelompok ketiga dalam tiga pusat data: satu tuan, dua hamba, tidak peranti kuorum. Kelompok keempat terdiri daripada empat pelayan PostgreSQL, dua setiap pusat data: satu induk, selebihnya replika, dan juga menggunakan Menyaksikan c peranti kuorum. Yang keempat boleh menahan kegagalan dua pelayan atau satu pusat data. Penyelesaian ini boleh ditingkatkan kepada bilangan replika yang lebih besar jika perlu.

Perkhidmatan masa yang tepat ntpd juga dikonfigurasikan semula untuk toleransi kesalahan, tetapi ia menggunakan kaedah itu sendiri ntpd (mod anak yatim). Pelayan kongsi Menyaksikan bertindak sebagai pelayan NTP pusat, mengagihkan masanya kepada semua kluster, dengan itu menyegerakkan semua pelayan antara satu sama lain. Jika Menyaksikan gagal atau menjadi terpencil, maka salah satu pelayan kluster (dalam kluster) akan mula mengagihkan masanya. Caching tambahan HTTP proksi juga dinaikkan kepada Menyaksikan, dengan bantuannya, mesin maya lain mempunyai akses kepada repositori Yum. Pada hakikatnya, perkhidmatan seperti masa dan proksi yang tepat kemungkinan besar akan dihoskan pada pelayan khusus, tetapi di gerai ia dihoskan pada Menyaksikan hanya untuk menjimatkan bilangan mesin maya dan ruang.

Versi

v0. Berfungsi dengan CentOS 7 dan PostgreSQL 11 pada VirtualBox 6.1.

Struktur kluster

Semua kluster direka bentuk untuk ditempatkan di berbilang pusat data, digabungkan menjadi satu rangkaian rata dan mesti menahan kegagalan atau pengasingan rangkaian bagi satu pusat data. sebab tu mustahil digunakan untuk perlindungan terhadap otak belah teknologi Pacemaker standard dipanggil STONITH (Tembak Nod Lain Di Kepala) atau pagar. Intipatinya: jika nod dalam kluster mula mengesyaki bahawa ada sesuatu yang tidak kena dengan sesetengah nod, ia tidak bertindak balas atau berkelakuan tidak betul, maka mereka mematikannya secara paksa melalui peranti "luar", contohnya, kad kawalan IPMI atau UPS . Tetapi ini hanya akan berfungsi dalam kes di mana, sekiranya berlaku kegagalan tunggal, pelayan IPMI atau UPS terus berfungsi. Di sini kami merancang untuk melindungi daripada kegagalan yang lebih dahsyat, apabila keseluruhan pusat data gagal (contohnya, kehilangan kuasa). Dan dengan penolakan sedemikian, semuanya stonith-peranti (IPMI, UPS, dll.) juga tidak akan berfungsi.

Sebaliknya, sistem ini berdasarkan idea kuorum. Semua nod mempunyai suara, dan hanya mereka yang boleh melihat lebih separuh daripada semua nod boleh berfungsi. Kuantiti "separuh + 1" ini dipanggil kuorum. Jika kuorum tidak tercapai, maka nod memutuskan bahawa ia berada dalam pengasingan rangkaian dan mesti mematikan sumbernya, i.e. inilah yang berlaku perlindungan otak berpecah. Jika perisian yang bertanggungjawab untuk tingkah laku ini tidak berfungsi, maka pengawas, contohnya, berdasarkan IPMI, perlu berfungsi.

Jika bilangan nod adalah genap (sekumpulan dalam dua pusat data), maka apa yang dipanggil ketidakpastian mungkin timbul 50% / 50% (lima puluh lima puluh) apabila pengasingan rangkaian membahagikan gugusan tepat pada separuh. Oleh itu, untuk bilangan nod genap, kami menambah peranti kuorum ialah daemon yang tidak menuntut yang boleh dilancarkan pada mesin maya termurah di pusat data ketiga. Dia memberikan undiannya kepada salah satu segmen (yang dia lihat), dan dengan itu menyelesaikan ketidakpastian 50%/50%. Saya menamakan pelayan di mana peranti kuorum akan dilancarkan Menyaksikan (istilah dari repmgr, saya menyukainya).

Sumber boleh dialihkan dari satu tempat ke satu tempat, contohnya, daripada pelayan yang rosak kepada yang sihat, atau atas arahan pentadbir sistem. Supaya pelanggan tahu di mana sumber yang mereka perlukan berada (di mana hendak disambungkan?), IP terapung (IP terapung). Ini adalah IP yang Pacemaker boleh bergerak di sekitar nod (semuanya berada pada rangkaian rata). Setiap daripada mereka melambangkan sumber (perkhidmatan) dan akan ditempatkan di mana anda perlu menyambung untuk mendapatkan akses kepada perkhidmatan ini (dalam kes kami, pangkalan data).

Tuchanka1 (litar dengan pemadatan)

Struktur

Ideanya ialah kami mempunyai banyak pangkalan data kecil dengan beban rendah, yang mana ia tidak menguntungkan untuk mengekalkan pelayan hamba khusus dalam mod siap sedia panas untuk transaksi baca sahaja (tidak perlu pembaziran sumber seperti itu).

Setiap pusat data mempunyai satu pelayan. Setiap pelayan mempunyai dua contoh PostgreSQL (dalam terminologi PostgreSQL ia dipanggil kluster, tetapi untuk mengelakkan kekeliruan saya akan memanggilnya contoh (dengan analogi dengan pangkalan data lain), dan saya hanya akan memanggil kluster gugusan Perentak jantung). Satu contoh beroperasi dalam mod induk, dan hanya ia menyediakan perkhidmatan (hanya IP terapung yang membawa kepadanya). Contoh kedua berfungsi sebagai hamba untuk pusat data kedua, dan akan menyediakan perkhidmatan hanya jika tuannya gagal. Oleh kerana kebanyakan masa hanya satu daripada dua (tuan) akan menyediakan perkhidmatan (melaksanakan permintaan), semua sumber pelayan dioptimumkan untuk induk (memori diperuntukkan untuk cache shared_buffers, dsb.), tetapi supaya contoh kedua juga mempunyai sumber yang mencukupi (walaupun untuk operasi suboptimum melalui cache sistem fail) sekiranya berlaku kegagalan salah satu pusat data. Hamba tidak menyediakan perkhidmatan (tidak melaksanakan permintaan baca sahaja) semasa operasi biasa kluster, supaya tiada perang untuk sumber dengan tuan pada mesin yang sama.

Dalam kes dua nod, toleransi kesalahan hanya boleh dilakukan dengan replikasi tak segerak, kerana dengan replikasi segerak, kegagalan hamba akan menyebabkan penghentian tuan.

Kegagalan untuk menyaksikan

Kegagalan untuk menyaksikan (peranti kuorum) Saya akan mempertimbangkan hanya untuk kelompok Tuchanka1, dengan semua yang lain ia akan menjadi cerita yang sama. Jika saksi gagal, tiada apa yang akan berubah dalam struktur kluster, semuanya akan terus berfungsi dengan cara yang sama. Tetapi kuorum akan menjadi 2 daripada 3, dan oleh itu sebarang kegagalan berikutnya akan membawa maut bagi kluster. Ia masih perlu diperbaiki dengan segera.

Penolakan Tuchanka1

Kegagalan salah satu pusat data untuk Tuchanka1. Dalam kes ini Menyaksikan memberikan undiannya kepada nod kedua dalam pusat data kedua. Di sana, bekas hamba bertukar menjadi tuan, akibatnya, kedua-dua tuan bekerja pada pelayan yang sama dan kedua-dua IP apungan mereka menunjuk kepada mereka.

Tuchanka2 (klasik)

Struktur

Skim klasik dua nod. Tuan bekerja pada satu, hamba pada yang kedua. Kedua-duanya boleh melaksanakan permintaan (hamba dibaca sahaja), jadi kedua-duanya ditunjuk oleh IP apungan: krogan2 ialah tuan, krogan2s1 ialah hamba. Kedua-dua tuan dan hamba akan mempunyai toleransi kesalahan.

Dalam kes dua nod, toleransi kesalahan hanya boleh dilakukan dengan replikasi tak segerak, kerana dengan replikasi segerak, kegagalan hamba akan membawa kepada penghentian tuan.

Penolakan Tuchanka2

Jika salah satu pusat data gagal Menyaksikan undi untuk yang kedua. Pada satu-satunya pusat data yang berfungsi, tuan akan dinaikkan, dan kedua-dua IP terapung akan menunjuk kepadanya: tuan dan hamba. Sudah tentu, contoh mesti dikonfigurasikan sedemikian rupa sehingga ia mempunyai sumber yang mencukupi (had sambungan, dll.) untuk menerima semua sambungan dan permintaan secara serentak daripada IP apungan tuan dan hamba. Iaitu, semasa operasi biasa ia harus mempunyai bekalan had yang mencukupi.

Tuchanka4 (banyak hamba)

Struktur

Sudah melampau lagi. Terdapat pangkalan data yang menerima banyak permintaan baca sahaja (kes tipikal tapak dengan muatan tinggi). Tuchanka4 ialah situasi di mana mungkin terdapat tiga atau lebih hamba untuk mengendalikan permintaan sedemikian, tetapi masih tidak terlalu ramai. Dengan bilangan hamba yang sangat besar, adalah perlu untuk mencipta sistem replikasi hierarki. Dalam kes minimum (dalam gambar), setiap satu daripada dua pusat data mempunyai dua pelayan, masing-masing dengan contoh PostgreSQL.

Satu lagi ciri skim ini ialah sudah mungkin untuk mengatur satu replikasi segerak. Ia dikonfigurasikan untuk mereplikasi, jika boleh, ke pusat data lain, dan bukannya replika dalam pusat data yang sama dengan induk. Tuan dan setiap hamba ditunjuk oleh IP terapung. Nasib baik, antara hamba perlu mengimbangi permintaan entah bagaimana proksi sql, sebagai contoh, di pihak pelanggan. Jenis pelanggan yang berbeza mungkin memerlukan jenis yang berbeza proksi sql, dan hanya pembangun pelanggan tahu siapa yang memerlukannya. Fungsi ini boleh dilaksanakan sama ada oleh daemon luaran atau oleh perpustakaan pelanggan (kolam sambungan), dsb. Semua ini melangkaui topik kumpulan pangkalan data failover (failover Proksi SQL boleh dilaksanakan secara bebas, bersama-sama dengan toleransi kesalahan pelanggan).

Penolakan Tuchanka4

Jika satu pusat data (iaitu, dua pelayan) gagal, saksi akan mengundi yang kedua. Akibatnya, terdapat dua pelayan yang berjalan di pusat data kedua: satu menjalankan induk, dan IP terapung induk menunjuk kepadanya (untuk menerima permintaan baca-tulis); dan pada pelayan kedua terdapat hamba berjalan dengan replikasi segerak, dan salah satu IP terapung hamba menunjuk kepadanya (untuk permintaan baca sahaja).

Perkara pertama yang perlu diperhatikan ialah tidak semua IP apungan hamba akan menjadi pekerja, tetapi hanya satu. Dan untuk bekerja dengannya dengan betul ia akan menjadi perlu itu proksi sql mengubah hala semua permintaan kepada satu-satunya IP terapung yang tinggal; dan jika proksi sql tidak, maka anda boleh menyenaraikan semua hamba IP terapung yang dipisahkan dengan koma dalam URL sambungan. Dalam kes ini, dengan libpq sambungan akan menjadi IP berfungsi pertama, ini dilakukan dalam sistem ujian automatik. Mungkin di perpustakaan lain, sebagai contoh, JDBC, ini tidak akan berfungsi dan perlu proksi sql. Ini dilakukan kerana IP apungan untuk hamba dilarang dinaikkan serentak pada satu pelayan, supaya ia diagihkan secara sama rata di antara pelayan hamba jika terdapat beberapa daripadanya berjalan.

Kedua: walaupun sekiranya berlaku kegagalan pusat data, replikasi segerak akan dikekalkan. Dan walaupun kegagalan sekunder berlaku, iaitu, salah satu daripada dua pelayan di pusat data yang tinggal gagal, kluster, walaupun ia akan berhenti menyediakan perkhidmatan, masih akan mengekalkan maklumat tentang semua transaksi yang komited yang mana ia telah memberikan pengesahan komit. (tidak akan ada maklumat kehilangan sekiranya berlaku kegagalan sekunder).

Tuchanka3 (3 pusat data)

Struktur

Ini adalah gugusan untuk situasi di mana terdapat tiga pusat data yang berfungsi sepenuhnya, setiap satunya mempunyai pelayan pangkalan data yang berfungsi sepenuhnya. Dalam kes ini peranti kuorum tidak diperlukan. Satu pusat data dikendalikan oleh seorang tuan, dua lagi dikendalikan oleh hamba. Replikasi adalah segerak, taip ANY (slave1, slave2), iaitu pelanggan akan menerima pengesahan komit apabila mana-mana hamba adalah yang pertama menjawab bahawa dia telah menerima komit. Sumber ditunjukkan oleh satu IP apungan untuk tuan dan dua untuk hamba. Tidak seperti Tuchanka4, ketiga-tiga IP apungan adalah tahan terhadap kesalahan. Untuk mengimbangi pertanyaan SQL baca sahaja yang anda boleh gunakan proksi sql (dengan toleransi kesalahan yang berasingan), atau tetapkan satu IP apungan hamba kepada separuh daripada pelanggan, dan separuh lagi kepada yang kedua.

Penolakan Tuchanka3

Jika salah satu pusat data gagal, dua kekal. Dalam satu, IP induk dan apungan daripada induk dinaikkan, pada yang kedua - IP apungan hamba dan kedua-dua hamba (contoh mesti mempunyai rizab sumber berganda untuk menerima semua sambungan daripada kedua-dua IP apungan hamba). Replikasi segerak antara tuan dan hamba. Selain itu, kluster akan menyimpan maklumat tentang transaksi yang komited dan disahkan (tidak akan ada kehilangan maklumat) sekiranya berlaku kemusnahan dua pusat data (jika ia tidak dimusnahkan serentak).

Saya memutuskan untuk tidak memasukkan penerangan terperinci tentang struktur dan penggunaan fail. Sesiapa yang nak main-main boleh baca semua dalam README. Saya hanya memberikan penerangan tentang ujian automatik.

Sistem ujian automatik

Untuk menguji toleransi kesalahan kelompok dengan mensimulasikan pelbagai kesalahan, sistem ujian automatik telah dicipta. Dilancarkan oleh skrip test/failure. Skrip boleh mengambil sebagai parameter bilangan kluster yang anda ingin uji. Contohnya arahan ini:

test/failure 2 3

hanya akan menguji kluster kedua dan ketiga. Jika parameter tidak dinyatakan, maka semua kelompok akan diuji. Semua kluster diuji secara selari, dan hasilnya dipaparkan dalam panel tmux. Tmux menggunakan pelayan tmux khusus, jadi skrip boleh dijalankan dari tmux lalai, menghasilkan tmux bersarang. Saya mengesyorkan menggunakan terminal dalam tetingkap besar dan dengan fon kecil. Sebelum ujian bermula, semua mesin maya digulung semula kepada syot kilat pada masa skrip selesai setup.

Terminal dibahagikan kepada lajur mengikut bilangan kluster yang diuji; secara lalai (dalam tangkapan skrin) terdapat empat. Saya akan menerangkan kandungan lajur menggunakan contoh Tuchanka2. Panel dalam tangkapan skrin diberi nombor:

1. Statistik ujian dipaparkan di sini. Lajur:
   • kegagalan — nama ujian (fungsi dalam skrip) yang meniru kesalahan.
   • tindak balas — purata masa aritmetik dalam saat semasa kluster memulihkan fungsinya. Ia diukur dari permulaan skrip yang meniru kesalahan sehingga saat kluster memulihkan fungsinya dan dapat meneruskan perkhidmatan. Jika masa adalah sangat singkat, contohnya, enam saat (ini berlaku dalam kelompok dengan beberapa hamba (Tuchanka3 dan Tuchanka4)), ini bermakna bahawa kesalahan adalah pada hamba tak segerak dan tidak menjejaskan prestasi dalam apa-apa cara; tidak ada suis keadaan kelompok.
   • sisihan — menunjukkan sebaran (ketepatan) nilai tindak balas menggunakan kaedah sisihan piawai.
   • mengira — berapa kali ujian ini dilakukan.
2. Log pendek membolehkan anda menilai perkara yang sedang dilakukan oleh kluster. Nombor lelaran (ujian), cap masa dan nama operasi dipaparkan. Berlari terlalu lama (> 5 minit) menunjukkan masalah.
3. jantung (hati) - masa semasa. Untuk penilaian visual prestasi master Masa semasa sentiasa ditulis pada jadualnya menggunakan induk IP terapung. Jika berjaya, hasilnya dipaparkan dalam panel ini.
4. menewaskan (nadi) - "masa semasa", yang sebelum ini direkodkan oleh skrip jantung untuk menguasai, kini baca daripada hamba melalui IP terapungnya. Membolehkan anda menilai secara visual prestasi hamba dan replikasi. Dalam Tuchanka1 tiada hamba dengan IP terapung (tiada hamba yang menyediakan perkhidmatan), tetapi terdapat dua contoh (DB), jadi ia tidak akan ditunjukkan di sini menewaskanDan jantung contoh kedua.
5. Memantau kesihatan kluster menggunakan utiliti pcs mon. Menunjukkan struktur, pengagihan sumber merentas nod dan maklumat berguna lain.
6. Pemantauan sistem daripada setiap mesin maya dalam kluster dipaparkan di sini. Mungkin terdapat lebih banyak panel sedemikian bergantung pada bilangan mesin maya yang dimiliki oleh kluster. Dua graf Beban CPU (mesin maya mempunyai dua pemproses), nama mesin maya, Beban Sistem (dinamakan Purata Beban kerana purata melebihi 5, 10 dan 15 minit), memproses data dan peruntukan memori.
7. Jejak skrip yang melakukan ujian. Sekiranya berlaku kerosakan - gangguan operasi secara tiba-tiba atau kitaran menunggu yang tidak berkesudahan - di sini anda boleh melihat sebab tingkah laku ini.

Pengujian dijalankan dalam dua peringkat. Pertama, skrip melalui semua jenis ujian, memilih mesin maya secara rawak untuk menggunakan ujian ini. Kemudian kitaran ujian yang tidak berkesudahan dilakukan, mesin maya dan kesalahan dipilih secara rawak setiap kali. Penamatan tiba-tiba skrip ujian (panel bawah) atau gelung yang tidak berkesudahan menunggu sesuatu (> 5 minit masa pelaksanaan untuk satu operasi, ini boleh dilihat dalam jejak) menunjukkan bahawa beberapa ujian pada kelompok ini telah gagal.

Setiap ujian terdiri daripada operasi berikut:

1. Lancarkan fungsi yang meniru kesalahan.
2. Sedia? — menunggu kluster dipulihkan (apabila semua perkhidmatan disediakan).
3. Menunjukkan tamat masa pemulihan kelompok (tindak balas).
4. Menetapkan — kluster sedang "dibaiki." Selepas itu ia harus kembali ke keadaan beroperasi sepenuhnya dan bersedia untuk kerosakan seterusnya.

Berikut ialah senarai ujian dengan penerangan tentang perkara yang mereka lakukan:

• ForkBomb: Mencipta "Kehabisan ingatan" menggunakan bom garpu.
• OutOfSpace: Pemacu keras penuh. Tetapi ujian itu agak simbolik; dengan beban yang tidak penting yang dibuat semasa ujian, PostgreSQL biasanya tidak gagal apabila cakera keras penuh.
• Postgres-BUNUH: membunuh PostgreSQL dengan arahan killall -KILL postgres.
• Postgres-STOP: menggantung arahan PostgreSQL killall -STOP postgres.
• Matikan: “menyahtenagakan” mesin maya dengan arahan VBoxManage controlvm "виртуалка" poweroff.
• Reset: membebankan mesin maya dengan arahan VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: menggantung syaitan SBD dengan arahan killall -STOP sbd.
• Menutup: menghantar arahan ke mesin maya melalui SSH systemctl poweroff, sistem dimatikan dengan baik.
• Nyahpaut: pengasingan rangkaian, arahan VBoxManage controlvm "виртуалка" setlinkstate1 off.

Menyelesaikan ujian sama ada menggunakan perintah tmux standard "kill-window" Ctrl-b &, atau arahan "detach-client". Ctrl-b d: pada ketika ini ujian tamat, tmux ditutup, mesin maya dimatikan.

Masalah yang dikenal pasti semasa ujian

• Pada saat ini syaitan pengawas sbd berfungsi untuk menghentikan daemon yang diperhatikan, tetapi tidak membekukannya. Dan, akibatnya, kerosakan yang membawa kepada pembekuan sahaja Corosync и Pacemaker, tetapi tidak digantung sbd... Untuk cek Corosync telah pun PR#83 (di GitHub di sbd), diterima ke benang master. Mereka berjanji (dalam PR#83) bahawa akan ada sesuatu yang serupa untuk Perentak Jantung, saya harap dengan Redhat 8 akan buat. Tetapi "kepincangan" sedemikian adalah spekulatif dan boleh disimulasikan dengan mudah secara buatan menggunakan, sebagai contoh, killall -STOP corosync, tetapi tidak pernah bertemu dalam kehidupan sebenar.

• У Pacemaker dalam versi untuk CentOS 7 tersalah set sync_timeout у peranti kuorum, Akibatnya jika satu nod gagal, dengan beberapa kebarangkalian nod kedua juga dibut semula, ke mana tuan sepatutnya berpindah. Diubati dengan pembesaran sync_timeout у peranti kuorum semasa penggunaan (dalam skrip setup/setup1). Pindaan ini tidak diterima oleh pemaju Pacemaker, sebaliknya mereka berjanji untuk mereka bentuk semula infrastruktur sedemikian rupa (pada masa hadapan yang tidak ditentukan) yang tamat masa ini akan dikira secara automatik.

• Jika konfigurasi pangkalan data menyatakan itu LC_MESSAGES (mesej teks) Unicode boleh digunakan, cth. ru_RU.UTF-8, kemudian pada permulaan postgres dalam persekitaran yang tempatnya bukan UTF-8, katakan dalam persekitaran kosong (di sini perentak jantung+pgsqlms(paf) berlari postgreskemudian log akan mengandungi tanda soal dan bukannya huruf UTF-8. Pembangun PostgreSQL belum bersetuju tentang perkara yang perlu dilakukan dalam kes ini. Ia kos, anda perlu memasang LC_MESSAGES=en_US.UTF-8 apabila mengkonfigurasi (mencipta) contoh pangkalan data.

• Jika wal_receiver_timeout ditetapkan (secara lalai ialah 60s), maka semasa ujian PostgreSQL-STOP pada induk dalam kelompok tuchanka3 dan tuchanka4 replikasi tidak menyambung semula kepada tuan baharu. Replikasi di sana adalah segerak, jadi bukan sahaja hamba berhenti, tetapi juga tuan baru. Berfungsi dengan menetapkan wal_receiver_timeout=0 apabila mengkonfigurasi PostgreSQL.

• Kadang-kadang saya melihat replikasi membeku dalam PostgreSQL dalam ujian ForkBomb (memori limpahan). Selepas ForkBomb, kadangkala hamba tidak boleh menyambung semula kepada tuan baharu. Saya hanya menemui ini dalam kelompok tuchanka3 dan tuchanka4, di mana tuannya membeku kerana replikasi segerak. Masalahnya hilang dengan sendirinya selepas masa yang lama (kira-kira dua jam). Lebih banyak penyelidikan diperlukan untuk membetulkannya. Gejala adalah serupa dengan pepijat sebelumnya, yang disebabkan oleh sebab yang berbeza, tetapi dengan akibat yang sama.

Gambar Krogan diambil dari Seni sesat dengan izin penulis:

Sumber: www.habr.com