Giriş

Bir müddət əvvəl mənə uğursuz klaster hazırlamaq tapşırığı verildi PostgreSQL, bir şəhər daxilində optik liflə birləşdirilən bir neçə məlumat mərkəzində fəaliyyət göstərən və bir məlumat mərkəzinin nasazlığına (məsələn, söndürülməsinə) tab gətirə bilir. Arızaya dözümlülükdən məsul olan proqram olaraq mən seçdim Kardiostimulyatoraçünki bu, RedHat-ın uğursuz klasterlər yaratmaq üçün rəsmi həllidir. Bu yaxşıdır, çünki RedHat ona dəstək verir və bu həll universaldır (moduldur). Onun köməyi ilə yalnız PostgreSQL-in deyil, həm də standart modullardan istifadə etməklə və ya onları xüsusi ehtiyaclar üçün yaratmaqla digər xidmətlərin də nasazlığa dözümlülüyünü təmin etmək mümkün olacaq.

Bu qərar ağlabatan sual doğurdu: uğursuzluq klasteri nasazlığa nə dərəcədə dözümlü olacaq? Bunu araşdırmaq üçün mən klaster qovşaqlarında müxtəlif nasazlıqları simulyasiya edən, xidmətin bərpa olunmasını gözləyən, uğursuz nodu bərpa edən və dövrədə sınaqdan keçirməyə davam edən bir sınaq dəzgahı hazırladım. Bu layihə əvvəlcə hapgsql adlanırdı, lakin zaman keçdikcə yalnız bir sait olan addan bezdim. Buna görə də, mən xətaya dözümlü verilənlər bazalarını çağırmağa başladım (və onlara işarə edən float IP) kroqan (bütün vacib orqanların təkrarlandığı kompüter oyunundan personaj) və qovşaqlar, klasterlər və layihənin özü tuçanka (kroqanların yaşadığı planet).

İndi rəhbərlik icazə verib MIT lisenziyası altında layihəni açıq mənbə ictimaiyyətinə açın. README tezliklə ingilis dilinə tərcümə olunacaq (çünki əsas istehlakçıların Kardiostimulyator və PostgreSQL tərtibatçıları olacağı gözlənilir) və mən README-nin köhnə rus versiyasını (qismən) bu məqalə şəklində təqdim etmək qərarına gəldim.

Klasterlər virtual maşınlarda yerləşdirilir VirtualBox. Cəmi 12 virtual maşın (ümumilikdə 36GiB) yerləşdiriləcək ki, bunlar 4 xətaya dözümlü klaster (müxtəlif seçimlər) təşkil edir. İlk iki klaster müxtəlif məlumat mərkəzlərində yerləşən iki PostgreSQL serverindən və ümumi serverdən ibarətdir. şahid c kvorum cihazı (üçüncü məlumat mərkəzində ucuz virtual maşında yerləşdirilir), qeyri-müəyyənliyi həll edir 50% / 50%, səsinizi partiyalardan birinə vermək. Üç məlumat mərkəzində üçüncü klaster: bir master, iki qul, yox kvorum cihazı. Dördüncü klaster dörd PostgreSQL serverindən ibarətdir, hər bir məlumat mərkəzinə ikisi: bir master, qalan replika və həmçinin istifadə edir. şahid c kvorum cihazı. Dördüncüsü iki serverin və ya bir məlumat mərkəzinin uğursuzluğuna tab gətirə bilər. Lazım gələrsə, bu həll daha çox sayda replikaya qədər genişləndirilə bilər.

Dəqiq vaxt xidməti ntpd həmçinin xətaya dözümlülük üçün yenidən konfiqurasiya edilib, lakin o, metodun özündən istifadə edir ntpd (yetim rejimi). Paylaşılan server şahid mərkəzi NTP serveri kimi çıxış edir, vaxtını bütün klasterlərə paylayır və bununla da bütün serverləri bir-biri ilə sinxronlaşdırır. Əgər şahid uğursuz olarsa və ya təcrid olunarsa, klaster serverlərindən biri (klaster daxilində) vaxtını paylamağa başlayacaq. Köməkçi keşləmə HTTP proxy də yüksəldi şahid, onun köməyi ilə digər virtual maşınlar Yum depolarına çıxış əldə edir. Əslində, dəqiq vaxt və etibarnamələr kimi xidmətlər çox güman ki, ayrılmış serverlərdə yerləşdiriləcək, lakin stenddə onlar yerləşdirilir. şahid yalnız virtual maşınların sayını və məkanı saxlamaq üçün.

