Giriş

Bir süre önce bana bir yük devretme kümesi geliştirme görevi verildi. PostgreSQL, bir şehir içinde fiber optik ile birbirine bağlanan birkaç veri merkezinde çalışan ve bir veri merkezinin arızasına (örneğin elektrik kesintisine) dayanma kapasitesine sahip. Hata toleransından sorumlu yazılım olarak şunu seçtim: Kalp Piliçünkü bu, RedHat'ın yük devretme kümeleri oluşturmaya yönelik resmi çözümüdür. İyi çünkü RedHat buna destek sağlıyor ve bu çözüm evrensel (modüler) olduğundan. Onun yardımıyla, yalnızca PostgreSQL'in değil, aynı zamanda standart modüller kullanarak veya belirli ihtiyaçlar için bunları oluşturarak diğer hizmetlerin de hata toleransını sağlamak mümkün olacaktır.

Bu karar makul bir soruyu gündeme getirdi: Bir yük devretme kümesi ne kadar hataya dayanıklı olacak? Bunu araştırmak için, küme düğümlerindeki çeşitli arızaları simüle eden, hizmetin geri yüklenmesini bekleyen, arızalı düğümü kurtaran ve bir döngü içinde teste devam eden bir test tezgahı geliştirdim. Bu projeye başlangıçta hapgsql adı verildi, ancak zamanla yalnızca bir sesli harften oluşan addan sıkıldım. Bu nedenle hataya dayanıklı veritabanlarını (ve onlara işaret eden kayan IP'yi) çağırmaya başladım. Krogan (tüm önemli organların kopyalandığı bir bilgisayar oyunundan bir karakter) ve düğümler, kümeler ve projenin kendisi tuchanka (kroganların yaşadığı gezegen).

Artık yönetim izin verdi projeyi MIT lisansı altında açık kaynak topluluğuna açın. README yakında İngilizce'ye çevrilecek (çünkü ana tüketicilerin Pacemaker ve PostgreSQL geliştiricileri olması bekleniyor) ve ben de README'nin eski Rusça versiyonunu (kısmen) bu makale biçiminde sunmaya karar verdim.

Kümeler sanal makinelere dağıtılır VirtualBox. Hataya dayanıklı 12 küme (farklı seçenekler) oluşturan toplam 36 sanal makine (toplamda 4GiB) dağıtılacaktır. İlk iki küme, farklı veri merkezlerinde bulunan iki PostgreSQL sunucusu ve ortak bir sunucudan oluşur. Tanık c çekirdek cihazı (üçüncü bir veri merkezindeki ucuz bir sanal makinede barındırılır), bu da belirsizliği ortadan kaldırır 50% / 50%, oyunuzu taraflardan birine vermek. Üç veri merkezinde üçüncü küme: bir ana, iki ikincil, hayır çekirdek cihazı. Dördüncü küme, veri merkezi başına iki tane olmak üzere dört PostgreSQL sunucusundan oluşur: bir ana sunucu, geri kalanı kopyalar ve ayrıca Tanık c çekirdek cihazı. Dördüncüsü, iki sunucunun veya bir veri merkezinin arızasına dayanabilir. Bu çözüm gerekirse daha fazla sayıda kopyaya ölçeklendirilebilir.

Doğru zamanda hizmet ntpd ayrıca hata toleransı için yeniden yapılandırıldı, ancak yöntemin kendisini kullanıyor ntpd (yetim modu). Paylaşılan sunucu Tanık merkezi bir NTP sunucusu gibi davranarak zamanını tüm kümelere dağıtır, böylece tüm sunucuları birbiriyle senkronize eder. Eğer Tanık başarısız olursa veya izole hale gelirse, küme sunucularından biri (küme içindeki) zamanını dağıtmaya başlayacaktır. Yardımcı önbelleğe alma HTTP vekil aynı zamanda yükseltildi Tanık, onun yardımıyla diğer sanal makinelerin Yum depolarına erişimi var. Gerçekte, doğru zaman ve proxy'ler gibi hizmetler büyük olasılıkla özel sunucularda barındırılacaktır, ancak barındırıldıkları kabinde Tanık yalnızca sanal makine sayısından ve yerden tasarruf etmek için.

Sürümleri

v0. VirtualBox 7'de CentOS 11 ve PostgreSQL 6.1 ile çalışır.

Küme yapısı

Tüm kümeler, birden fazla veri merkezinde yer alacak, tek bir düz ağda birleştirilecek şekilde tasarlanmıştır ve tek bir veri merkezinin arızasına veya ağ izolasyonuna dayanması gerekir. Bu yüzden imkânsız karşı koruma için kullanın bölünmüş beyin standart Pacemaker teknolojisi denir STONİTH (Baştaki Diğer Düğümü Vurun) veya eskrim. Özü: Kümedeki düğümler, bazı düğümlerde bir sorun olduğundan, yanıt vermediğinden veya yanlış davrandığından şüphelenmeye başlarsa, o zaman onu IPMI veya UPS kontrol kartı gibi "harici" cihazlar aracılığıyla zorla kapatırlar. . Ancak bu yalnızca tek bir arıza durumunda IPMI veya UPS sunucusunun çalışmaya devam ettiği durumlarda işe yarayacaktır. Burada, tüm veri merkezinin arızalanması (örneğin güç kaybı) gibi çok daha büyük bir arızaya karşı koruma sağlamayı planlıyoruz. Ve böyle bir ret ile her şey taş-cihazlar (IPMI, UPS vb.) de çalışmayacaktır.

Bunun yerine sistem yeter sayı fikrine dayanıyor. Tüm düğümlerin bir sesi vardır ve yalnızca tüm düğümlerin yarısından fazlasını görebilenler çalışabilir. Bu miktara “yarım + 1” denir. nisap. Yeterli çoğunluk sağlanamazsa, düğüm ağ izolasyonunda olduğuna ve kaynaklarını kapatması gerektiğine karar verir; Durum bu bölünmüş beyin koruması. Bu davranıştan sorumlu olan yazılım çalışmazsa, örneğin IPMI'ya dayalı bir gözlemcinin çalışması gerekecektir.

Düğüm sayısı eşitse (iki veri merkezindeki bir küme), belirsizlik olarak adlandırılan durum ortaya çıkabilir 50% / 50% (elli elli) ağ izolasyonu kümeyi tam olarak ikiye böldüğünde. Bu nedenle, çift sayıda düğüm için şunu ekliyoruz: çekirdek cihazı üçüncü bir veri merkezindeki en ucuz sanal makinede başlatılabilen iddiasız bir arka plan programıdır. Oyu (gördüğü) segmentlerden birine verir ve böylece %50/%50 belirsizliği giderir. Çekirdek aygıtının başlatılacağı sunucunun adını verdim Tanık (repmgr terminolojisi hoşuma gitti).

Kaynaklar, örneğin arızalı sunuculardan sağlıklı sunuculara veya sistem yöneticilerinin emriyle bir yerden bir yere taşınabilir. Müşterilerin ihtiyaç duydukları kaynakların nerede bulunduğunu (nereye bağlanacaklarını) bilmeleri için, kayan IP (kayan IP). Bunlar, Pacemaker'ın düğümler arasında hareket ettirebileceği IP'lerdir (her şey düz bir ağ üzerindedir). Her biri bir kaynağı (hizmeti) sembolize eder ve bu hizmete (bizim durumumuzda bir veritabanı) erişim sağlamak için bağlanmanız gereken yerde bulunacaktır.

Tuchanka1 (sıkıştırmalı devre)

Yapı

Buradaki fikir, düşük yüklü çok sayıda küçük veri tabanına sahip olmamızdı; bu nedenle, salt okunur işlemler için özel bir ikincil sunucuyu sıcak bekleme modunda tutmanın kârlı olmadığı (böyle bir kaynak israfına gerek yoktur).

Her veri merkezinin bir sunucusu vardır. Her sunucunun iki PostgreSQL örneği vardır (PostgreSQL terminolojisinde bunlara kümeler denir, ancak karışıklığı önlemek için onlara örnekler diyeceğim (diğer veritabanlarına benzer şekilde) ve yalnızca Pacemaker kümeleri kümeleri olarak adlandıracağım). Bir örnek ana modda çalışır ve yalnızca hizmet sağlar (yalnızca kayan IP ona yol açar). İkinci bulut sunucusu, ikinci veri merkezi için köle olarak çalışır ve yalnızca yöneticisinin arızalanması durumunda hizmet sağlar. Çoğu zaman iki örnekten yalnızca biri (ana) hizmet sağlayacağından (istekleri gerçekleştireceğinden), tüm sunucu kaynakları ana sunucu için optimize edilir (bellek, paylaşılan_buffers önbelleği vb. için ayrılır), ancak ikinci örnek ayrıca veri merkezlerinden birinin arızalanması durumunda yeterli kaynağa sahiptir (dosya sistemi önbelleği aracılığıyla optimumun altında işlem için de olsa). Slave, kümenin normal çalışması sırasında hizmet sağlamaz (salt okunur istekleri gerçekleştirmez), böylece aynı makinedeki master ile kaynaklar için bir savaş olmaz.

İki düğüm olması durumunda, hata toleransı yalnızca eşzamansız çoğaltmayla mümkündür, çünkü eşzamanlı çoğaltmada bir bağımlı birimin arızalanması, ana bilgisayarın durmasına yol açacaktır.

Tanıklık yapılmaması

Şahit olmamak (çekirdek cihazı) Yalnızca Tuchanka1 kümesini ele alacağım, diğerleriyle aynı hikaye olacak. Tanık başarısız olursa küme yapısında hiçbir şey değişmeyecek, her şey aynı şekilde çalışmaya devam edecektir. Ancak çoğunluk 2 üzerinden 3 olacak ve bu nedenle daha sonraki herhangi bir başarısızlık küme için ölümcül olacaktır. Yine de acilen düzeltilmesi gerekecek.

Tuchanka1 reddi

Tuchanka1'in veri merkezlerinden birinde arıza. Bu durumda Tanık Oyunu ikinci bir veri merkezindeki ikinci bir düğüme verir. Orada, eski köle bir ustaya dönüşür, sonuç olarak her iki usta da aynı sunucuda çalışır ve her iki kayan IP'leri de onlara işaret eder.

Tuchanka2 (klasik)

Yapı

İki düğümün klasik şeması. Birinde efendi, ikincisinde köle çalışıyor. Her ikisi de istekleri yerine getirebilir (slave salt okunurdur), dolayısıyla her ikisi de kayan IP ile gösterilir: krogan2 ana, krogan2s1 ise köledir. Hem master hem deslave hata toleransına sahip olacaktır.

İki düğüm olması durumunda, hata toleransı yalnızca eşzamansız çoğaltmayla mümkündür, çünkü eşzamanlı çoğaltmada ikincil sunucunun arızalanması, ana bilgisayarın durmasına yol açacaktır.

Tuchanka2 reddi

Veri merkezlerinden biri arızalanırsa Tanık ikinciye oy verin. Çalışan tek veri merkezinde, ana birim yükseltilecek ve her iki kayan IP de ona işaret edecek: ana ve bağımlı. Elbette örneğin, ana ve yardımcı kayan IP'den gelen tüm bağlantıları ve istekleri aynı anda kabul etmek için yeterli kaynağa (bağlantı sınırları vb.) sahip olacak şekilde yapılandırılması gerekir. Yani normal çalışma sırasında yeterli miktarda limit kaynağına sahip olmalıdır.

Tuchanka4 (birçok köle)

Yapı

Zaten başka bir aşırılık. Çok sayıda salt okunur istek alan veritabanları vardır (yüksek yüklü sitelerin tipik bir örneği). Tuchanka4, bu tür istekleri yerine getirecek üç veya daha fazla kölenin bulunabileceği ancak yine de çok fazla olmayan bir durumdur. Çok sayıda köleyle hiyerarşik bir kopyalama sistemi icat etmek gerekli olacaktır. Minimum durumda (resimde), iki veri merkezinin her birinde, her biri PostgreSQL örneğine sahip iki sunucu bulunur.

Bu şemanın bir başka özelliği de, bir senkronize çoğaltmanın organize edilmesinin zaten mümkün olmasıdır. Mümkünse ana veri merkezindeki bir kopya yerine başka bir veri merkezine kopyalama yapacak şekilde yapılandırılmıştır. Master ve her bir köle, kayan bir IP ile gösterilir. Neyse ki köleler arasında istekleri bir şekilde dengelemek gerekecek SQL proxy'siörneğin istemci tarafında. Farklı müşteri türleri farklı türler gerektirebilir SQL proxy'sive yalnızca müşteri geliştiricileri kimin neye ihtiyacı olduğunu bilir. Bu işlevsellik, harici bir arka plan programı veya bir istemci kitaplığı (bağlantı havuzu) vb. tarafından uygulanabilir. Bütün bunlar yük devretme veritabanı kümesi (yük devretme) konusunun ötesine geçer SQL proxy'si istemci hata toleransıyla birlikte bağımsız olarak uygulanabilir).

Tuchanka4 reddi

Bir veri merkezi (yani iki sunucu) arızalanırsa, tanık ikinci için oy kullanır. Sonuç olarak, ikinci veri merkezinde çalışan iki sunucu vardır: biri bir ana bilgisayarı çalıştırır ve ana kayan IP ona işaret eder (okuma-yazma isteklerini almak için); ve ikinci sunucuda eşzamanlı çoğaltma ile çalışan bir ikincil öğe vardır ve bağımlı değişken IP'lerden biri ona işaret eder (salt okunur istekler için).

Unutulmaması gereken ilk şey, tüm bağımlı değişken IP'lerin işçi olacağı, yalnızca bir tanesi olacağıdır. Ve onunla doğru şekilde çalışmak için gerekli olacak SQL proxy'si tüm istekleri kalan tek kayan IP'ye yönlendirdi; ve eğer SQL proxy'si hayır, o zaman bağlantı URL'sinde tüm kayan IP bağımlı birimlerini virgüllerle ayırarak listeleyebilirsiniz. Bu durumda, libpq bağlantı ilk çalışan IP'ye yapılacaktır, bu otomatik test sisteminde yapılır. Belki diğer kütüphanelerde, örneğin JDBC'de bu işe yaramayacaktır ve gereklidir SQL proxy'si. Bunun nedeni, bağımlı sunuculara yönelik kayan IP'lerin aynı anda bir sunucuda yükseltilmesinin yasak olmasıdır, böylece birkaç tane çalışıyorsa bağımlı sunucular arasında eşit şekilde dağıtılırlar.

İkincisi: Veri merkezi arızası durumunda bile senkronize çoğaltma sürdürülecektir. İkincil bir arıza meydana gelse, yani geri kalan veri merkezindeki iki sunucudan biri arızalansa bile, küme, hizmet sağlamayı bıraksa da, taahhüt onayı verdiği tüm taahhüt edilen işlemler hakkındaki bilgileri yine de tutacaktır. (İkincil arıza durumunda kayıp bilgisi olmayacaktır).

Tuchanka3 (3 veri merkezi)

Yapı

Bu, her biri tam işlevli bir veritabanı sunucusuna sahip olan, tam işlevli üç veri merkezinin bulunduğu bir duruma yönelik bir kümedir. Bu durumda çekirdek cihazı gerekli değil. Bir veri merkezinde bir yönetici, diğer ikisinde ise köleler bulunur. Çoğaltma eşzamanlıdır, HERHANGİ BİR (slave1,slave2) yazın, yani bağımlılardan herhangi biri taahhüdü kabul ettiğine dair ilk yanıt verdiğinde müşteri bir taahhüt onayı alacaktır. Kaynaklar, ana için bir kayan IP ve yardımcılar için iki adet IP ile gösterilir. Tuchanka4'ün aksine, üç kayan IP'nin tümü hataya dayanıklıdır. Salt okunur SQL sorgularını dengelemek için kullanabilirsiniz SQL proxy'si (ayrı hata toleransıyla) veya istemcilerin yarısına bir bağımlı kayan IP, diğer yarısını da ikinciye atayın.

Tuchanka3 reddi

Veri merkezlerinden biri arızalanırsa geriye iki tane kalır. Birinde, ana sunucudan gelen ana ve kayan IP yükseltilir, ikincisinde ise bağımlı ve her iki bağımlı kayan IP'ler yükseltilir (örneğin, her iki bağımlı kayan IP'den gelen tüm bağlantıları kabul etmek için örneğin çift kaynak rezervine sahip olması gerekir). Efendiler ve köleler arasında eşzamanlı çoğaltma. Ayrıca küme, iki veri merkezinin yok edilmesi durumunda (aynı anda yok edilmezlerse) taahhüt edilen ve onaylanan işlemlerle ilgili bilgileri kaydedecektir (bilgi kaybı olmayacaktır).

