Patroninin əsas məqsədi PostgreSQL üçün yüksək əlçatanlığı təmin etməkdir. Lakin Patroni hazır alət deyil (ümumiyyətlə, sənədlərdə deyilir) sadəcə şablondur. İlk baxışdan Patroni-ni sınaq laboratoriyasında quraşdırdıqdan sonra onun nə qədər gözəl alət olduğunu və çoxluğu pozmaq cəhdlərimizi necə asanlıqla idarə etdiyini görə bilərsiniz. Bununla belə, praktikada istehsal mühitində hər şey həmişə sınaq laboratoriyasındakı kimi gözəl və zərif şəkildə baş vermir.
Sizə bir az özüm haqqında danışacağam. Mən sistem administratoru kimi başlamışam. Veb inkişafında işləyib. 2014-cü ildən Data Egret-də işləyirəm. Şirkət Postgres sahəsində konsaltinqlə məşğuldur. Və biz tam olaraq Postgres-ə xidmət edirik və hər gün Postgres ilə işləyirik, buna görə də əməliyyatla bağlı müxtəlif təcrübəmiz var.
Və 2018-ci ilin sonunda biz Patroni-dən yavaş-yavaş istifadə etməyə başladıq. Və müəyyən təcrübə toplanıb. Biz birtəhər diaqnoz qoyduq, köklədik, ən yaxşı təcrübələrimizə gəldik. Və bu hesabatda onlar haqqında danışacağam.
Postgres-dən başqa mən Linux-u sevirəm. Mən onun ətrafında dolaşmağı və araşdırmağı, nüvələr toplamağı xoşlayıram. Mən virtuallaşdırmanı, konteynerləri, docker, Kubernetes-i sevirəm. Bütün bunlar məni maraqlandırır, çünki köhnə admin vərdişləri təsir edir. Mən monitorinqlə məşğul olmağı xoşlayıram. Mən postgres administrasiyası ilə əlaqəli şeyləri, yəni replikasiya, ehtiyat nüsxəsini sevirəm. Boş vaxtlarımda isə Go-da yazıram. Mən proqram mühəndisi deyiləm, sadəcə Go-da özüm üçün yazıram. Və bu mənə həzz verir.
- Düşünürəm ki, bir çoxunuz Postgres-də HA (High Availability) olmadığını bilirsiniz. HA almaq üçün nəyisə quraşdırmaq, konfiqurasiya etmək, səy göstərmək və əldə etmək lazımdır.
- Bir neçə alət var və Patroni HA-nı olduqca sərin və çox yaxşı həll edən onlardan biridir. Ancaq hamısını sınaq laboratoriyasına qoyaraq və onu işə salmaqla, hər şeyin işlədiyini görə bilərik, bəzi problemləri təkrarlaya bilərik, Patroninin onlara necə xidmət etdiyini görə bilərik. Və hər şeyin əla işlədiyini görəcəyik.
- Amma praktikada fərqli problemlərlə üzləşdik. Və bu problemlərdən danışacağam.
- Mən sizə necə diaqnoz qoyduğumuzu, nəyi düzəltdiyimizi söyləyəcəyəm - bizə kömək edib-etmədi.
- Mən sizə Patroninin necə qurulacağını söyləməyəcəyəm, çünki İnternetdə google-a baxa bilərsiniz, hər şeyin necə başladığını, necə konfiqurasiya edildiyini başa düşmək üçün konfiqurasiya fayllarına baxa bilərsiniz. İnternetdə bu barədə məlumat tapmaqla sxemləri, arxitekturaları başa düşə bilərsiniz.
- Başqasının təcrübəsindən danışmayacağam. Mən ancaq üzləşdiyimiz problemlərdən danışacağam.
- Mən Patroni və PostgreSQL xaricində olan problemlərdən danışmayacağam. Məsələn, balanslaşdırma ilə bağlı problemlər varsa, klasterimiz dağılanda, mən bu barədə danışmayacağam.
Hesabatımıza başlamazdan əvvəl kiçik bir imtina.
Qarşılaşdığımız bütün bu problemlər fəaliyyətimizin ilk 6-7-8 ayında yaşadıq. Zamanla biz daxili ən yaxşı təcrübələrimizə gəldik. Və problemlərimiz aradan qalxdı. Buna görə də hesabat təxminən altı ay əvvəl açıqlandı, o vaxt hər şey beynimdə təzə idi və hamısını mükəmməl xatırladım.
Hesabatı hazırlayarkən mən artıq köhnə postmortemləri qaldırdım, loglara baxdım. Və problemlərin təhlili zamanı bəzi təfərrüatlar unudula bilərdi, yaxud bəzi detallar tam araşdırıla bilmədi, ona görə də bəzi məqamlarda elə görünə bilər ki, problemlər tam nəzərdən keçirilmir, yaxud müəyyən qədər informasiya çatışmazlığı var. Və buna görə də bu an üçün məni bağışlamanızı xahiş edirəm.
Patroni nədir?
- Bu HA qurmaq üçün şablondur. Sənədlərdə belə deyilir. Və mənim nöqteyi-nəzərimdən bu, çox düzgün aydınlaşdırmadır. Patroni bütün problemlərinizi həll edəcək gümüş güllə deyil, yəni onun işləməsi və fayda gətirməsi üçün səy göstərmək lazımdır.
- Bu, hər bir verilənlər bazası xidmətində quraşdırılmış agent xidmətidir və Postgres üçün bir növ başlanğıc sistemidir. Postgres-i işə salır, dayandırır, yenidən işə salır, yenidən konfiqurasiya edir və klasterinizin topologiyasını dəyişir.
- Müvafiq olaraq, klasterin vəziyyətini, onun cari təqdimatını saxlamaq üçün, göründüyü kimi, bir növ yaddaş lazımdır. Və bu baxımdan Patroni dövlətin xarici sistemdə saxlanması yolunu tutdu. Bu paylanmış konfiqurasiya saxlama sistemidir. Bu, Etcd, Consul, ZooKeeper və ya kubernetes Etcd ola bilər, yəni bu seçimlərdən biri.
- Patroninin xüsusiyyətlərindən biri də odur ki, avtomatik doldurucunu qutudan çıxara bilərsiniz, yalnız onu quraşdırmaqla. Müqayisə üçün Repmgr-i götürsək, onda fayl ora daxil edilir. Repmgr ilə biz keçid əldə edirik, lakin avtofiler istəsək, onu əlavə olaraq konfiqurasiya etməliyik. Patroni artıq qutudan çıxmış avtomatik doldurucuya malikdir.
- Və bir çox başqa şeylər var. Məsələn, konfiqurasiyaların saxlanması, yeni replikaların tökülməsi, ehtiyat nüsxəsi və s.. Amma bu, hesabatın əhatə dairəsindən kənardır, bu barədə danışmayacağam.
Kiçik bir nəticə ondan ibarətdir ki, Patroninin əsas vəzifəsi avtofaylı yaxşı və etibarlı şəkildə etməkdir ki, klasterimiz işlək qalsın və tətbiq klaster topologiyasındakı dəyişiklikləri görməsin.
Ancaq Patroni istifadə etməyə başlayanda sistemimiz bir az daha mürəkkəbləşir. Əgər əvvəllər bizdə Postgres var idisə, Patroni istifadə edərkən biz Patroninin özünü alırıq, dövlətin saxlandığı yerdə DCS alırıq. Və hər şey bir şəkildə işləməlidir. Beləliklə, nə səhv ola bilər?
Qırıla bilər:
- Postgres pozula bilər. Bu master və ya replika ola bilər, onlardan biri uğursuz ola bilər.
- Patroninin özü qırıla bilər.
- Vəziyyətin saxlandığı DCS pozula bilər.
- Və şəbəkə pozula bilər.
Hesabatda bütün bu məqamları nəzərdən keçirəcəyəm.
Mən işin bir çox komponentləri ehtiva etdiyi nöqteyi-nəzərdən deyil, onlar mürəkkəbləşdikcə baxacağam. Və subyektiv hisslər baxımından bu iş mənim üçün çətin idi, onu sökmək çətin idi ... və əksinə, bəzi iş yüngül idi və onu sökmək asan idi.
Və birinci hal ən asandır. Bu, verilənlər bazası klasterini götürüb DCS yaddaşımızı eyni klasterdə yerləşdirdiyimiz zaman belədir. Bu ən çox yayılmış səhvdir. Bu, arxitekturaların qurulmasında, yəni müxtəlif komponentlərin bir yerdə birləşdirilməsində səhvdir.
Deməli, filler var idi, gedək baş verənlərlə məşğul olaq.
Və burada biz filerin nə vaxt baş verdiyi ilə maraqlanırıq. Yəni, biz klaster vəziyyətinin dəyişdiyi zamanla maraqlanırıq.
Ancaq doldurucu həmişə ani deyil, yəni heç bir vaxt vahidi tələb etmir, gecikdirilə bilər. Uzunmüddətli ola bilər.
Buna görə də onun başlanğıc və bitmə vaxtı var, yəni davamlı bir hadisədir. Və biz bütün hadisələri üç intervala bölürük: doldurucudan əvvəl, doldurma zamanı və fayldan sonra vaxtımız var. Yəni biz bütün hadisələri bu zaman qrafikində nəzərə alırıq.
Və ilk şey, filler baş verəndə, baş verənlərin səbəbini axtarırıq, fillerə səbəb olan şeyin səbəbi nədir.
Günlüklərə baxsaq, onlar klassik Patroni logları olacaq. Onlarda bizə deyir ki, server ustaya çevrilib və master rolu bu qovşağa keçib. Burada vurğulanır.
Sonra, faylın niyə baş verdiyini, yəni master rolunun bir qovşaqdan digərinə keçməsinə səbəb olan hadisələrin baş verdiyini başa düşməliyik. Və bu vəziyyətdə hər şey sadədir. Yaddaş sistemi ilə qarşılıqlı əlaqədə xəta var. Usta DCS ilə işləyə bilməyəcəyini başa düşdü, yəni qarşılıqlı əlaqədə bir növ problem var. Və deyir ki, daha usta ola bilməz və istefa verir. Bu “rütbəsi aşağı salınmış özünü” xətti məhz bunu deyir.
Filerdən əvvəl baş verən hadisələrə baxsaq, problemin sehrbazı davam etdirməsinə səbəb olan səbəbləri görə bilərik.
Patroni qeydlərinə baxsaq görərik ki, bizdə çoxlu səhvlər, fasilələr var, yəni Patroni agenti DCS ilə işləyə bilmir. Bu halda, bu, 8500 portunda əlaqə saxlayan Konsul agentidir.
Və burada problem Patroninin və verilənlər bazasının eyni hostda işləməsidir. Konsul serverləri də eyni qovşaqda işə salındı. Serverdə yük yaratmaqla Konsul serverləri üçün də problemlər yaratdıq. Düzgün ünsiyyət qura bilmirdilər.
Bir müddət sonra yük səngiyəndə Patronumuz yenidən agentlərlə əlaqə saxlaya bildi. Normal iş bərpa edildi. Və eyni Pgdb-2 serveri yenidən master oldu. Yəni kiçik bir sürüşmə var idi, buna görə düyün ustanın səlahiyyətlərini tərk etdi və sonra onları yenidən aldı, yəni hər şey olduğu kimi geri döndü.
Və bu, yanlış həyəcan siqnalı kimi qəbul edilə bilər və ya Patroninin hər şeyi düzgün etdiyi hesab edilə bilər. Yəni klasterin vəziyyətini saxlaya bilməyəcəyini anladı və səlahiyyətlərini kənarlaşdırdı.
Və burada problem konsul serverlərinin bazalarla eyni aparatda olması səbəbindən yaranıb. Müvafiq olaraq, hər hansı bir yük: istər disklər, istərsə də prosessorlardakı yük, Konsul klasteri ilə qarşılıqlı əlaqəyə də təsir göstərir.
Biz qərara gəldik ki, bu, bir yerdə yaşamasın, konsul üçün ayrıca klaster ayırdıq. Və Patroni artıq ayrıca Konsulla işləyirdi, yəni ayrıca Postgres klasteri, ayrıca Konsul klasteri var idi. Bu, bütün bunları birlikdə yaşamamaq üçün necə daşımaq və saxlamaq barədə əsas təlimatdır.
Bir seçim olaraq, ttl, loop_wait, retry_timeout parametrlərini bükə bilərsiniz, yəni bu parametrləri artırmaqla bu qısamüddətli yük piklərindən sağ çıxmağa çalışın. Ancaq bu ən uyğun seçim deyil, çünki bu yük zamanla uzun ola bilər. Və biz sadəcə olaraq bu parametrlərin bu hüdudlarından kənara çıxacağıq. Və bu, həqiqətən kömək etməyə bilər.
Birinci problem, başa düşdüyünüz kimi, sadədir. DCS-ni götürüb baza ilə bir yerə qoyduq, problem yarandı.
İkinci problem birinciyə bənzəyir. DCS sistemi ilə yenidən qarşılıqlı fəaliyyətlə bağlı problemlərimiz var.
Günlüklərə baxsaq, yenə də ünsiyyət xətamız olduğunu görərik. Və Patroni deyir ki, mən DCS ilə əlaqə saxlaya bilmirəm, ona görə də cari master replika rejiminə keçir.
Köhnə usta bir nüsxəyə çevrilir, burada Patroni olduğu kimi işləyir. Əməliyyat jurnalını geri çəkmək üçün pg_rewind işləyir və sonra yeni master ilə əlaqə saxlamaq üçün yeni master-a qoşulur. Burada Patroni lazım olduğu kimi işləyir.
Burada biz filerdən əvvəl olan yeri, yəni bizə fayl yaratmağa səbəb olan səhvləri tapmalıyıq. Və bu baxımdan, Patroni jurnalları ilə işləmək olduqca rahatdır. Eyni mesajları müəyyən intervalla yazır. Və əgər biz bu logları sürətlə sürüşməyə başlasaq, o zaman loglardan logların dəyişdiyini görərik, yəni bəzi problemlər başlayıb. Tez bu yerə qayıdırıq, gör nə baş verir.
Və normal bir vəziyyətdə, loglar bu kimi görünür. Kilidin sahibi yoxlanılır. Və əgər sahibi, məsələn, dəyişibsə, Patroninin cavab verməli olduğu bəzi hadisələr baş verə bilər. Ancaq bu vəziyyətdə biz yaxşıyıq. Səhvlərin başladığı yeri axtarırıq.
Səhvlərin görünməyə başladığı nöqtəyə keçdikdən sonra avtomatik fayl köçürməmizin olduğunu görürük. Səhvlərimiz DCS ilə qarşılıqlı əlaqə ilə bağlı olduğundan və bizim vəziyyətimizdə Konsuldan istifadə etdiyimiz üçün Konsul qeydlərinə də baxırıq, orada baş verənlər.
Filer vaxtını və Konsul qeydlərindəki vaxtı kobud şəkildə müqayisə etsək, görürük ki, Konsul klasterindəki qonşularımız Konsul klasterinin digər üzvlərinin mövcudluğuna şübhə etməyə başladılar.
Digər konsul agentlərinin qeydlərinə baxsanız, orada bir növ şəbəkə çökməsinin olduğunu da görə bilərsiniz. Konsul klasterinin bütün üzvləri bir-birinin varlığına şübhə ilə yanaşırlar. Və bu filler üçün təkan oldu.
Bu səhvlərdən əvvəl baş verənlərə baxsanız, görə bilərsiniz ki, hər cür səhvlər var, məsələn, son tarix, RPC düşdü, yəni konsul klasterinin üzvlərinin bir-biri ilə qarşılıqlı əlaqəsində bir növ problem var. .
Ən sadə cavab şəbəkəni təmir etməkdir. Amma mənim üçün podiumda dayanaraq bunu demək asandır. Lakin vəziyyət elədir ki, həmişə müştərinin şəbəkəni təmir etməyə imkanı olmur. O, DC-də yaşaya bilər və şəbəkəni təmir edə bilməz, avadanlıqlara təsir göstərə bilməz. Və buna görə də başqa variantlara ehtiyac var.
Seçimlər var:
- Mənim fikrimcə, hətta sənədlərdə yazılmış ən sadə seçim Konsul çeklərini söndürməkdir, yəni sadəcə boş bir massivdən keçməkdir. Biz isə konsul agentinə deyirik ki, heç bir çekdən istifadə etməsin. Bu yoxlamalarla biz bu şəbəkə fırtınalarına məhəl qoymaya bilərik və faylları işə salmaya bilərik.
- Başqa bir seçim raft_multiplier-i iki dəfə yoxlamaqdır. Bu, Konsul serverinin özünün parametridir. Defolt olaraq, o, 5-ə təyin edilmişdir. Bu dəyər quruluş mühitləri üçün sənədlər tərəfindən tövsiyə olunur. Əslində bu, Konsul şəbəkəsinin üzvləri arasında mesajlaşma tezliyinə təsir edir. Əslində, bu parametr Konsul klasterinin üzvləri arasında xidmət əlaqəsinin sürətinə təsir göstərir. İstehsal üçün isə artıq onu azaltmaq tövsiyə olunur ki, qovşaqlar daha tez-tez mesaj mübadiləsi etsinlər.
- Qarşılaşdığımız başqa bir seçim əməliyyat sisteminin proses planlayıcısı üçün digər proseslər arasında Konsul proseslərinin prioritetini artırmaqdır. Belə bir "gözəl" parametr var, sadəcə planlaşdırma zamanı OS planlaşdırıcısı tərəfindən nəzərə alınan proseslərin prioritetini müəyyənləşdirir. Konsul agentləri üçün gözəl dəyəri də aşağı saldıq, yəni. prioriteti artırdı ki, əməliyyat sistemi Konsul proseslərə kodlarını işləmək və icra etmək üçün daha çox vaxt versin. Bizim vəziyyətimizdə bu, problemimizi həll etdi.
- Digər seçim isə Konsuldan istifadə etməməkdir. Etcd-nin böyük dəstəkçisi olan bir dostum var. Və biz müntəzəm olaraq onunla mübahisə edirik, hansının daha yaxşıdır, yoxsa Konsul. Ancaq hansının daha yaxşı olduğuna gəlincə, biz onunla razılaşırıq ki, konsulun hər bir qovşaqda verilənlər bazası ilə işləməli olan agenti var. Yəni Patroninin Konsul klasteri ilə qarşılıqlı əlaqəsi bu agentdən keçir. Və bu agent darboğaza çevrilir. Agentin başına nəsə olarsa, Patroni daha Konsul klasteri ilə işləyə bilməz. Və bu problemdir. Etcd planında heç bir agent yoxdur. Patroni birbaşa Etcd serverlərinin siyahısı ilə işləyə və artıq onlarla əlaqə saxlaya bilər. Bu baxımdan, şirkətinizdə Etcd istifadə etsəniz, o zaman Etcd Konsuldan daha yaxşı seçim olacaq. Lakin biz müştərilərimizdə həmişə müştərinin seçdiyi və istifadə etdiyi şeylərlə məhdudlaşırıq. Və bütün müştərilər üçün konsulumuz var.
- Və son nöqtə parametr dəyərlərini yenidən nəzərdən keçirməkdir. Qısamüddətli şəbəkə problemlərimizin qısa olacağı və bu parametrlərin əhatə dairəsindən kənara çıxmayacağı ümidi ilə bu parametrləri yüksəldə bilərik. Bu yolla, bəzi şəbəkə problemləri baş verərsə, Patroninin avtomatik fayla aqressivliyini azalda bilərik.
Məncə, Patroni istifadə edənlərin çoxu bu əmrlə tanışdır.
Bu əmr klasterin cari vəziyyətini göstərir. Və ilk baxışda bu şəkil normal görünə bilər. Ustamız var, replikamız var, replikasiya gecikməsi yoxdur. Ancaq bu çoxluqda iki deyil, üç qovşaq olması lazım olduğunu bilənə qədər bu şəkil normaldır.
Müvafiq olaraq, avtomatik fayl var idi. Və bu avtomatik fayldan sonra replikamız itdi. Biz onun niyə yoxa çıxdığını öyrənib geri qaytarmalı, bərpa etməliyik. Və biz yenidən qeydlərə gedirik və niyə avtomatik fayl köçürməmizin olduğunu görürük.
Bu vəziyyətdə ikinci replika usta oldu. Burada hər şey qaydasındadır.
Və biz yıxılan və çoxluqda olmayan replikaya baxmalıyıq. Patroni loglarını açırıq və pg_rewind mərhələsində klasterə qoşulma prosesində problemlə üzləşdiyimizi görürük. Klasterə qoşulmaq üçün siz əməliyyat jurnalını geri çevirməli, masterdən tələb olunan əməliyyat jurnalını tələb etməli və ondan master ilə görüşmək üçün istifadə etməlisiniz.
Bu halda, əməliyyat jurnalımız yoxdur və replika başlaya bilməz. Müvafiq olaraq, Postgres-i xəta ilə dayandırırıq. Və buna görə də çoxluqda deyil.
Niyə klasterdə olmadığını və niyə logların olmadığını başa düşməliyik. Yeni ustanın yanına gedirik və loglarda nə olduğuna baxırıq. Məlum olub ki, pg_rewind işləri görüləndə yoxlama nöqtəsi yaranıb. Və bəzi köhnə əməliyyat qeydləri sadəcə olaraq dəyişdirildi. Köhnə usta yeni ustaya qoşulmağa və bu jurnalları sorğulamağa çalışdıqda, onlar artıq adlandırılmışdılar, sadəcə mövcud deyildilər.
Bu hadisələr baş verəndə vaxt nişanlarını müqayisə etdim. Və orada fərq sözün əsl mənasında 150 millisaniyədir, yəni keçid məntəqəsi 369 millisaniyədə tamamlandı, WAL seqmentlərinin adı dəyişdirildi. Və sözün əsl mənasında 517-də, 150 millisaniyədən sonra köhnə replikada geri sarma başladı. Yəni replikanın qoşulub qazana bilməməsi üçün sözün əsl mənasında 150 millisaniyə bizim üçün kifayət idi.
Seçimlər hansılardır?
Əvvəlcə replikasiya yuvalarından istifadə etdik. Yaxşı olduğunu düşündük. Baxmayaraq ki, əməliyyatın ilk mərhələsində biz yuvaları söndürdük. Bizə elə gəldi ki, slotlarda çoxlu WAL seqmentləri toplanırsa, biz masterı buraxa bilərik. O düşəcək. Slotsuz bir müddət əziyyət çəkdik. Və anladıq ki, bizə slot lazımdır, biz slotları qaytardıq.
Ancaq burada bir problem var ki, master replikaya gedəndə yuvaları silir və yuvalarla birlikdə WAL seqmentlərini də silir. Və bu problemi aradan qaldırmaq üçün wal_keep_segments parametrini yüksəltmək qərarına gəldik. Standart olaraq 8 seqmentdir. Biz onu 1-ə qaldırdıq və nə qədər boş yerimiz olduğuna baxdıq. Və biz wal_keep_segments üçün 000 gigabayt hədiyyə etdik. Yəni, keçid zamanı bizdə həmişə bütün qovşaqlarda 16 giqabaytlıq əməliyyat qeydləri ehtiyatı olur.
Və plus - uzunmüddətli texniki xidmət tapşırıqları üçün hələ də aktualdır. Tutaq ki, replikalardan birini yeniləmək lazımdır. Və biz onu söndürmək istəyirik. Proqram təminatını, bəlkə əməliyyat sistemini, başqa bir şeyi yeniləmək lazımdır. Biz replikanı söndürdükdə həmin replikanın yuvası da silinir. Kiçik bir wal_keep_segments istifadə etsək, uzun müddət replika olmadıqda, əməliyyat qeydləri itiriləcəkdir. Biz replika qaldıracağıq, o, dayandırıldığı yerdə əməliyyat qeydlərini tələb edəcək, lakin onlar master-da olmaya bilər. Və replika da qoşula bilməyəcək. Buna görə də biz böyük jurnal ehtiyatı saxlayırıq.
Bizim istehsal bazamız var. Artıq icra olunan layihələr var.
Filler var idi. İçəri girdik və baxdıq - hər şey qaydasındadır, replikalar yerindədir, replikasiyada gecikmə yoxdur. Jurnallarda da heç bir xəta yoxdur, hər şey qaydasındadır.
Məhsul komandası deyir ki, bəzi məlumatlar olmalıdır, lakin biz bunu bir mənbədən görürük, lakin verilənlər bazasında görmürük. Və onların başına gələnləri başa düşməliyik.
Aydındır ki, pg_rewind onları qaçırdı. Biz bunu dərhal başa düşdük, amma nə baş verdiyini görmək üçün getdik.
Qeydlərdə biz həmişə fayl verənin nə vaxt baş verdiyini, kimin usta olduğunu tapa bilərik və kimin köhnə usta olduğunu və onun nə vaxt replika olmaq istədiyini müəyyən edə bilərik, yəni əməliyyat qeydlərinin miqdarını öyrənmək üçün bizə bu qeydlər lazımdır. itirildi.
Köhnə ustamız yenidən başladı. Və Patroni avtorunda qeydiyyatdan keçdi. Patroni işə saldı. Sonra Postgres-ə başladı. Daha dəqiq desək, Postgres-ə başlamazdan əvvəl və onun nüsxəsinə çevrilməzdən əvvəl Patroni pg_rewind prosesini işə saldı. Müvafiq olaraq, əməliyyat qeydlərinin bir hissəsini sildi, yenilərini endirdi və qoşuldu. Burada Patroni ağıllı işləyirdi, yəni gözlənildiyi kimi. Klaster bərpa olunub. 3 qovşaqımız var idi, doldurucudan sonra 3 qovşaq - hər şey sərindir.
Bəzi məlumatları itirmişik. Və nə qədər itirdiyimizi başa düşməliyik. Biz sadəcə geri çəkildiyimiz anı axtarırıq. Biz bunu belə jurnal yazılarında tapa bilərik. Geri sarma başladı, orada bir şey etdi və bitdi.
Əməliyyat jurnalında köhnə ustanın qaldığı yeri tapmalıyıq. Bu vəziyyətdə işarədir. Və bizə ikinci bir işarə lazımdır, yəni köhnə ustanın yenisindən fərqləndiyi məsafə.
Biz adi pg_wal_lsn_diff götürürük və bu iki işarəni müqayisə edirik. Və bu halda biz 17 meqabayt alırıq. Çox və ya az, hər kəs özü üçün qərar verir. Çünki kimsə üçün 17 meqabayt çox deyil, kimsə üçün çox və qəbuledilməzdir. Burada hər bir fərd biznesin ehtiyaclarına uyğun olaraq özü üçün müəyyən edir.
Bəs biz özümüz üçün nə tapdıq?
Birincisi, özümüz qərar verməliyik - sistemin yenidən başlamasından sonra Patroninin avtomatik işə salınmasına həmişə ehtiyacımız varmı? Tez-tez elə olur ki, qoca ustanın yanına getməliyik, gör nə qədər irəli gedib. Bəlkə əməliyyat jurnalının seqmentlərini yoxlayın, orada nə olduğuna baxın. Və bu məlumatları itirə biləcəyimizi və ya bu məlumatları çıxarmaq üçün köhnə masterı müstəqil rejimdə işə salmağımız lazım olub olmadığını anlamaq üçün.
Və yalnız bundan sonra biz qərar verməliyik ki, bu məlumatları ləğv edə bilərik, yoxsa onu bərpa edə bilərik, bu nodu replika olaraq klasterimizə birləşdirə bilərik.
Bundan əlavə, "maksimum_lag_on_failover" parametri var. Varsayılan olaraq, yaddaşım mənə xidmət edirsə, bu parametrin dəyəri 1 meqabaytdır.
O necə işləyir? Əgər replikamız replikasiya gecikməsində 1 meqabayt məlumat geridədirsə, bu replika seçkilərdə iştirak etmir. Və birdən-birə fileover olarsa, Patroni hansı replikaların geridə qaldığına baxır. Əgər onlar çoxlu sayda əməliyyat qeydləri ilə geri qalırlarsa, onlar master ola bilməzlər. Bu, çoxlu məlumatların itirilməsinin qarşısını alan çox yaxşı təhlükəsizlik xüsusiyyətidir.
Ancaq bir problem var ki, Patroni klasterində və DCS-də replikasiya gecikməsi müəyyən intervalla yenilənir. Düşünürəm ki, 30 saniyə standart ttl dəyəridir.
Müvafiq olaraq, DCS-də replikalar üçün bir replikasiya gecikməsinin olduğu bir vəziyyət ola bilər, lakin əslində tamamilə fərqli bir gecikmə ola bilər və ya heç bir gecikmə olmaya bilər, yəni bu şey real vaxt deyil. Və həmişə real mənzərəni əks etdirmir. Üstəlik bunun üzərində zərif məntiqlə məşğul olmağa dəyməz.
Və itki riski həmişə qalır. Və ən pis halda bir düstur, orta halda isə başqa bir düstur. Yəni, biz Patroninin həyata keçirilməsini planlaşdırarkən və nə qədər məlumat itirə biləcəyimizi qiymətləndirərkən, bu düsturlara arxalanmalıyıq və nə qədər məlumat itirə biləcəyimizi təxminən təsəvvür etməliyik.
Və yaxşı xəbər var. Qoca usta irəli getdikdə, bəzi fon prosesləri səbəbindən irəli gedə bilər. Yəni bir növ avtovakuum var idi, məlumatları yazdı, əməliyyatlar jurnalına saxladı. Və biz bu məlumatları asanlıqla gözardı edə və itirə bilərik. Bunda hec bir problem yoxdur.
Maksimum_lag_on_failover təyin olunarsa və fayl yaranarsa, loglar belə görünür və siz yeni master seçməlisiniz. Replika özünü seçkilərdə iştirak edə bilməyən kimi qiymətləndirir. Və o, liderlik yarışında iştirak etməkdən imtina edir. Və o, yeni ustanın seçilməsini gözləyir ki, ona qoşula bilsin. Bu, məlumat itkisinə qarşı əlavə tədbirdir.
Burada məhsullarının Postgres ilə problemləri olduğunu yazan bir məhsul komandamız var. Eyni zamanda, masterun özünə daxil olmaq mümkün deyil, çünki SSH vasitəsilə mövcud deyil. Və avtomatik fayl da baş vermir.
Bu host yenidən işə salınmağa məcbur oldu. Yenidən yükləmə səbəbindən avtomatik fayl baş verdi, baxmayaraq ki, indi başa düşdüyüm kimi, əl ilə avtomatik fayl etmək mümkün idi. Yenidən başladıqdan sonra indiki usta ilə nə etdiyimizi görəcəyik.
Eyni zamanda disklərlə bağlı problemlərimiz olduğunu əvvəlcədən bilirdik, yəni harda qazıb nə axtaracağımızı monitorinqdən artıq bilirdik.
Postgres jurnalına girdik, orada nə baş verdiyini görməyə başladıq. Biz orada bir, iki, üç saniyə davam edən əməliyyatları gördük, bu heç də normal deyil. Avtovakuumumuzun çox yavaş və qəribə şəkildə işə düşdüyünü gördük. Və diskdə müvəqqəti faylları gördük. Yəni bunların hamısı disklərlə bağlı problemlərin göstəriciləridir.
Biz dmesg (kernel log) sisteminə baxdıq. Və gördük ki, disklərdən birində problemimiz var. Disk alt sistemi proqram təminatı Raid idi. Biz /proc/mdstat-a baxdıq və gördük ki, bir diskimiz çatışmır. Yəni 8 diskdən ibarət Reyd var, bizdə biri çatışmır. Slayda diqqətlə baxsanız, çıxışda orada sde olmadığını görə bilərsiniz. Bizdə, şərti olaraq, disk düşdü. Bu disk problemlərinə səbəb oldu və tətbiqlər Postgres klasteri ilə işləyərkən də problemlərlə üzləşdi.
Və bu halda, Patroni bizə heç bir şəkildə kömək etməzdi, çünki Patroninin serverin vəziyyətini, diskin vəziyyətini izləmək vəzifəsi yoxdur. Biz isə kənar monitorinqlə belə hallara nəzarət etməliyik. Xarici monitorinqə tez bir zamanda disk monitorinqini əlavə etdik.
Və belə bir fikir var idi - qılıncoynatma və ya gözətçi proqramı bizə kömək edə bilərmi? Düşündük ki, o, çətin ki, bu işdə bizə kömək etsin, çünki problemlər zamanı Patroni DCS klasteri ilə əlaqə saxlamağa davam etdi və heç bir problem görmədi. Yəni, DCS və Patroni baxımından klasterdə hər şey qaydasında idi, əslində diskdə problemlər olsa da, verilənlər bazasının mövcudluğu ilə bağlı problemlər var idi.
Fikrimcə, bu, çox uzun müddətdir araşdırdığım ən qəribə problemlərdən biridir, çoxlu logları oxudum, yenidən seçdim və onu klaster simulyatoru adlandırdım.
Problem onda idi ki, köhnə usta normal bir replikaya çevrilə bilmədi, yəni Patroni onu işə saldı, Patroni göstərdi ki, bu node replika kimi mövcuddur, lakin eyni zamanda normal bir replika deyildi. İndi bunun səbəbini görəcəksiniz. Bu problemin təhlilindən saxladığım budur.
Və hər şey necə başladı? Əvvəlki problemdə olduğu kimi, disk əyləcləri ilə başladı. Biz bir saniyə, iki öhdəlik götürdük.
Əlaqələrdə fasilələr oldu, yəni müştərilər parçalandı.
Müxtəlif şiddətdə tıxanmalar var idi.
Və müvafiq olaraq, disk alt sistemi çox həssas deyil.
Və mənim üçün ən sirlisi dərhal bağlanma tələbidir. Postgres-in üç bağlanma rejimi var:
- Bütün müştərilərin öz-özünə əlaqəni kəsməsini gözlədiyimiz zaman zərifdir.
- Bağlanacağımız üçün müştəriləri əlaqəni kəsməyə məcbur etdiyimiz zaman sürətli olur.
- Və dərhal. Bu halda, dərhal müştərilərə bağlanmağı belə demir, sadəcə xəbərdarlıq etmədən bağlanır. Və bütün müştərilərə əməliyyat sistemi artıq RST mesajı göndərir (bağlantının kəsildiyi və müştərinin tutmaq üçün başqa bir şey olmadığı barədə TCP mesajı).
Bu siqnalı kim göndərdi? Postgres fon prosesləri bir-birinə belə siqnallar göndərmir, yəni bu kill-9-dur. Bir-birlərinə belə şeylər göndərmirlər, yalnız belə şeylərə reaksiya verirlər, yəni bu Postgresin təcili yenidən başlamasıdır. Kim göndərib, bilmirəm.
"Sonuncu" əmrə baxdım və bir nəfər gördüm ki, o da bizimlə bu serverə daxil olub, amma sual verməyə çox utandım. Bəlkə də öldürmək idi -9. Mən loglarda kill -9 görərdim, çünki Postgres deyir ki, öldürmək -9 tələb etdi, amma loglarda görmədim.
Daha uzağa baxanda gördüm ki, Patroni kifayət qədər uzun müddət - 54 saniyə ərzində jurnala yazmadı. Və iki vaxt işarəsini müqayisə etsək, təxminən 54 saniyə ərzində heç bir mesaj yox idi.
Və bu müddət ərzində avtomatik fayl var idi. Patroni burada yenə əla iş gördü. Qoca ustamız əlçatmaz idi, ona nəsə oldu. Və yeni ustadın seçilməsi başladı. Burada hər şey yaxşı alındı. Bizim pgsql01 yeni lider oldu.
Ustaya çevrilmiş bir replikamız var. Və ikinci cavab var. İkinci replika ilə bağlı problemlər var idi. O, yenidən konfiqurasiya etməyə çalışdı. Mən başa düşdüyüm kimi o, recovery.conf-u dəyişməyə, Postgres-i yenidən işə salmağa və yeni master-a qoşulmağa çalışdı. O, hər 10 saniyədən bir mesaj yazır ki, cəhd edir, amma bacarmır.
Və bu cəhdlər zamanı köhnə ustaya dərhal bağlanma siqnalı gəlir. Usta yenidən işə salınır. Həm də bərpa dayandırılır, çünki köhnə usta yenidən işə düşür. Yəni replika ona qoşula bilmir, çünki bağlanma rejimindədir.
Müəyyən bir nöqtədə işlədi, lakin təkrarlama başlamadı.
Tək ehtimalım odur ki, recovery.conf-da köhnə master ünvanı var idi. Və yeni bir usta görünəndə ikinci replika hələ də köhnə ustaya qoşulmağa çalışdı.
Patroni ikinci nüsxədə işə başlayanda qovşaq işə düşdü, lakin təkrarlana bilmədi. Və belə bir şeyə bənzəyən bir replikasiya gecikməsi yarandı. Yəni hər üç qovşaq yerində idi, amma ikinci qovşaq geridə qaldı.
Eyni zamanda, yazılmış qeydlərə baxsanız, əməliyyat qeydləri fərqli olduğu üçün təkrarlamanın başlaya bilməyəcəyini görə bilərsiniz. Və masterun təklif etdiyi, recovery.conf-da göstərilən əməliyyat qeydləri sadəcə olaraq cari qovşağımıza uyğun gəlmir.
Və burada səhv etdim. Səhv usta ilə əlaqə qurduğumuza dair fərziyyəmi yoxlamaq üçün gəlib recovery.conf-da nə olduğunu görməli idim. Ancaq sonra sadəcə bununla məşğul oldum və ağlıma gəlmədi, ya da replikanın geridə qaldığını və yenidən doldurulmalı olduğunu gördüm, yəni birtəhər diqqətsiz işlədim. Bu mənim ortağımdı.
30 dəqiqədən sonra admin artıq gəldi, yəni Patronini replikada yenidən başladım. Artıq buna son qoydum, düşündüm ki, yenidən doldurulmalı olacaq. Və düşündüm - Patroni yenidən işə salacağam, bəlkə yaxşı bir şey çıxacaq. Bərpa başladı. Və baza hətta açıldı, əlaqələri qəbul etməyə hazır idi.
Replikasiya başladı. Ancaq bir dəqiqə sonra o, əməliyyat qeydlərinin onun üçün uyğun olmadığı səhvi ilə düşdü.
Yenidən başlayacağımı düşündüm. Mən Patronini yenidən başladım və Postgres-i yenidən başlatmadım, lakin verilənlər bazasını sehrli şəkildə işə salacağı ümidi ilə Patronini yenidən başladım.
Replikasiya yenidən başladı, lakin əməliyyat jurnalındakı işarələr fərqli idi, onlar əvvəlki başlanğıc cəhdi ilə eyni deyildi. Replikasiya yenidən dayandırıldı. Və mesaj artıq bir az fərqli idi. Və mənim üçün çox məlumatlı deyildi.
Və sonra ağlıma gəlir - Postgres-i yenidən işə salsam, bu zaman əməliyyat jurnalındakı nöqtəni bir az irəli aparmaq üçün cari master-da yoxlama nöqtəsi edirəm ki, bərpa başqa bir andan başlasın? Üstəlik, bizdə hələ də WAL ehtiyatlarımız var idi.
Patroni-ni yenidən işə saldım, ustada bir neçə yoxlama nöqtəsi, açıldığında replikada bir neçə yenidən başlama nöqtəsi etdim. Və kömək etdi. Niyə kömək etdiyini və necə işlədiyini uzun müddət düşündüm. Və replika başladı. Və replikasiya artıq yırtılmırdı.
Mənim üçün belə bir problem daha müəmmalı problemlərdən biridir və mən hələ də orada həqiqətən nə baş verdiyini çaşdırıram.
Burada hansı təsirlər var? Patroni nəzərdə tutulduğu kimi və heç bir səhvsiz işləyə bilər. Ancaq eyni zamanda, bu, bizdə hər şeyin yaxşı olduğuna 100% zəmanət deyil. Replika başlaya bilər, lakin o, yarı işlək vəziyyətdə ola bilər və tətbiq belə bir replika ilə işləyə bilməz, çünki köhnə məlumatlar olacaq.
Və fayldan sonra, həmişə çoxluqda hər şeyin qaydasında olduğunu yoxlamaq lazımdır, yəni lazımi sayda replika var, replikasiya gecikməsi yoxdur.
Və bu məsələlərin üzərindən keçərkən mən tövsiyələr verəcəyəm. Onları iki slaydda birləşdirməyə çalışdım. Yəqin ki, bütün hekayələri iki slaydda birləşdirib yalnız danışmaq olardı.
Patroni istifadə edərkən monitorinqiniz olmalıdır. Avtomatik faylın nə vaxt baş verdiyini həmişə bilməlisiniz, çünki siz avtomatik faylın olduğunu bilmirsinizsə, klaster üzərində nəzarətiniz yoxdur. Və bu pisdir.
Hər fayldan sonra biz həmişə klasteri əl ilə yoxlamalıyıq. Əmin olmalıyıq ki, bizdə həmişə aktual sayda replika olsun, replikasiya gecikməsi yoxdur, Patroni ilə, DCS sistemi ilə axın replikasiyası ilə bağlı qeydlərdə heç bir səhv yoxdur.
Avtomatlaşdırma uğurla işləyə bilər, Patroni çox yaxşı vasitədir. Bu işləyə bilər, lakin bu, klasteri istədiyiniz vəziyyətə gətirməyəcək. Və bu barədə məlumat verməsək, problemimiz olacaq.
Və Patroni gümüş güllə deyil. Biz hələ də Postgres-in necə işlədiyini, replikasiyanın necə işlədiyini və Patroninin Postgres ilə necə işlədiyini və qovşaqlar arasında əlaqənin necə təmin olunduğunu başa düşməliyik. Bu, əllərinizlə problemləri həll etmək üçün lazımdır.
Diaqnoz məsələsinə necə yanaşıram? Belə oldu ki, biz müxtəlif müştərilərlə işləyirik və heç kimin ELK yığını yoxdur və biz 6 konsol və 2 tab açaraq qeydləri çeşidləməliyik. Bir tabda bunlar hər bir qovşaq üçün Patroni qeydləri, digər tabda bunlar Konsul qeydləri və ya lazım olduqda Postgresdir. Buna diaqnoz qoymaq çox çətindir.
Mən hansı yanaşmaları inkişaf etdirmişəm? Birincisi, mən həmişə faylın nə vaxt gəldiyinə baxıram. Və mənim üçün bu, su hövzəsidir. Filerdən əvvəl, filler zamanı və fillerdən sonra baş verənlərə baxıram. Faylın iki işarəsi var: bu başlanğıc və bitmə vaxtıdır.
Sonra, mən fayldan əvvəl olan hadisələr üçün qeydlərə baxıram, yəni faylın baş verməsinin səbəblərini axtarıram.
Və bu, belə halların baş verməməsi üçün nə baş verdiyini və gələcəkdə nə edilə biləcəyini başa düşmək üçün bir şəkil verir (və nəticədə heç bir fayl yoxdur).
Və biz adətən hara baxırıq? Mən baxıram:
- Birincisi, Patroni jurnallarına.
- Sonra, Patroni qeydlərində tapılanlardan asılı olaraq Postgres qeydlərinə və ya DCS qeydlərinə baxıram.
- Sistem qeydləri də bəzən fayla səbəb olanı başa düşür.
Patroniyə münasibətim necədir? Patroni ilə çox yaxşı münasibətim var. Məncə, bu, bu gün mövcud olan ən yaxşısıdır. Bir çox başqa məhsullar bilirəm. Bunlar Stolon, Repmgr, Pg_auto_failover, PAF-dır. 4 alət. Hamısını sınadım. Patroni mənim sevimlidir.
Məndən soruşsalar: "Patroni tövsiyə edirəm?". Bəli deyəcəm, çünki Patronini bəyənirəm. Və düşünürəm ki, onu necə bişirməyi öyrəndim.
Əgər qeyd etdiyim problemlərdən başqa Patroni ilə bağlı hansı problemlərin olduğunu görmək istəyirsinizsə, həmişə səhifəyə baxa bilərsiniz. GitHub-da. Orada çoxlu müxtəlif hekayələr var və çoxlu maraqlı məsələlər müzakirə olunur. Və nəticədə bəzi səhvlər təqdim edildi və həll edildi, yəni bu maraqlı bir oxunuşdur.
Ayağına atəş açan insanlar haqqında maraqlı hekayələr var. Çox məlumatlandırıcıdır. Oxuyub başa düşürsən ki, bunu etmək lazım deyil. Özümü işarələdim.
Mən bu layihəni hazırladığı üçün Zalandoya, daha doğrusu Aleksandr Kukuşkinə və Aleksey Klyukinə böyük təşəkkür etmək istərdim. Aleksey Klyukin həmmüəlliflərdən biridir, o, artıq Zalandoda işləmir, lakin bunlar bu məhsulla işləməyə başlayan iki nəfərdir.
Və mən hesab edirəm ki, Patroni çox gözəl şeydir. Mən onun varlığına şadam, onunla maraqlıdır. Patroniyə yamaqlar yazan bütün ianəçilərə böyük təşəkkür edirəm. Ümid edirəm ki, Patroni yaşlandıqca daha yetkin, soyuqqanlı və səmərəli olacaq. Artıq funksionaldır, amma ümid edirəm ki, daha da yaxşılaşacaq. Buna görə də, Patroni istifadə etməyi planlaşdırırsınızsa, qorxmayın. Bu yaxşı bir həlldir, onu həyata keçirmək və istifadə etmək olar.
Hamısı budur. Suallarınız varsa, soruşun.
Suallar
Hesabat üçün təşəkkür edirik! Bir fayldan sonra hələ də ora çox diqqətlə baxmaq lazımdırsa, niyə avtomatik doldurucuya ehtiyacımız var?
Çünki yeni şeylərdir. Onunla cəmi bir il oldu. Təhlükəsiz olmaq daha yaxşıdır. Biz içəri girib hər şeyin həqiqətən də lazım olduğu kimi getdiyini görmək istəyirik. Bu, böyüklərin inamsızlığının səviyyəsidir - iki dəfə yoxlamaq və görmək daha yaxşıdır.
Məsələn, səhər gedib baxırdıq, hə?
Səhər yox, biz adətən avtomatik fayl haqqında dərhal öyrənirik. Bildirişlər alırıq, avtomatik faylın baş verdiyini görürük. Demək olar ki, dərhal gedib baxırıq. Amma bütün bu yoxlamalar monitorinq səviyyəsinə çatdırılmalıdır. REST API vasitəsilə Patroni-yə daxil olsanız, tarixçə var. Tarixçəyə görə, faylın baş verdiyi zaman ştamplarını görə bilərsiniz. Bunun əsasında monitorinq aparıla bilər. Tarixi, nə qədər hadisələrin olduğunu görə bilərsiniz. Əgər daha çox hadisəmiz varsa, o zaman avtomatik fayl baş verdi. Gedin baxa bilersiniz. Və ya monitorinq avtomatlaşdırmamız yoxladı ki, bizdə bütün nüsxələr yerindədir, heç bir gecikmə yoxdur və hər şey qaydasındadır.
Təşəkkür edirik!
Böyük hekayə üçün çox sağ olun! DCS klasterini Postgres klasterindən uzaq bir yerə köçürsək, bu klasterə də vaxtaşırı xidmət göstərilməlidir? DCS klasterinin bəzi hissələrinin söndürülməli olduğu ən yaxşı təcrübələr hansılardır, onlarla nəsə etmək lazımdır və s.? Bütün bu quruluş necə yaşayır? Və bunları necə edirsən?
Bir şirkət üçün, komponentlərdən biri və ya bir neçə komponent uğursuz olarsa, nə baş verəcək, problemlərin matrisini hazırlamaq lazım idi. Bu matrisə uyğun olaraq, biz ardıcıl olaraq bütün komponentlərdən keçirik və bu komponentlərin nasazlığı halında ssenarilər qururuq. Müvafiq olaraq, hər bir uğursuzluq ssenarisi üçün bərpa üçün fəaliyyət planınız ola bilər. Və DCS vəziyyətində, standart infrastrukturun bir hissəsi kimi gəlir. Və admin onu idarə edir və biz artıq onu idarə edən adminlərə və onların qəza halında onu düzəltmək qabiliyyətinə güvənirik. Əgər ümumiyyətlə DCS yoxdursa, biz onu yerləşdiririk, lakin eyni zamanda ona xüsusi nəzarət etmirik, çünki infrastruktura cavabdeh deyilik, lakin necə və nəyə nəzarət etmək barədə tövsiyələr veririk.
Yəni mən düzgün başa düşdüm ki, hostlarla hər hansı bir iş görməzdən əvvəl Patronini söndürməli, faylı söndürməli, hər şeyi söndürməliyəm?
Bu, DCS klasterində neçə qovşaqımızın olmasından asılıdır. Əgər çoxlu qovşaq varsa və biz qovşaqlardan yalnız birini (replika) söndürsək, o zaman klaster kvorumu saxlayır. Və Patroni fəaliyyətini davam etdirir. Və heç bir şey tətiklənmir. Əgər daha çox qovşaqlara təsir edən bəzi mürəkkəb əməliyyatlarımız varsa, onların olmaması kvorumu poza bilər, onda - bəli, Patronini fasiləyə vermək mənalı ola bilər. Bunun müvafiq əmri var - patronictl pause, patronictl resume. Biz sadəcə fasilə veririk və avtofiler həmin vaxt işləmir. Biz DCS klasterində texniki xidmət göstəririk, sonra fasiləni götürüb yaşamağa davam edirik.
Çox sağ olun!
Hesabatınıza görə çox sağ olun! Məhsul komandası məlumatların itirilməsini necə hiss edir?
Məhsul komandaları əhəmiyyət vermir və komanda rəhbərləri narahatdır.
Hansı zəmanətlər var?
Zəmanətlər çox çətindir. Alexander Kukushkinin "RPO və RTO-nu necə hesablamaq olar", yəni bərpa müddəti və nə qədər məlumat itirə biləcəyimiz hesabatı var. Məncə bu slaydları tapıb öyrənməliyik. Xatırladığım qədəri ilə bunların hesablanması ilə bağlı konkret addımlar var. Nə qədər əməliyyatı itirə bilərik, nə qədər data itirə bilərik. Bir seçim olaraq, biz Patroni səviyyəsində sinxron replikasiyadan istifadə edə bilərik, lakin bu, ikitərəfli qılıncdır: ya məlumatların etibarlılığına sahibik, ya da sürəti itiririk. Sinxron replikasiya var, lakin o, həmçinin məlumat itkisindən 100% qorunmağa zəmanət vermir.
Aleksey, əla hesabata görə təşəkkürlər! Sıfır səviyyəli qorunma üçün Patroni istifadə təcrübəsi varmı? Yəni sinxron gözləmə ilə birlikdə? Bu birinci sualdır. Və ikinci sual. Müxtəlif həll yollarından istifadə etmisiniz. Repmgr-dən istifadə etdik, lakin avtofilersiz və indi avtofiler daxil etməyi planlaşdırırıq. Və biz Patronini alternativ həll yolu hesab edirik. Repmgr ilə müqayisədə üstünlüklər kimi nə deyə bilərsiniz?
İlk sual sinxron replikalarla bağlı idi. Burada heç kim sinxron replikasiyadan istifadə etmir, çünki hamı qorxur (bir neçə müştəri artıq ondan istifadə edir, prinsipcə, performans problemlərini görmədilər - Spikerin qeydi). Ancaq biz özümüz üçün bir qayda hazırlamışıq ki, sinxron replikasiya klasterində ən azı üç qovşaq olmalıdır, çünki iki qovşaqımız varsa və master və ya replika uğursuz olarsa, Patroni bu qovşağı müstəqil rejimə keçir ki, tətbiq davam etsin. iş. Bu vəziyyətdə məlumatların itirilməsi riski var.
İkinci suala gəlincə, biz Repmgr-dən istifadə etdik və hələ də bəzi müştərilərlə tarixi səbəblərdən istifadə edirik. Nə demək olar? Patroni qutudan çıxarılan avtomatik doldurucu ilə gəlir, Repmgr aktivləşdirilməli olan əlavə xüsusiyyət kimi avtomatik doldurucu ilə gəlir. Biz hər bir qovşaqda Repmgr demonunu işə salmalıyıq və sonra avtomatik doldurucunu konfiqurasiya edə bilərik.
Repmgr Postgres qovşaqlarının canlı olub olmadığını yoxlayır. Repmgr prosesləri bir-birinin varlığını yoxlayır, bu çox təsirli bir yanaşma deyil. Böyük bir Repmgr klasterinin bir neçə kiçik qrupa parçalanaraq işləməyə davam edə biləcəyi mürəkkəb şəbəkə izolyasiyası halları ola bilər. Repmgr-ı çoxdan izləmirəm, bəlkə düzəldilib... ya da yox. Lakin Stolon, Patroninin etdiyi kimi, DCS-də klasterin vəziyyəti haqqında məlumatın silinməsi ən uyğun variantdır.
Aleksey, mənim bir sualım var, bəlkə də lal. İlk nümunələrdən birində siz DCS-ni yerli maşından uzaq hosta köçürdünüz. Başa düşürük ki, şəbəkə özünəməxsus xüsusiyyətlərə malik bir şeydir, öz-özünə yaşayır. Nədənsə DCS klasteri əlçatmaz olarsa nə olar? Səbəbləri demirəm, çox ola bilər: şəbəkəçilərin əyri əllərindən tutmuş real problemlərə qədər.
Mən bunu yüksək səslə demədim, lakin kvorumun təmin edilməsi üçün DCS klasteri də uğursuz olmalıdır, yəni tək sayda qovşaqdır. DCS klasteri əlçatmaz olarsa və ya kvorum təmin olunmazsa, yəni şəbəkənin bir növ bölünməsi və ya qovşaq nasazlığı olarsa nə baş verir? Bu halda, Patroni klasteri yalnız oxumaq rejiminə keçir. Patroni klasteri klasterin vəziyyətini və nə etməli olduğunu müəyyən edə bilmir. O, DCS ilə əlaqə saxlaya və orada yeni klaster vəziyyətini saxlaya bilməz, ona görə də bütün klaster yalnız oxunuş rejiminə keçir. Və ya operatorun əl ilə müdaxiləsini, ya da DCS-nin bərpasını gözləyir.
Kobud desək, DCS bizim üçün bazanın özü qədər vacib bir xidmətə çevrilir?
Hə hə. Bir çox müasir şirkətlərdə Service Discovery infrastrukturun ayrılmaz hissəsidir. Hətta infrastrukturda verilənlər bazası olmamışdan əvvəl də həyata keçirilir. Nisbətən desək, infrastruktur işə salındı, DC-də yerləşdirildi və bizdə dərhal Service Discovery var. Konsuldursa, onda DNS onun üzərində qurula bilər. Bu Etcd-dirsə, Kubernetes klasterindən hər şeyin yerləşdiriləcəyi bir hissə ola bilər. Mənə elə gəlir ki, Service Discovery artıq müasir infrastrukturların tərkib hissəsidir. Və onlar bu barədə məlumat bazalarından çox daha əvvəl düşünürlər.
Təşəkkür edirik!
Mənbə: www.habr.com