Süjetlər

v0. VirtualBox 7-də CentOS 11 və PostgreSQL 6.1 ilə işləyir.

Klaster quruluşu

Bütün klasterlər birdən çox məlumat mərkəzlərində yerləşmək, bir düz şəbəkədə birləşdirmək üçün nəzərdə tutulmuşdur və bir məlumat mərkəzinin uğursuzluğuna və ya şəbəkə izolyasiyasına tab gətirməlidir. Buna görə də mümkün deyil qarşı qorunmaq üçün istifadə edin bölünmüş beyin standart Kardiostimulyator texnologiyası adlanır STONIT (Başındakı Digər Nodu Çək) və ya qılıncoynatma. Onun mahiyyəti: əgər çoxluqdakı qovşaqlar hansısa node ilə nəyinsə səhv olduğundan şübhələnməyə başlayırsa, o, cavab vermir və ya düzgün davranmır, o zaman onu “xarici” qurğular, məsələn, IPMI və ya UPS idarəetmə kartı vasitəsilə zorla söndürürlər. . Ancaq bu, yalnız bir uğursuzluq halında IPMI və ya UPS serverinin işləməyə davam etdiyi hallarda işləyəcək. Burada biz bütün məlumat mərkəzi sıradan çıxdıqda (məsələn, enerjini itirdikdə) daha fəlakətli nasazlıqdan qorunmağı planlaşdırırıq. Və belə bir imtina ilə hər şey daş daş-cihazlar (IPMI, UPS və s.) da işləməyəcək.

Bunun əvəzinə sistem kvorum ideyasına əsaslanır. Bütün qovşaqların səsi var və yalnız bütün qovşaqların yarısından çoxunu görə bilənlər işləyə bilər. Bu “yarım + 1” kəmiyyəti adlanır kvorum. Əgər kvorum əldə edilmirsə, onda node şəbəkə izolyasiyasında olduğuna qərar verir və öz resurslarını söndürməlidir, yəni. bu da budur split beyin qorunması. Bu davranışa cavabdeh olan proqram işləmirsə, məsələn, IPMI-yə əsaslanan bir nəzarətçi işləməli olacaq.

Əgər qovşaqların sayı cütdürsə (iki məlumat mərkəzində çoxluq), onda qeyri-müəyyənlik yarana bilər. 50% / 50% (əlli əlli) şəbəkə izolyasiyası klasteri tam olaraq yarıya böldükdə. Buna görə də, cüt sayda qovşaq üçün əlavə edirik kvorum cihazı üçüncü məlumat mərkəzində ən ucuz virtual maşında işə salına bilən qeyri-adi demondur. O, səsini seqmentlərdən birinə (gördüyü) verir və bununla da 50%/50% qeyri-müəyyənliyi həll edir. Kvorum cihazının işə salınacağı serverin adını verdim şahid (repmgr-dən terminologiya, bəyəndim).

Resurslar bir yerdən başqa yerə, məsələn, nasaz serverlərdən sağlam olanlara və ya sistem administratorlarının əmri ilə köçürülə bilər. Beləliklə, müştərilər ehtiyac duyduqları resursların harada yerləşdiyini bilsinlər (hara qoşulmalı?), üzən IP (float IP). Bunlar kardiostimulyatorun qovşaqlar ətrafında hərəkət edə biləcəyi IP-lərdir (hər şey düz şəbəkədədir). Onların hər biri resursu (xidməti) simvollaşdırır və bu xidmətə (bizim vəziyyətimizdə verilənlər bazası) daxil olmaq üçün qoşulmağınız lazım olan yerdə yerləşdiriləcək.

Tuchanka1 (sıxlaşdırma ilə dövrə)

Struktur