Dosya yapısı ve dağıtımına ilişkin ayrıntılı bir açıklama eklememeye karar verdim. Oynamak isteyen herkes README'de hepsini okuyabilir. Yalnızca otomatik testin açıklamasını veriyorum.

Otomatik test sistemi

Çeşitli hataları simüle ederek kümelerin hata toleransını test etmek için otomatik bir test sistemi oluşturulmuştur. Komut dosyası tarafından başlatıldı test/failure. Betik, test etmek istediğiniz küme sayısını parametre olarak alabilir. Örneğin bu komut:

test/failure 2 3

yalnızca ikinci ve üçüncü kümeyi test edecektir. Parametreler belirtilmezse tüm kümeler test edilecektir. Tüm kümeler paralel olarak test edilir ve sonuç tmux panelinde görüntülenir. Tmux özel bir tmux sunucusu kullanır, böylece komut dosyası varsayılan tmux altında çalıştırılabilir ve bu da iç içe geçmiş bir tmux ile sonuçlanır. Terminali büyük bir pencerede ve küçük bir yazı tipiyle kullanmanızı öneririm. Test başlamadan önce tüm sanal makineler, komut dosyası tamamlandığında anlık görüntüye geri alınır setup.

Terminal, test edilen küme sayısına göre varsayılan olarak (ekran görüntüsünde) dört sütuna bölünmüştür; Sütunların içeriğini Tuchanka2 örneğini kullanarak anlatacağım. Ekran görüntüsündeki paneller numaralandırılmıştır:

Test istatistikleri burada görüntülenir. Sütunlar:
- başarısızlık — hatayı taklit eden testin adı (komut dosyasındaki işlev).
- tepki — kümenin işlevselliğini geri kazandığı saniye cinsinden aritmetik ortalama süre. Bir hatayı taklit eden betiğin başlangıcından, kümenin işlevselliğini geri yüklediği ve hizmet sağlamaya devam edebildiği ana kadar ölçülür. Süre çok kısaysa, örneğin altı saniye (bu, birkaç ikincil öğenin (Tuchanka3 ve Tuchanka4) olduğu kümelerde gerçekleşir), bu, hatanın eşzamansız ikincil öğede olduğu ve performansı hiçbir şekilde etkilemediği anlamına gelir; küme durumu anahtarları.
- sapma — değerin yayılmasını (doğruluğunu) gösterir tepki standart sapma yöntemini kullanarak.
- saymak — bu testin kaç kez yapıldığı.
Kısa bir günlük, kümenin o anda ne yaptığını değerlendirmenize olanak tanır. İşlemin yineleme (test) numarası, zaman damgası ve adı görüntülenir. Çok uzun süre (> 5 dakika) çalıştırmak bir sorun olduğunu gösterir.
kalp (kalp) - şimdiki zaman. Performansın görsel değerlendirmesi için direk Geçerli saat, kayan IP yöneticisi kullanılarak sürekli olarak tablosuna yazılır. Başarılı olursa sonuç bu panelde görüntülenir.
dövmek (nabız) - daha önce komut dosyası tarafından kaydedilen “geçerli saat” kalp ustalaşmak için şimdi buradan okuyun köle kayan IP'si aracılığıyla. İkincil öğenin ve çoğaltmanın performansını görsel olarak değerlendirmenize olanak tanır. Tuchanka1'de kayan IP'ye sahip köleler yoktur (hizmet sağlayan köleler yoktur), ancak iki örnek (DB'ler) vardır, bu nedenle burada gösterilmeyecektir. dövmekVe kalp ikinci örnek.
Yardımcı programı kullanarak küme sağlığını izleme pcs mon. Yapıyı, kaynakların düğümler arasındaki dağılımını ve diğer yararlı bilgileri gösterir.
Kümedeki her sanal makinenin sistem izlemesi burada görüntülenir. Kümenin kaç sanal makineye sahip olduğuna bağlı olarak bu tür panellerin sayısı daha fazla olabilir. İki grafik CPU Yükü (sanal makinelerin iki işlemcisi vardır), sanal makine adı, Sistem Yükü (5, 10 ve 15 dakikalık ortalaması alındığı için Yük Ortalaması olarak adlandırılmıştır), işlem verileri ve bellek tahsisi.
Testi gerçekleştiren betiğin izi. Bir arıza durumunda - ani bir çalışma kesintisi veya sonsuz bir bekleme döngüsü - burada bu davranışın nedenini görebilirsiniz.