İdeya ondan ibarət idi ki, bizdə aşağı yüklə çoxlu kiçik verilənlər bazalarımız var, bunun üçün yalnız oxunan əməliyyatlar üçün xüsusi qul serverini qaynar gözləmə rejimində saxlamaq sərfəli deyil (resursların belə israfına ehtiyac yoxdur).

Hər bir məlumat mərkəzində bir server var. Hər bir serverdə iki PostgreSQL nümunəsi var (PostgreSQL terminologiyasında onlar klasterlər adlanır, lakin çaşqınlığın qarşısını almaq üçün mən onları nümunələr adlandıracağam (digər verilənlər bazaları ilə analoji olaraq) və mən yalnız Kardiostimulyator klasterlərini klaster adlandıracağam). Bir nümunə master rejimində işləyir və yalnız o, xidmətlər təqdim edir (yalnız float IP ona aparır). İkinci instansiya ikinci məlumat mərkəzi üçün qul kimi işləyir və yalnız master uğursuz olarsa xidmət göstərəcək. Çox vaxt iki nümunədən yalnız biri (master) xidmətlər göstərəcəyindən (sorğuları yerinə yetirir), bütün server resursları master üçün optimallaşdırılır (yaddaş paylaşılan_buffers keşi və s. üçün ayrılır), lakin ikinci instansiya məlumat mərkəzlərindən birinin nasazlığı halında kifayət qədər resursa malikdir (fayl sisteminin önbelleği vasitəsilə suboptimal işləməyə baxmayaraq). Qul, klasterin normal işləməsi zamanı xidmət göstərmir (yalnız oxunan sorğuları yerinə yetirmir), belə ki, eyni maşında master ilə resurslar üçün müharibə olmasın.

İki qovşaq vəziyyətində, nasazlığa dözümlülük yalnız asinxron replikasiya ilə mümkündür, çünki sinxron replikasiya ilə qulun uğursuzluğu masterın dayanmasına səbəb olacaqdır.

Şahid olmamaq

Şahid olmamaq (kvorum cihazı) Mən yalnız Tuchanka1 klasterini nəzərdən keçirəcəyəm, digərləri ilə eyni hekayə olacaq. Şahid uğursuz olarsa, klaster strukturunda heç nə dəyişməyəcək, hər şey olduğu kimi işləməyə davam edəcək. Lakin kvorum 2-dən 3-si olacaq və buna görə də hər hansı bir sonrakı uğursuzluq çoxluq üçün ölümcül olacaq. Hələ təcili olaraq düzəldilməli olacaq.

Tuchanka1 imtina

Tuchanka1 üçün məlumat mərkəzlərindən birinin uğursuzluğu. Bu halda şahid səsini ikinci məlumat mərkəzindəki ikinci qovşaq üçün verir. Orada keçmiş qul ustaya çevrilir, nəticədə hər iki master eyni serverdə işləyir və hər iki float IP-ləri onlara işarə edir.

Tuchanka2 (klassik)

Struktur

İki node klassik sxemi. Birində usta, ikincisində qul işləyir. Hər ikisi sorğuları yerinə yetirə bilər (qul yalnız oxunur), buna görə də hər ikisi float IP ilə işarələnir: krogan2 master, krogan2s1 quldur. Həm ağa, həm də qul qüsura dözümlü olacaq.

İki qovşaq vəziyyətində, nasazlığa dözümlülük yalnız asinxron replikasiya ilə mümkündür, çünki sinxron təkrarlama ilə qulun uğursuzluğu masterun dayanmasına səbəb olacaqdır.

Tuchanka2 imtina

Məlumat mərkəzlərindən biri uğursuz olarsa şahid ikinciyə səs verir. Yeganə işləyən məlumat mərkəzində master qaldırılacaq və hər iki float IP onu göstərəcək: master və qul. Təbii ki, instansiya elə konfiqurasiya edilməlidir ki, eyni zamanda master və slave float IP-dən gələn bütün əlaqələri və sorğuları qəbul etmək üçün kifayət qədər resurslara (qoşulma məhdudiyyətləri və s.) malik olsun. Yəni, normal işləmə zamanı kifayət qədər limit təchizatı olmalıdır.

Tuchanka4 (çoxlu qul)

Struktur

Artıq başqa bir ifrat. Çoxlu yalnız oxumaq üçün sorğu alan verilənlər bazaları var (yüksək yüklənmiş saytın tipik halı). Tuchanka4, bu cür sorğuları idarə etmək üçün üç və ya daha çox qulun ola biləcəyi bir vəziyyətdir, lakin hələ də çox deyil. Çox sayda kölə ilə iyerarxik təkrarlama sistemi icad etmək lazım gələcək. Minimum halda (şəkildə) iki məlumat mərkəzinin hər birində PostgreSQL nümunəsi olan iki server var.

Bu sxemin başqa bir xüsusiyyəti ondan ibarətdir ki, artıq bir sinxron replikasiya təşkil etmək mümkündür. Mümkünsə, master ilə eyni məlumat mərkəzindəki replikaya deyil, başqa məlumat mərkəzinə təkrarlamaq üçün konfiqurasiya edilmişdir. Usta və hər bir qul üzən IP ilə işarələnir. Xoşbəxtlikdən, qullar arasında istəkləri bir şəkildə tarazlaşdırmaq lazım olacaq sql proxyməsələn, müştəri tərəfində. Müxtəlif növ müştərilər fərqli növlər tələb edə bilər sql proxy, və yalnız müştəri tərtibatçıları kimin nəyə ehtiyacı olduğunu bilirlər. Bu funksionallıq ya xarici daemon, ya da müştəri kitabxanası (bağlantı hovuzu) və s. tərəfindən həyata keçirilə bilər. Bütün bunlar uğursuz verilənlər bazası klasterinin (failover SQL proxy müştərinin günaha dözümlülüyü ilə birlikdə müstəqil şəkildə həyata keçirilə bilər).

Tuchanka4 imtina

Bir məlumat mərkəzi (yəni, iki server) uğursuz olarsa, şahid ikinciyə səs verir. Nəticədə, ikinci məlumat mərkəzində işləyən iki server var: biri master işləyir və master float IP onu göstərir (oxumaq-yazmaq sorğularını qəbul etmək üçün); ikinci serverdə isə sinxron replikasiya ilə işləyən slave var və qul float IP-lərindən biri ona işarə edir (yalnız oxumaq üçün sorğular üçün).

Qeyd etmək lazım olan ilk şey odur ki, bütün qul float IP-ləri işçi olmayacaq, ancaq birdir. Və onunla düzgün işləmək üçün lazım olacaq sql proxy bütün sorğuları qalan yeganə float IP-yə yönləndirdi; və əgər sql proxy yox, onda siz əlaqə URL-də vergüllə ayrılmış bütün float IP qullarını sadalaya bilərsiniz. Bu halda, ilə libpq əlaqə ilk işləyən IP-yə olacaq, bu avtomatik sınaq sistemində edilir. Ola bilsin ki, digər kitabxanalarda, məsələn, JDBC-də bu işləməyəcək və zəruridir sql proxy. Bu ona görə edilir ki, qullar üçün float IP-lərinin eyni vaxtda bir serverdə qaldırılması qadağandır, belə ki, bir neçə işlək vəziyyətdədirsə, onlar qul serverləri arasında bərabər paylansın.

İkincisi: məlumat mərkəzinin nasazlığı halında belə, sinxron replikasiya qorunacaq. Və hətta ikinci dərəcəli nasazlıq baş versə, yəni qalan məlumat mərkəzindəki iki serverdən biri sıradan çıxsa belə, klaster xidmətlərin göstərilməsini dayandırsa da, öhdəliyin təsdiqini verdiyi bütün əməliyyatlar haqqında məlumatları saxlayacaqdır. (ikinci dərəcəli nasazlıq halında itki haqqında məlumat olmayacaq).

Tuchanka3 (3 məlumat mərkəzi)

Struktur