Test iki aşamada gerçekleştirilir. İlk olarak, komut dosyası tüm test türlerinden geçer ve bu testin uygulanacağı sanal makineyi rastgele seçer. Daha sonra sonsuz bir test döngüsü gerçekleştirilir, sanal makineler ve arıza her seferinde rastgele seçilir. Test komut dosyasının aniden sonlandırılması (alt panel) veya bir şey için sonsuz bir bekleme döngüsü (bir işlem için> 5 dakika yürütme süresi, bu izlemede görülebilir) bu kümedeki bazı testlerin başarısız olduğunu gösterir.

Her test aşağıdaki işlemlerden oluşur:

Bir hatayı taklit eden bir işlevi başlatın.
Hazır mısınız? — kümenin geri yüklenmesinin beklenmesi (tüm hizmetler sağlandığında).
Küme kurtarma zaman aşımını gösterir (tepki).
sabit — küme "onarılıyor." Bundan sonra tamamen çalışır duruma dönmeli ve bir sonraki arızaya hazır olmalıdır.

İşte ne yaptıklarının açıklamasını içeren testlerin bir listesi:

Çatal Bomba: Çatal bombası kullanarak "Bellek yetersiz" oluşturur.
Uzay Dışı: Sabit sürücü dolu. Ancak test oldukça semboliktir; test sırasında oluşan önemsiz yük nedeniyle PostgreSQL genellikle sabit disk dolduğunda başarısız olmaz.
Postgres-KILL: PostgreSQL'i komutla öldürür killall -KILL postgres.
Postgres-DURDUR: PostgreSQL komutunu kilitler killall -STOP postgres.
Kapat: komutuyla sanal makinenin enerjisini keser VBoxManage controlvm "виртуалка" poweroff.
Reset: sanal makineyi komutla aşırı yükler VBoxManage controlvm "виртуалка" reset.
SBD-DURDURMA: SBD iblisini komutla askıya alır killall -STOP sbd.
Kapat: SSH aracılığıyla sanal makineye komut gönderir systemctl poweroff, sistem sorunsuz bir şekilde kapanıyor.
Bağlantıyı kaldır: ağ izolasyonu, komut VBoxManage controlvm "виртуалка" setlinkstate1 off.