Bu, hər biri tam işləyən verilənlər bazası serverinə malik olan üç tam fəaliyyət göstərən məlumat mərkəzinin olduğu vəziyyət üçün klasterdir. Bu halda kvorum cihazı lazım deyil. Bir məlumat mərkəzində usta, digər ikisində isə qullar işləyir. Replikasiya sinxrondur, HƏR HƏR (slave1, slave2) növüdür, yəni qullardan hər hansı biri öhdəliyi qəbul etdiyinə ilk cavab verəndə müştəri öhdəlik təsdiqini alacaq. Resurslar master üçün bir float IP və iki qul üçün göstərilir. Tuchanka4-dən fərqli olaraq, hər üç float IP xətaya dözümlüdür. Yalnız oxumaq üçün SQL sorğularını balanslaşdırmaq üçün istifadə edə bilərsiniz sql proxy (ayrı-ayrı nasazlıqlara dözümlülük ilə) və ya müştərilərin yarısına bir slave float IP təyin edin, digər yarısı isə ikinci.

Tuchanka3 imtina

Məlumat mərkəzlərindən biri uğursuz olarsa, ikisi qalır. Birində master-dan master və float IP-i qaldırılır, ikincidə - qul və hər iki slave float IP-ləri (nümunə hər iki slave float IP-dən bütün əlaqələri qəbul etmək üçün ikiqat resurslar ehtiyatına malik olmalıdır). Ustalar və qullar arasında sinxron replikasiya. Həmçinin, klaster iki məlumat mərkəzinin məhv edilməsi halında (eyni vaxtda məhv edilmədikdə) törədilmiş və təsdiqlənmiş əməliyyatlar haqqında məlumatları (məlumat itkisi olmayacaq) saxlayacaq.

Mən fayl strukturunun və yerləşdirilməsinin ətraflı təsvirini daxil etməməyə qərar verdim. Oynamaq istəyən hər kəs hamısını README-də oxuya bilər. Mən yalnız avtomatlaşdırılmış testin təsvirini təqdim edirəm.

Avtomatik sınaq sistemi

Müxtəlif nasazlıqları simulyasiya etməklə klasterlərin nasazlığa dözümlülüyünü yoxlamaq üçün avtomatik sınaq sistemi yaradılmışdır. Skriptlə işə salınıb test/failure. Skript sınamaq istədiyiniz klasterlərin sayını parametr kimi qəbul edə bilər. Məsələn, bu əmr:

test/failure 2 3

yalnız ikinci və üçüncü klasteri sınaqdan keçirəcək. Parametrlər göstərilməyibsə, bütün klasterlər sınaqdan keçiriləcək. Bütün klasterlər paralel olaraq sınaqdan keçirilir və nəticə tmux panelində göstərilir. Tmux xüsusi tmux serverindən istifadə edir, buna görə də skript standart tmux altında işlədilə bilər, nəticədə iç içə tmux yaranır. Mən terminalı böyük pəncərədə və kiçik şriftlə istifadə etməyi məsləhət görürəm. Sınaq başlamazdan əvvəl, bütün virtual maşınlar skriptin tamamlandığı anda snapshota qaytarılır. setup.

Terminal sınaqdan keçirilən klasterlərin sayına görə sütunlara bölünür; standart olaraq (ekran görüntüsündə) dörd ədəd var. Tuchanka2 nümunəsindən istifadə edərək sütunların məzmununu təsvir edəcəyəm. Ekran görüntüsündəki panellər nömrələnir:

1. Test statistikası burada göstərilir. Sütunlar:
   • uğursuzluq — xətanı təqlid edən testin adı (skriptdəki funksiya).
   • reaksiya — klasterin öz funksionallığını bərpa etdiyi saniyələrlə hesablanmış orta vaxt. Bu, nasazlığı təqlid edən skriptin başlanğıcından klasterin öz funksionallığını bərpa etdiyi və xidmətləri göstərməyə davam edə bildiyi ana qədər ölçülür. Əgər vaxt çox qısadırsa, məsələn, altı saniyə (bu, bir neçə qul olan qruplarda baş verir (Tuchanka3 və Tuchanka4)), bu, nasazlığın asinxron qulda olduğunu və heç bir şəkildə performansa təsir etmədiyini bildirir; klaster vəziyyəti açarları.
   • sapma — qiymətin yayılmasını (dəqiqliyini) göstərir reaksiya standart sapma metodundan istifadə etməklə.
   • saymaq - bu test neçə dəfə aparılıb.
2. Qısa jurnal klasterin hazırda nə etdiyini qiymətləndirməyə imkan verir. İterasiya (test) nömrəsi, vaxt möhürü və əməliyyatın adı göstərilir. Çox uzun (> 5 dəqiqə) qaçmaq problem olduğunu göstərir.
3. ürək (ürək) - cari vaxt. Performansın vizual qiymətləndirilməsi üçün usta Cari vaxt float IP master istifadə edərək daim öz cədvəlinə yazılır. Uğurlu olarsa, nəticə bu paneldə göstərilir.
4. döymək (nəbz) - əvvəllər skript tərəfindən qeydə alınmış "cari vaxt" ürək master etmək, indidən oxumaq qul float IP vasitəsilə. Qul və təkrarlamanın işini vizual olaraq qiymətləndirməyə imkan verir. Tuchanka1-də float IP olan qullar yoxdur (xidmət göstərən qullar yoxdur), lakin iki nümunə (DB) var, ona görə də burada göstərilməyəcək döyməkVə ürək ikinci instansiya.
5. Utilitydən istifadə edərək klaster sağlamlığının monitorinqi pcs mon. Quruluşunu, resursların qovşaqlar üzrə paylanmasını və digər faydalı məlumatları göstərir.
6. Klasterdəki hər bir virtual maşından sistem monitorinqi burada göstərilir. Klasterin neçə virtual maşının olmasından asılı olaraq belə panellər daha çox ola bilər. İki qrafik CPU yükü (virtual maşınların iki prosessoru var), virtual maşının adı, Sistem yükü (5, 10 və 15 dəqiqə ərzində orta hesabla götürüldüyü üçün Yük Ortası adlandırılır), emal məlumatları və yaddaşın ayrılması.
7. Testi həyata keçirən skriptin izi. Bir nasazlıq halında - işin qəfil kəsilməsi və ya sonsuz gözləmə dövrü - burada bu davranışın səbəbini görə bilərsiniz.

Sınaq iki mərhələdə aparılır. Birincisi, skript təsadüfi olaraq bu testin tətbiq olunacağı virtual maşını seçərək bütün növ testlərdən keçir. Sonra sonsuz bir sınaq dövrü həyata keçirilir, virtual maşınlar və nasazlıq hər dəfə təsadüfi seçilir. Test skriptinin qəfil dayandırılması (alt panel) və ya nəyisə gözləməyin sonsuz döngəsi (bir əməliyyat üçün > 5 dəqiqə icra müddəti, bunu izdə görmək olar) bu klasterdəki bəzi testlərin uğursuz olduğunu göstərir.

Hər bir test aşağıdakı əməliyyatlardan ibarətdir:

1. Arızanı təqlid edən funksiyanı işə salın.
2. Hazır? — klasterin bərpasını gözləmək (bütün xidmətlər təqdim edildikdə).
3. Klasterin bərpa müddətini göstərir (reaksiya).
4. Fix — klaster “təmir olunur”. Bundan sonra o, tam işlək vəziyyətə qayıtmalı və növbəti nasazlığa hazır olmalıdır.

Nə etdiklərinin təsviri ilə testlərin siyahısı:

• ForkBomb: Çəngəl bombasından istifadə edərək "Yaddaş tükəndi" yaradır.
• OutOfSpace: Sərt disk doludur. Lakin test olduqca simvolikdir; sınaq zamanı yaranan əhəmiyyətsiz yüklə PostgreSQL ümumiyyətlə sabit disk dolu olduqda uğursuz olmur.
• Postgres - ÖLDÜR: əmri ilə PostgreSQL-i öldürür killall -KILL postgres.
• Postgres-STOP: PostgreSQL əmrini bağlayır killall -STOP postgres.
• Söndürmək: əmri ilə virtual maşını "enerjisizləşdirir" VBoxManage controlvm "виртуалка" poweroff.
• Sıfırla: virtual maşını əmrlə həddən artıq yükləyir VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: əmri ilə SBD demonunu dayandırır killall -STOP sbd.
• Söndür: SSH vasitəsilə virtual maşına əmr göndərir systemctl poweroff, sistem zərif şəkildə bağlanır.
• Bağlantını kəsin: şəbəkə izolyasiyası, əmr VBoxManage controlvm "виртуалка" setlinkstate1 off.