Testin standart tmux komutu "kill-window" kullanılarak tamamlanması Ctrl-b &veya "istemciyi ayır" komutu Ctrl-b d: bu noktada test biter, tmux kapanır, sanal makineler kapatılır.

Test sırasında tespit edilen sorunlar

Şu anda, bekçi köpeği iblis sbd gözlemlenen daemonları durdurmaya çalışır, ancak onları dondurmaz. Ve bunun sonucunda sadece donmaya yol açan arızalar Korosenkronizasyon и Kalp Pili, ancak askıya almıyorum SBD. Kontrol için Korosenkronizasyon zaten sahip PR#83 (GitHub'da şu adreste: SBD), konuya kabul edildi usta. Pacemaker için de benzer bir şey olacağına söz verdiler (PR#83'te) RedHat 8 yapacak. Ancak bu tür "arızalar" spekülatiftir ve örneğin aşağıdakiler kullanılarak yapay olarak kolayca simüle edilebilir: killall -STOP corosync, ama gerçek hayatta asla tanışmayın.
У Kalp Pili için versiyonda 7 CentOS yanlış ayarlanmış senkronizasyon_zaman aşımı у çekirdek cihazısonuç olarak bir düğüm başarısız olursa, büyük olasılıkla ikinci düğüm de yeniden başlatılır, ustanın taşınması gerekiyordu. Genişletme ile tedavi edilir senkronizasyon_zaman aşımı у çekirdek cihazı dağıtım sırasında (komut dosyasında setup/setup1). Bu değişiklik geliştiriciler tarafından kabul edilmedi Kalp Pilibunun yerine altyapıyı (belirsiz bir gelecekte) bu zaman aşımının otomatik olarak hesaplanacağı şekilde yeniden tasarlama sözü verdiler.
Veritabanı yapılandırması bunu belirtiyorsa LC_MESSAGES (metin mesajları) Unicode kullanılabilir, örn. ru_RU.UTF-8, ardından başlangıçta postgres yerel ayarın UTF-8 olmadığı bir ortamda, örneğin boş bir ortamda (burada kalp pili+pgsqlm'ler(paf) koşar postgres), o zaman günlükte UTF-8 harfleri yerine soru işaretleri bulunacak. PostgreSQL geliştiricileri bu durumda ne yapılacağı konusunda anlaşamadılar. Maliyeti var, yüklemeniz gerekiyor LC_MESSAGES=en_US.UTF-8 bir veritabanı örneğini yapılandırırken (oluştururken).
wal_receiver_timeout ayarlanmışsa (varsayılan olarak 60 saniyedir), tuchanka3 ve tuchanka4 kümelerindeki ana makinede PostgreSQL-STOP testi sırasında çoğaltma yeni ana bilgisayara yeniden bağlanmıyor. Çoğaltma orada eşzamanlıdır, yani yalnızca bağımlı değil, aynı zamanda yeni yönetici de durur. PostgreSQL'i yapılandırırken wal_receiver_timeout=0 ayarını yaparak bu sorunu çözebilirsiniz.
Bazen ForkBomb testinde PostgreSQL'de çoğaltma donmalarını gözlemledim (bellek taşması). ForkBomb'dan sonra bazen köleler yeni efendiye yeniden bağlanamayabilir. Bununla yalnızca ana sunucunun eşzamanlı çoğaltma nedeniyle donduğu tuchanka3 ve tuchanka4 kümelerinde karşılaştım. Uzun bir süre sonra (yaklaşık iki saat) sorun kendiliğinden ortadan kalktı. Bunu düzeltmek için daha fazla araştırmaya ihtiyaç vardır. Belirtiler, farklı bir nedenden kaynaklanan ancak aynı sonuçlara sahip olan önceki hataya benzer.