Standart tmux "kill-window" əmrindən istifadə edərək testi tamamlamaq Ctrl-b &, və ya "ayrılmaq-müştəri" əmri Ctrl-b d: bu anda test başa çatır, tmux bağlanır, virtual maşınlar söndürülür.

Test zamanı müəyyən edilmiş problemlər

• Hazırda gözətçi cin sbd müşahidə olunan demonları dayandırmaq üzərində işləyir, lakin onları dondurmur. Və nəticədə yalnız donmağa səbəb olan nasazlıqlar Korosinx и Kardiostimulyatora, amma asılmır sbd. Çek üçün Korosinx artıq var PR # 83 (GitHub-da sbd), mövzuya qəbul edildi ustad. Onlar (PR # 83-də) söz verdilər ki, ürək stimulyatoru üçün oxşar bir şey olacaq, ümid edirəm ki Qırmızı papaq 8 edəcək. Ancaq bu cür "nasazlıqlar" spekulyativdir və məsələn, istifadə edərək asanlıqla süni şəkildə simulyasiya edilə bilər. killall -STOP corosync, amma real həyatda heç vaxt görüşmürəm.

• У Kardiostimulyatora üçün versiyada CentOS 7 səhv təyin edilmişdir sync_timeout у kvorum cihazı, nəticə olaraq bir node uğursuz olarsa, müəyyən ehtimalla ikinci node da yenidən başladı, ustanın hərəkət etməli olduğu yerə. Böyütmə ilə müalicə olunur sync_timeout у kvorum cihazı yerləşdirmə zamanı (skriptdə setup/setup1). Bu düzəliş tərtibatçılar tərəfindən qəbul edilmədi Kardiostimulyatora, əvəzində onlar infrastrukturu elə bir şəkildə (bəzi qeyri-müəyyən gələcəkdə) yenidən dizayn edəcəklərini vəd etdilər ki, bu fasilə avtomatik olaraq hesablansın.

• Əgər verilənlər bazası konfiqurasiyası bunu müəyyən edirsə LC_MESSAGES (mətn mesajları) Unicode istifadə edilə bilər, məs. ru_RU.UTF-8, sonra başlanğıcda postgres yerlinin UTF-8 olmadığı bir mühitdə, deyək ki, boş bir mühitdə (burada ürəyiniz+pgsqlms(paf) qaçır postgres) sonra jurnalda UTF-8 hərfləri yerinə sual işarələri olacaq. PostgreSQL tərtibatçıları bu halda nə etmək barədə razılığa gəlməyiblər. Xərclidir, quraşdırmaq lazımdır LC_MESSAGES=en_US.UTF-8 verilənlər bazası nümunəsini konfiqurasiya edərkən (yaratdıqda).

• wal_receiver_timeout təyin edilibsə (defolt olaraq 60 saniyədir), onda postgreSQL-STOP testi zamanı tuchanka3 və tuchanka4 klasterlərində master replikasiya yeni master ilə yenidən əlaqə yaratmır. Orada replikasiya sinxrondur, ona görə də təkcə qul deyil, həm də yeni usta dayanır. PostgreSQL-i konfiqurasiya edərkən wal_receiver_timeout=0 təyin etməklə işləyir.

• Bəzən ForkBomb testində PostgreSQL-də replikasiyanın donmasını müşahidə etdim (yaddaşın daşması). ForkBomb-dan sonra bəzən qullar yeni ustaya yenidən qoşulmaya bilər. Mən bununla yalnız tuchanka3 və tuchanka4 klasterlərində rastlaşmışam, burada master sinxron replikasiyaya görə donub. Problem uzun müddət (təxminən iki saat) sonra öz-özünə keçdi. Bunu düzəltmək üçün daha çox araşdırma lazımdır. Semptomlar fərqli bir səbəbdən yaranan, lakin eyni nəticələrə malik olan əvvəlki səhvə bənzəyir.

Kroqan şəkli Deviant Sənət müəllifin icazəsi ilə:

Mənbə: www.habr.com