2019-cu ilin əvvəlindən Andrey Borodinin “WAL-G ilə ehtiyat nüsxələri. 2019-cu ildə nə var?” hesabatının stenoqramını oxumağı təklif edirəm.
Hamıya salam! Mənim adım Andrey Borodindir. Mən Yandex-də tərtibatçıyam. Mən 2016-cı ildən PostgreSQL ilə maraqlanıram, tərtibatçılarla danışdıqdan sonra dedilər ki, hər şey sadədir – mənbə kodunu götürüb onu qurursan və hər şey düzələcək. Və o vaxtdan bəri dayana bilmirəm - hər cür müxtəlif şeylər yazıram.
Üzərində işlədiyim şeylərdən biri ehtiyat sistemdir. . Ümumiyyətlə, Yandex-də biz çox uzun müddətdir PostgreSQL-də ehtiyat sistemlər üzərində işləyirik. Və siz İnternetdə ehtiyat sistemləri necə hazırladığımıza dair altı hesabatdan ibarət bir sıra tapa bilərsiniz. Və hər il bir az inkişaf edir, bir az inkişaf edir və daha etibarlı olurlar.
Amma bu gün hesabat təkcə bizim gördüyümüz işlərlə bağlı deyil, həm də bunun nə qədər sadə və nədən ibarət olmasıdır. Neçəniz artıq WAL-G haqqında reportajlarıma baxmısınız? Yaxşı ki, az adam baxmadı, çünki ən sadəindən başlayacağam.
Birdən PostgreSQL klasteriniz varsa və düşünürəm ki, hər kəsdə onlardan bir neçəsi var və birdən hələ də ehtiyat sistem yoxdursa, o zaman hər hansı bir S3 yaddaşı və ya Google Cloud-a uyğun yaddaş əldə etməlisiniz.
Məsələn, siz bizim stendimizə gəlib S3-ə uyğun olan Yandex Obyekt Yaddaşı üçün promosyon kodu götürə bilərsiniz.
Sonra bir Kova yaradın. Bu, sadəcə məlumat üçün konteynerdir.
Xidmət istifadəçisi yaradın.
Xidmət istifadəçisi üçün giriş açarı yaradın: aws-s3-key.
WAL-G-nin ən son stabil buraxılışını endirin.
Bizim pre-relizlərimiz buraxılışlardan nə ilə fərqlənir? Məndən tez-tez tez buraxılmağı tələb edirlər. Əgər versiyada kifayət qədər müddətə, məsələn, bir ay ərzində səhv yoxdursa, onu buraxıram. Budur, noyabr ayından bu buraxılış. Bu o deməkdir ki, biz hər ay bir növ səhv tapırıq, adətən qeyri-kritik funksionallıqda, lakin biz hələ buraxılış buraxmamışıq. Əvvəlki versiya yalnız noyabrdır. Bizə məlum olan heç bir səhv yoxdur, yəni layihə irəlilədikcə səhvlər əlavə edildi.
WAL-G-ni endirdikdən sonra, ətraf mühit dəyişənlərini keçirərək sadə “ehtiyat siyahısı” əmrini işlədə bilərsiniz. O, Obyekt Yaddaşına qoşulacaq və hansı ehtiyat nüsxələriniz olduğunu sizə xəbər verəcəkdir. Əvvəlcə, əlbəttə ki, ehtiyat nüsxələriniz olmamalıdır. Bu slaydın məqsədi hər şeyin olduqca sadə olduğunu göstərməkdir. Bu mühit dəyişənlərini qəbul edən və alt əmrləri yerinə yetirən konsol əmridir.
Bundan sonra ilk ehtiyat nüsxənizi edə bilərsiniz. WAL-G-də “backup-push” deyin və WAL-G-də klasterinizin pgdata yerini təyin edin. Və çox güman ki, PostgreSQL sizə xəbər verəcək ki, əgər sizdə artıq ehtiyat nüsxə sistemi yoxdursa, siz “arxiv rejimi”ni aktivləşdirməlisiniz.
Bu o deməkdir ki, siz parametrlərə keçib “arxiv_rejimi = on” funksiyasını yandırmalı və WAL-G-də alt əmr olan “arxiv_əmrini” əlavə etməlisiniz. Ancaq nədənsə insanlar tez-tez bu mövzuda bar skriptlərindən istifadə edirlər və onu WAL-G-yə bükürlər. Xahiş edirəm bunu etmə. WAL-G-də olan funksionallıqdan istifadə edin. Nəyisə əskik edirsinizsə, yazın . WAL-G onun archive_command-da işləyən yeganə proqram olduğunu güman edir.
Biz WAL-G-dən əsasən Yandex verilənlər bazasının idarə edilməsində Yüksək Əlçatımlılıq klasteri yaratmaq üçün istifadə edirik.
Və adətən bir Master topologiyasında və bir neçə təkrarlamada istifadə olunur. Eyni zamanda, Yandex Object Storage-də ehtiyat nüsxəsini çıxarır.
Ən çox görülən ssenarilər, vaxtın bərpası nöqtəsindən istifadə edərək klasterin surətlərinin yaradılmasıdır. Amma bu halda ehtiyat sisteminin işləməsi bizim üçün o qədər də vacib deyil. Bizə sadəcə ehtiyat nüsxədən yeni klaster yükləmək lazımdır.
Tipik olaraq, yeni bir node əlavə edərkən bizə ehtiyat sistem performansı lazımdır. Niyə vacibdir? Adətən insanlar klasterə yeni qovşaq əlavə edirlər, çünki mövcud klaster oxu yükünü idarə edə bilmir. Onlar yeni bir replika əlavə etməlidirlər. pg_basebackup-dan yükü Master-a əlavə etsək, Master çökə bilər. Buna görə də, Master-a minimal yük yaradaraq, arxivdən tez bir zamanda yeni bir node yükləyə bilməyimiz bizim üçün çox vacib idi.
Və başqa bir oxşar vəziyyət. Bu, əlaqənin itirildiyi Məlumat Mərkəzindən Klaster Ustasını dəyişdirdikdən sonra köhnə Master-ı yenidən işə salmaq ehtiyacıdır.
- Nəticədə, kopiya sisteminə tələbləri formalaşdırarkən, buludda işləyərkən pg_basebackup-ın bizə uyğun olmadığını başa düşdük.
- Biz məlumatlarımızı sıxışdıra bilmək istəyirdik. Ancaq qutuda gələnlərdən başqa demək olar ki, hər hansı bir ehtiyat sistemi məlumatların sıxılmasını təmin edəcəkdir.
- Biz hər şeyi paralelləşdirmək istədik, çünki buluddakı istifadəçi çoxlu sayda prosessor nüvəsi alır. Ancaq bəzi əməliyyatlarda paralellik yoxdursa, o zaman çox sayda nüvə yararsız olur.
- Bizə şifrələmə lazımdır, çünki çox vaxt məlumatlar bizim deyil və aydın mətndə saxlanıla bilməz. Yeri gəlmişkən, WAL-G-yə töhfəmiz şifrələmə ilə başladı. WAL-G-də şifrələməni tamamladıq, bundan sonra bizdən soruşdular: "Bəlkə bizdən biri layihəni inkişaf etdirəcək?" Və o vaxtdan bir ildən artıqdır ki, WAL-G ilə işləyirəm.
- Bizə resursun məhdudlaşdırılması da lazım idi, çünki zaman keçdikcə buluddan istifadə edərək bildik ki, bəzən insanların gecələr vacib ərzaq yükü olur və bu yükə müdaxilə etmək olmaz. Buna görə də biz resursun məhdudlaşdırılmasını əlavə etdik.
- Eləcə də siyahı və idarəetmə.
- Və yoxlama.
Bir çox müxtəlif vasitələrə baxdıq. Xoşbəxtlikdən, PostgreSQL-də böyük seçimimiz var. Və hər yerdə nəyisə əskik edirdik, bəziləri kiçik funksiyalar, bəziləri isə kiçik xüsusiyyətlər.
Və mövcud sistemləri araşdıraraq, WAL-G-ni inkişaf etdirəcəyimiz qənaətinə gəldik. O zaman bu, yeni layihə idi. Yedəkləmə sisteminin bulud infrastrukturuna doğru inkişafa təsir etmək olduqca asan idi.
Sadiq qaldığımız əsas ideologiya WAL-G-nin balalayka qədər sadə olmasıdır.
WAL-G-nin 4 əmri var. Bu:
WAL-PUSH – şaftın arxivi.
WAL-FETCH – mil alın.
BACKUP-PUSH – ehtiyat nüsxəsini çıxarın.
BACKUP-FETCH – ehtiyat sistemdən ehtiyat nüsxəsini əldə edin.
Əslində, WAL-G də bu ehtiyat nüsxələrin idarə edilməsinə malikdir, yəni tarixdə hazırda lazım olmayan qeydlərin və ehtiyat nüsxələrin siyahısı və silinməsi.
Bizim üçün vacib funksiyalardan biri delta nüsxələrinin yaradılması funksiyasıdır.
Delta nüsxələri o deməkdir ki, biz bütün klasterin tam ehtiyat nüsxəsini yaratmırıq, yalnız klasterdə dəyişdirilmiş faylların dəyişdirilmiş səhifələrini yaradırıq. Görünür ki, funksional olaraq bu, WAL-dan istifadə edərək bərpa etmək qabiliyyətinə çox bənzəyir. Lakin biz paralel olaraq WAL tək yivli delta ehtiyat nüsxəsini yığa bilərik. Müvafiq olaraq, şənbə günü əsas ehtiyat nüsxəmiz olduqda, hər gün delta ehtiyat nüsxəsini çıxarır və cümə axşamı uğursuz oluruq, onda biz 4 delta ehtiyat nüsxəsini və 10 saat WAL yığmalıyıq. Delta ehtiyat nüsxələri paralel olaraq yuvarlandığı üçün təxminən eyni vaxt tələb olunacaq.
LSN-əsaslı deltalar - bu o deməkdir ki, ehtiyat nüsxəsini yaratarkən onun dəyişdiyini başa düşmək üçün hər bir səhifəni birləşdirməli və onun LSN-ni əvvəlki ehtiyat nüsxənin LSN-si ilə yoxlamalı olacağıq. Dəyişən məlumatları ehtiva edə biləcək hər hansı bir səhifə delta ehtiyat nüsxəsində olmalıdır.
Dediyim kimi, paralelliyə kifayət qədər diqqət yetirildi.
Lakin PostgreSQL-də arxiv API ardıcıldır. PostgreSQL bir WAL faylını arxivləşdirir və onu bərpa edərkən bir WAL faylı tələb edir. Lakin verilənlər bazası "WAL-FETCH" əmrindən istifadə edərək bir WAL faylı tələb etdikdə, biz "WAL-PREFETCH" əmrini çağırırıq ki, bu da növbəti 8 faylı paralel olaraq obyekt anbarından məlumat almaq üçün hazırlayandır.
Və verilənlər bazası bizdən bir faylı arxivləşdirməyi tələb etdikdə, biz archive_status-a baxırıq və başqa WAL fayllarının olub-olmadığını görürük. Biz də paralel olaraq WAL-ı endirməyə çalışırıq. Bu, əhəmiyyətli performans artımı təmin edir və arxivləşdirilməmiş WAL-ların sayındakı məsafəni əhəmiyyətli dərəcədə azaldır. Bir çox ehtiyat sistem tərtibatçıları bunun belə riskli bir sistem olduğuna inanır, çünki biz PostgreSQL API olmayan kodun daxili elementləri haqqında biliklərimizə güvənirik. PostgreSQL bizim üçün archive_status qovluğunun mövcudluğuna zəmanət vermir və semantikaya, orada WAL faylları üçün hazırlıq siqnallarının olmasına zəmanət vermir. Buna baxmayaraq, mənbə kodunu öyrənirik, bunun belə olduğunu görürük və ondan istifadə etməyə çalışırıq. Və biz PostgreSQL-in inkişaf etdiyi istiqamətə nəzarət edirik, birdən bu mexanizm pozularsa, ondan istifadəni dayandıracağıq.
Təmiz formada LSN əsaslı WAL deltası əvvəlki ehtiyat nüsxədən sonra fayl sistemindəki rejim vaxtı dəyişmiş istənilən klaster faylını oxumağı tələb edir. Biz bununla uzun müddət, demək olar ki, bir il yaşadıq. Və sonda belə bir nəticəyə gəldik ki, bizdə WAL deltaları var.
Bu o deməkdir ki, biz WAL-ı Master-da hər dəfə arxivləşdirəndə biz onu nəinki sıxışdırırıq, şifrələyirik və şəbəkəyə göndəririk, həm də eyni zamanda oxuyuruq. Oradakı qeydləri təhlil edib oxuyuruq. Hansı blokların dəyişdiyini başa düşürük və delta faylları toplayırıq.
Delta faylı WAL fayllarının müəyyən diapazonunu təsvir edir, WAL-ın bu diapazonunda hansı blokların dəyişdirildiyi barədə məlumatları təsvir edir. Və sonra bu delta faylları da arxivləşdirilir.
Burada biz hər şeyi kifayət qədər tez paralelləşdirdiyimiz faktı ilə qarşılaşırıq, lakin ardıcıl bir tarixi paralel oxuya bilmirik, çünki müəyyən bir seqmentdə əvvəlki WAL rekordunun sonu ilə qarşılaşa bilərik, onunla hələ əlaqəmiz yoxdur, çünki paralel oxuma ona gətirib çıxardı ki, biz əvvəlcə hələ keçmişi olmayan gələcəyi təhlil edirik.
Nəticədə _delta_partial fayllara anlaşılmaz parçaları yerləşdirməli olduq. Nəticədə, keçmişə qayıtdıqda, WAL qeydinin hissələrini birinə yapışdıracağıq, bundan sonra onu təhlil edəcəyik və onda nə dəyişdiyini anlayacağıq.
Şaftın təhlili tarixində nə baş verdiyini başa düşmədiyimiz ən azı bir nöqtə varsa, müvafiq olaraq növbəti ehtiyat nüsxəsi zamanı adi bir LSN ilə etdiyimiz kimi bütün klasteri yenidən oxumaq məcburiyyətində qalacağıq. - əsaslı delta.
Nəticədə, bütün əziyyətlərimiz WAL-G təhlil kitabxanasını açıq mənbəyə çevirməyimizə səbəb oldu. Bildiyimə görə, hələ ki, heç kim istifadə etmir, amma kim istəsə, yazsın, istifadə etsin, ictimai mülkiyyətdədir. (Yenilənmiş link )
Nəticədə, bütün məlumat axınları olduqca mürəkkəb görünür. Ustamız şaftı arxivləşdirir və delta fayllarını arxivləşdirir. Və ehtiyat nüsxəsini yaradan replika ehtiyat nüsxələri arasında keçən müddət ərzində delta faylları qəbul etməlidir. Bu halda, tarixin hissələri toplu şəkildə əlavə edilməli və təhlil edilməlidir, çünki bütün tarix böyük seqmentlərə uyğun gəlmir. Və yalnız bundan sonra replika tam delta ehtiyat nüsxəsini arxivləşdirə bilər.
Qrafiklərdə hər şey daha sadə görünür. Bu, bizim real klasterlərimizdən birindən endirmədir. Bizdə LSN əsaslı, bir gündə hazırlanmışdır. LSN əsaslı delta ehtiyat nüsxəsinin səhər üçdən səhər beşə qədər işlədiyini görürük. Bu, prosessor nüvələrinin sayındakı yükdür. WAL-delta bizə burada təxminən 20 dəqiqə çəkdi.Yəni əhəmiyyətli dərəcədə sürətləndi, lakin eyni zamanda şəbəkə üzərində daha intensiv mübadilə oldu.
Hansı blokların dəyişdiyi və verilənlər bazası tarixində hansı vaxtda olduğu barədə məlumatımız olduğundan, biz daha da irəli getdik və funksionallığı inteqrasiya etmək qərarına gəldik - “pg_prefaulter” adlı PostgreSQL uzantısı
Bu o deməkdir ki, gözləmə bazası bərpa əmrini yerinə yetirdikdə, WAL-G-yə növbəti WAL faylını gətirməyi əmr edir. Biz yaxın gələcəkdə WAL bərpa prosesinin hansı məlumat bloklarına daxil olacağını başa düşürük və bu bloklar üzərində oxu əməliyyatına başlayırıq. Bu, SSD kontrollerlərinin işini artırmaq üçün edilib. Çünki WAL roll dəyişdirilməsi lazım olan səhifəyə çatacaq. Bu səhifə diskdədir və səhifə keşində deyil. Və o, bu səhifənin gəlməsini sinxron şəkildə gözləyəcək. Ancaq yaxınlıqda WAL-G var, o bilir ki, növbəti bir neçə yüz meqabayt WAL-da bizə müəyyən səhifələr lazım olacaq və eyni zamanda onları qızdırmağa başlayır. Paralel olaraq yerinə yetirilmələri üçün birdən çox diskə girişi işə salır. Bu, SSD disklərində yaxşı işləyir, lakin təəssüf ki, bu, sabit disk üçün tamamilə uyğun deyil, çünki biz ona yalnız göstərişlərimizlə müdaxilə edirik.
İndi kodda olan budur.
Əlavə etmək istədiyimiz xüsusiyyətlər var.
Bu şəkil WAL-deltanın nisbətən qısa vaxt tələb etdiyini göstərir. Və bu, gün ərzində verilənlər bazasında baş verən dəyişiklikləri oxuyur. Biz WAL-deltasını təkcə gecələr yox, edə bilərdik, çünki o, artıq əhəmiyyətli bir yük mənbəyi deyil. Ucuz olduğu üçün biz hər dəqiqə WAL-delta oxuya bilirik. Bir dəqiqə ərzində biz klasterdə baş vermiş bütün dəyişiklikləri skan edə bilərik. Və bunu "instant WAL-delta" adlandırmaq olar.
Məsələ burasındadır ki, biz klasteri bərpa etdikdə ardıcıl olaraq yığışdırmalı olduğumuz hekayələrin sayını azaldırıq. Yəni PostgreSQL-in yuvarladığı WAL miqdarı azaldılmalıdır, çünki bu, əhəmiyyətli vaxt tələb edir.
Ancaq bu, hamısı deyil. Bəzi blokların ehtiyat ardıcıllıq nöqtəsinə dəyişdiriləcəyini bilsək, keçmişdə onu dəyişdirə bilmərik. Yəni, indi bizdə WAL-delta yönləndirmənin fayl-fayl optimallaşdırılması var. Bu o deməkdir ki, məsələn, çərşənbə axşamı cədvəl tamamilə silinibsə və ya bəzi fayllar cədvəldən tamamilə silinibsə, onda delta bazar ertəsi dönəndə və şənbə günü pg_basebackup bərpa edildikdə, biz bu məlumatları belə yaratmayacağıq.
Biz bu texnologiyanı səhifə səviyyəsinə qədər genişləndirmək istəyirik. Yəni, əgər faylın bəzi hissəsi bazar ertəsi günü dəyişirsə, lakin çərşənbə günü üzərinə yazılacaqsa, cümə axşamı günü bir nöqtəyə bərpa edərkən, səhifələrin ilk bir neçə versiyasını diskə yazmağa ehtiyac yoxdur.
Amma bu, hələ də öz içimizdə aktiv şəkildə müzakirə olunan, lakin hələ məcəlləyə çatmamış ideyadır.
WAL-G-də daha bir xüsusiyyət etmək istəyirik. Biz onu genişləndirilə bilən etmək istəyirik, çünki müxtəlif verilənlər bazalarını dəstəkləməliyik və ehtiyat nüsxələrin idarə edilməsinə eyni şəkildə yanaşmaq istəyirik. Ancaq problem MySQL API-lərinin kökündən fərqli olmasıdır. MySQL-də PITR fiziki WAL jurnalına deyil, binloga əsaslanır. MySQL-də bəzi xarici sistemlərə bu binloqun bitdiyini və arxivləşdirilməli olduğunu bildirən arxivləşdirmə sistemimiz yoxdur. Verilənlər bazası ilə cronda bir yerdə dayanmalı və hazır bir şeyin olub olmadığını yoxlamalıyıq?
Eyni şəkildə, MySQL-in bərpası zamanı sistemə belə və belə fayllara ehtiyacım olduğunu deyə biləcək heç bir bərpa əmri yoxdur. Klasterinizi yenidən qurmağa başlamazdan əvvəl sizə hansı fayllar lazım olduğunu bilməlisiniz. Hansı fayllara ehtiyacınız olacağını özünüz təxmin etməlisiniz. Ancaq bu problemlərin qarşısını hansısa yolla almaq olar. (Aydınlaşdırma: MySQL artıq dəstəklənir)
Hesabatda WAL-G-nin sizə uyğun olmadığı hallar haqqında da danışmaq istədim.
Sinxron replikanız yoxdursa, WAL-G sonuncu seqmentin qorunub saxlanacağına zəmanət vermir. Və arxivləşdirmə tarixin son bir neçə seqmentindən geri qalırsa, bu, riskdir. Sinxron replika yoxdursa, WAL-G-dən istifadə etməyi məsləhət görməzdim. Yenə də, o, əsasən, son baytların təhlükəsizliyinə cavabdeh olan sinxron replika ilə Yüksək Əlçatımlılıq həllini nəzərdə tutan bulud quraşdırılması üçün nəzərdə tutulub.
Mən tez-tez insanların həm WAL-G, həm də WAL-E-ni eyni anda idarə etməyə çalışdığını görürəm. Biz WAL-G-nin WAL-E-dən faylı bərpa edə bilməsi və WAL-E-də hazırlanmış ehtiyat nüsxəni bərpa edə bilməsi mənasında geriyə uyğunluğu dəstəkləyirik. Lakin bu sistemlərin hər ikisi paralel wal-push istifadə etdiyi üçün bir-birindən faylları oğurlamağa başlayırlar. Onu WAL-G-də düzəltsək, yenə də WAL-E-də qalacaq. WAL-E-də o, arxiv statusuna baxır, bitmiş faylları görür və onları arxivləşdirir, digər sistemlər isə sadəcə olaraq bu WAL faylının mövcud olduğunu bilməyəcək, çünki PostgreSQL onu ikinci dəfə arxivləşdirməyə cəhd etməyəcək.
Burada WAL-G tərəfində nəyi düzəldəcəyik? Biz PostgreSQL-ə bu faylın paralel olaraq ötürüldüyü barədə məlumat verməyəcəyik və PostgreSQL bizdən onu arxivləşdirməyi xahiş etdikdə, artıq biləcəyik ki, bu rejim vaxtı və bu md5 ilə belə bir fayl artıq arxivlənib və sadəcə PostgreSQL deyəcəyik - OK, heç nə etmədən hər şey hazırdır.
Lakin bu problemin WAL-E tərəfində həlli çətin ki, ona görə də faylı həm WAL-G, həm də WAL-E-də arxivləşdirəcək arxiv əmri yaratmaq hazırda mümkün deyil.
Bundan əlavə, WAL-G-nin indi sizin üçün uyğun olmadığı hallar var, lakin biz onu mütləq düzəldəcəyik.
Birincisi, hazırda bizdə daxili ehtiyat nüsxəsi yoxlanışı yoxdur. Yedəkləmə və ya bərpa zamanı bizdə doğrulama yoxdur. Təbii ki, bu buludda həyata keçirilir. Amma bu, sadəcə olaraq, əvvəlcədən yoxlama yolu ilə, sadəcə olaraq, klasteri bərpa etməklə həyata keçirilir. Mən bu funksiyanı istifadəçilərə vermək istərdim. Lakin yoxlama ilə mən güman edirəm ki, WAL-G-də klasteri bərpa etmək və işə salmaq və tüstü testlərini həyata keçirmək mümkün olacaq: pg_dumpall-dan /dev/null və amcheck indeksinin yoxlanılması.
Hazırda WAL-G-də WAL-dan bir ehtiyat nüsxəni təxirə salmaq üçün heç bir yol yoxdur. Yəni biz hansısa pəncərəni dəstəkləyirik. Məsələn, son yeddi günü saxlamaq, son on ehtiyat nüsxəni saxlamaq, son üç tam ehtiyat nüsxəni saxlamaq. Çox vaxt insanlar gəlib deyirlər: “Bizə Yeni ildə baş verənlərin ehtiyat nüsxəsinə ehtiyacımız var və biz onu əbədi saxlamaq istəyirik”. WAL-G bunu hələ edə bilməz. (Qeyd - Bu artıq düzəldildi. Ətraflı oxuyun - Yedəkləmə işarəsi seçimi )
Və bizdə PITR-i təsdiqləyərkən bütün şaft seqmentləri üçün səhifə yoxlama cəmi və bütövlük yoxlanışı yoxdur.
Bütün bunlardan mən Google Summer of Code üçün bir layihə hazırladım. Əgər siz Go-da nəsə yazmaq və “G” hərfi ilə bir şirkətdən bir neçə min dollar almaq istəyən ağıllı tələbələri tanıyırsınızsa, layihəmizi onlara tövsiyə edin. Mən bu layihədə mentor kimi çıxış edəcəyəm, onlar bunu edə bilərlər. Tələbə yoxdursa, yayda götürüb özüm edəcəm.
Və bizim tədricən üzərində işlədiyimiz bir çox başqa kiçik problemlərimiz də var. Və olduqca qəribə şeylər baş verir.
Məsələn, WAL-G-yə boş ehtiyat nüsxəsi versəniz, o, sadəcə düşəcək. Məsələn, ona boş bir qovluğun ehtiyat nüsxəsini çıxarması lazım olduğunu söyləsəniz. pg_control faylı orada olmayacaq. Və nəyisə başa düşmədiyini düşünəcək. Teorik olaraq, bu halda istifadəçiyə alətdən necə istifadə edəcəyini izah etmək üçün ona normal mesaj yazmaq lazımdır. Ancaq bu, hətta proqramlaşdırmanın bir xüsusiyyəti deyil, yaxşı, başa düşülən bir dilin xüsusiyyətidir.
Oflayn ehtiyat nüsxəsini necə edəcəyimizi bilmirik. Verilənlər bazası yalan danışırsa, biz onun ehtiyat nüsxəsini çıxara bilmərik. Ancaq burada hər şey çox sadədir. LSN başladıqda ehtiyat nüsxələri çağırırıq. Əsas bazanın LSN-i nəzarət faylından oxunmalıdır. Və bu belə reallaşdırılmamış bir xüsusiyyətdir. Bir çox ehtiyat sistemləri əsas verilənlər bazasını ehtiyat nüsxəsini çıxara bilər. Və rahatdır.
Hazırda ehtiyat nüsxəsinin olmaması ilə düzgün məşğul ola bilmirik. Çünki biz adətən evdə böyük ehtiyatlarla işləyirik. Və onlar buna çatmadılar. Ancaq kimsə Go-da proqramlaşdırmaq istəyirsə, boşluqdan kənar xətaların idarə edilməsini kovaya əlavə edin. Mən mütləq çəkmə sorğusuna baxacağam.
Bizi narahat edən əsas odur ki, biz müxtəlif ssenariləri yoxlayan mümkün qədər çox docker inteqrasiya testləri istəyirik. Hazırda biz yalnız əsas ssenariləri sınaqdan keçiririk. Hər bir öhdəlikdə, lakin biz dəstəklədiyimiz bütün funksiyaları yerinə yetirmək üzrə yoxlamaq istəyirik. Xüsusilə, məsələn, PostgreSQL 9.4-9.5 üçün kifayət qədər dəstəyimiz olacaq. Biz onları dəstəkləyirik, çünki icma PostgreSQL-i dəstəkləyir, lakin biz hər şeyin pozulmadığına əmin olmaq üçün öhdəliklərin yerinə yetirilməsini yoxlamırıq. Və mənə elə gəlir ki, bu kifayət qədər ciddi riskdir.
Yandex Database idarəçiliyində mindən çox klasterdə işləyən WAL-G var. Və hər gün bir neçə yüz terabayt məlumatın ehtiyat nüsxəsini çıxarır.
Kodumuzda çoxlu TODO var. Proqram etmək istəyirsənsə gəl, çəkmə sorğularını, suallarını gözləyirik.
Suallar
Axşamınız xeyir! Çox sağ ol! Düşünürəm ki, WAL-delta istifadə edirsinizsə, çox güman ki, tam səhifə yazılarına etibar edirsiniz. Əgər belədirsə, testlər keçirmisiniz? Gözəl qrafik göstərdiniz. FPW söndürülsə nə qədər gözəl olar?
Tam səhifə yazısı bizim üçün aktivdir, biz onu söndürməyə çalışmamışıq. Yəni mən bir tərtibatçı olaraq onu söndürməyə çalışmamışam. Tədqiqat aparan sistem administratorları yəqin ki, bu məsələni araşdırıblar. Ancaq bizə FPW lazımdır. Demək olar ki, heç kim onu söndürmür, çünki əks halda replikadan ehtiyat nüsxəsini çıxarmaq mümkün deyil.
Hesabat üçün təşəkkür edirik! Mənim iki sualım var. İlk sual masa boşluqlarına nə olacaq?
Çəkmə tələbini gözləyirik. Verilənlər bazalarımız SSD və NMVE disklərində yaşayır və bu xüsusiyyətə ehtiyacımız yoxdur. Mən bunu yaxşı etmək üçün hazırda ciddi vaxt sərf etməyə hazır deyiləm. Mən ürəkdən müdafiə edirəm ki, biz bunu dəstəkləyirik. Bunu dəstəkləyənlər var, amma özlərinə uyğun şəkildə dəstək veriblər. Çəngəl düzəltdilər, amma çəkmə tələbləri etmədilər. (0.2.13 versiyada əlavə edilib)
Və ikinci sual. Siz ən əvvəl dediniz ki, WAL-G onun tək işlədiyini və heç bir sarğı lazım olmadığını güman edir. Mən özüm sarğılardan istifadə edirəm. Niyə onlardan istifadə edilməməlidir?
Biz bunun balalayka kimi sadə olmasını istəyirik. Bu o deməkdir ki, balalaykadan başqa heç nəyə ehtiyacınız yoxdur. Sistemin sadə olmasını istəyirik. Əgər skriptdə etməli olduğunuz funksiyalarınız varsa, gəlin və bizə deyin - biz bunu Go-da edəcəyik.
Axşamınız xeyir! Hesabat üçün təşəkkür edirik! WAL-G-ni GPG deşifrəsi ilə işləmək üçün əldə edə bilmədik. Normal olaraq şifrələyir, lakin şifrəni açmaq istəmir. Bu, bizim üçün işləməyən bir şeydir? Vəziyyət depressivdir.
GitHub-da problem yaradın və gəlin bunu anlayaq.
Yəni, bununla qarşılaşmamısınız?
Səhv hesabatının bir xüsusiyyəti var ki, WAL-G onun hansı fayl olduğunu başa düşmədikdə soruşur: "Bəlkə şifrələnib?" Bəlkə də problem ümumiyyətlə şifrələmə deyil. Mən bu mövzuda girişi təkmilləşdirmək istəyirəm. O, deşifrə etməlidir. Hal-hazırda bu mövzu üzərində işləyirik, o mənada ki, açıq və şəxsi açarların əldə edilməsi sisteminin necə təşkil olunduğunu bəyənmirik. Çünki biz xarici GPG çağırırıq ki, o bizə açarlarını verir. Və sonra biz bu açarları götürüb daxili GPG-yə köçürürük, açıq PGP, bizim üçün WAL-G daxilində tərtib edilir və orada şifrələmə deyirik. Bu baxımdan, biz sistemi təkmilləşdirmək istəyirik və Libsodium şifrələməsini dəstəkləmək istəyirik (0.2.15 versiyasında əlavə edilib). Əlbəttə ki, dekodlaşdırma işləməlidir, gəlin bunu anlayaq - bir neçə sözdən daha çox bir simptoma ehtiyacınız var. Nə vaxtsa natiq otağına yığışıb sistemə baxa bilərsiniz. (Xarici GPG olmadan PGP şifrələməsi - v0.2.9)
Salam! Hesabat üçün təşəkkür edirik! Mənim iki sualım var. İki provayderdə pg_basebackup və WAL daxil olmaq üçün qəribə bir istəyim var, yəni bir bulud və digərini etmək istəyirəm. Bunu etmək üçün bir yol varmı?
Bu indi mövcud deyil, amma maraqlı fikirdir.
Mən sadəcə bir provayderə etibar etmirəm, hər ehtimala qarşı başqa bir provayderdə də eyni olmasını istəyirəm.
İdeya maraqlıdır. Texniki cəhətdən bunu həyata keçirmək heç də çətin deyil. İdeyanın itirilməsinin qarşısını almaq üçün sizdən GitHub-da problem yaratmağınızı xahiş edə bilərəmmi?
Bəli, əlbəttə.
Və sonra, tələbələr Google Summer of Code-a gəldikdə, biz onları layihəyə əlavə edəcəyik ki, onlardan daha çox faydalanmaq üçün daha çox iş olsun.
Və ikinci sual. GitHub-da problem var. Məncə artıq bağlanıb. Bərpa zamanı çaxnaşma var. Və onu məğlub etmək üçün ayrıca bir məclis etdin. Məsələlərdə haqlıdır. Və bir mövzuda dəyişən mühit etmək üçün bir seçim var. Və buna görə də çox yavaş işləyir. Və biz bu problemlə qarşılaşdıq və hələ də həll olunmayıb.
Problem ondadır ki, nədənsə yaddaş (CEPH) yüksək paralelliklə gəldiyimiz zaman əlaqəni sıfırlayır. Bununla bağlı nə etmək olar? Yenidən cəhd məntiqi belə görünür. Faylı yenidən endirməyə çalışırıq. Bir keçiddə yüklənməmiş bir sıra fayllarımız var idi, daxil olmayanların hamısı üçün ikincisini edəcəyik. Və iterasiya başına ən azı bir fayl yükləndiyi müddətdə biz təkrar edirik və təkrar edirik və təkrar edirik. Yenidən cəhd məntiqini təkmilləşdirdik - eksponensial geriləmə. Ancaq əlaqənin sadəcə yaddaş sistemi tərəfində kəsilməsi ilə nə edəcəyiniz tam aydın deyil. Yəni bir axına yüklədiyimiz zaman bu əlaqələri pozmur. Burada nəyi təkmilləşdirə bilərik? Şəbəkə tənzimləməmiz var, hər bir əlaqəni göndərdiyi baytların sayı ilə məhdudlaşdıra bilərik. Əks təqdirdə, obyekt yaddaşının paralel olaraq yükləməyə və ya endirməyə imkan verməməsi ilə necə məşğul olacağımı bilmirəm.
SLA yoxdur? Onlar üçün yazılmayıbmı ki, özlərinə necə əzab versinlər?
Məsələ burasındadır ki, bu sualla gündəmə gələn insanların adətən öz anbarı olur. Yəni heç kim Amazon və ya Google Cloud və ya Yandex Object Storage-dən gəlmir.
Bəlkə sual artıq sənin üçün deyil?
Bu vəziyyətdə sualın kimə əhəmiyyəti yoxdur. Bununla necə məşğul olacağına dair hər hansı bir fikir varsa, bunu WAL-G-də edək. Ancaq hələ ki, bununla necə məşğul olacağım barədə yaxşı fikirlərim yoxdur. Siyahıdakı ehtiyat nüsxələrini fərqli şəkildə dəstəkləyən bəzi Obyekt Yaddaşları var. Siz onlardan obyektləri siyahıya salmağı xahiş edirsiniz və onlar ora qovluq əlavə edirlər. WAL-G bundan qorxur - burada fayl olmayan bir şey var, mən onu bərpa edə bilmirəm, yəni ehtiyat nüsxəsi bərpa olunmayıb. Yəni, əslində, tamamilə bərpa edilmiş klasteriniz var, lakin o, sizə səhv status qaytarır, çünki Obyekt Yaddaşı tam başa düşmədiyi bəzi qəribə məlumatları qaytarır.
Bu, Mail buludunda baş verən bir şeydir.
Bir reproduksiya qura bilsəniz ...
Ardıcıl olaraq təkrarlanır ...
Əgər reproduksiya varsa, o zaman düşünürəm ki, biz yenidən cəhd strategiyaları ilə sınaqdan keçirəcəyik və yenidən cəhd etməyi və buludun bizdən nə tələb etdiyini başa düşməyi öyrənəcəyik. Bəlkə üç əlaqədə bizim üçün sabit olacaq və əlaqəni pozmayacaq, sonra diqqətlə üçə çatacağıq. Çünki indi biz əlaqəni çox tez kəsirik, yəni 16 iplə bərpanı işə salmışıqsa, ilk təkrar cəhddən sonra 8 ip, 4 ip, 2 ip və bir olacaq. Və sonra faylı bir axına çəkəcək. 7,5 iplik kimi bəzi sehrli dəyərlər varsa, nasos üçün ən yaxşısıdır, onda biz onların üzərində dayanacağıq və başqa 7,5 ip düzəltməyə çalışacağıq. Burada bir fikir var.
Hesabat üçün təşəkkür edirik! WAL-G ilə işləmək üçün tam iş axını necə görünür? Məsələn, səhifələr arasında heç bir delta olmadığı axmaq halda. Və biz ilkin ehtiyat nüsxəsini götürüb çıxarırıq, sonra üzü mavi olana qədər şaftı arxivləşdiririk. Burada, mənim başa düşdüyüm kimi, bir nasazlıq var. Müəyyən bir nöqtədə səhifələrin delta ehtiyat nüsxəsini yaratmalısınız, yəni hansısa xarici proses bunu idarə edir və ya bu necə baş verir?
Delta backup API olduqca sadədir. Orada bir nömrə var - maksimum delta addımları, buna belə deyilir. Defolt olaraq sıfırdır. Bu o deməkdir ki, siz hər dəfə backup-push etdiyiniz zaman tam ehtiyat nüsxəsini endirir. Əgər siz onu hər hansı müsbət rəqəmə, məsələn, 3-ə dəyişsəniz, növbəti dəfə ehtiyat nüsxəsini çıxardığınız zaman əvvəlki ehtiyat nüsxələrin tarixinə baxır. Görür ki, 3 delta zəncirini keçmirsən və delta edir.
Yəni hər dəfə biz WAL-G-ni işə saldığımız zaman o, tam ehtiyat nüsxəsini çıxarmağa çalışır?
Xeyr, biz WAL-G-ni idarə edirik və siyasətləriniz icazə verərsə, o, delta yaratmağa çalışır.
Kobud desək, hər dəfə sıfırla işlətsəniz, pg_basebackup kimi davranacaq?
Xeyr, sıxılma və paralellikdən istifadə etdiyi üçün yenə də daha sürətli işləyəcək. Pg_basebackup şaftı yanınıza qoyacaq. WAL-G, arxivləşdirməni konfiqurasiya etdiyinizi güman edir. Və konfiqurasiya edilmədiyi təqdirdə xəbərdarlıq verəcəkdir.
Pg_basebackup vallar olmadan işlədilə bilər.
Bəli, o zaman özlərini demək olar ki, eyni aparacaqlar. Pg_basebackup fayl sisteminə kopyalayır. Yeri gəlmişkən, qeyd etməyi unutduğum yeni bir xüsusiyyətimiz var. İndi pg_basebackup-dan fayl sisteminə ehtiyat nüsxəsini çıxara bilərik. Bunun nə üçün lazım olduğunu bilmirəm, amma var.
Məsələn, CephFS-də. Hər kəs Obyekt Yaddaşını konfiqurasiya etmək istəmir.
Bəli, yəqin ki, buna görə də bu xüsusiyyət haqqında sual verdilər ki, biz bunu edə bilək. Və biz bunu etdik.
Hesabat üçün təşəkkür edirik! Sadəcə fayl sisteminə kopyalama ilə bağlı bir sual var. Qutudan kənarda, məsələn, məlumat mərkəzində bir az rəf varsa və ya başqa bir şey varsa, indi uzaq yaddaşa köçürməyi dəstəkləyirsinizmi?
Bu formada bu çətin sualdır. Bəli, dəstəkləyirik, lakin bu funksionallıq hələ heç bir buraxılışa daxil edilməyib. Yəni bütün pre-relizlər bunu dəstəkləyir, lakin buraxılış versiyaları bunu dəstəkləmir. Bu funksionallıq 0.2 versiyada əlavə edilmişdir. Bütün məlum səhvləri düzəldən kimi mütləq tezliklə buraxılacaq. Ancaq hazırda bu, yalnız pre-relizdə edilə bilər. İlkin buraxılışda iki səhv var. WAL-E bərpası ilə bağlı problem, biz onu həll etməmişik. Ən son pre-relizdə delta-backup ilə bağlı bir səhv əlavə edildi. Buna görə də hər kəsə buraxılış versiyalarından istifadə etməyi tövsiyə edirik. Əvvəlcədən buraxılışda səhvlər qalmayan kimi deyə bilərik ki, biz Google Cloud, S3-ə uyğun şeylər və fayl yaddaşını dəstəkləyirik.
Salam, hesabata görə təşəkkürlər. Mən başa düşdüyüm kimi, WAL-G barmen kimi bir növ mərkəzləşdirilmiş sistem deyil? Bu istiqamətdə hərəkət etməyi planlaşdırırsınızmı?
Problem ondadır ki, biz bu istiqamətdən uzaqlaşmışıq. WAL-G əsas hostda, klaster hostunda və klasterdəki bütün hostlarda yaşayır. Bir neçə min klasterə köçəndə çoxlu barmen qurğularımız var idi. Və hər dəfə onların içində bir şey dağılırsa, bu, böyük bir problemdir. Onların təmirə ehtiyacı olduğundan, indi hansı klasterlərin ehtiyat nüsxələrinin olmadığını başa düşməlisiniz. WAL-G-ni ehtiyat sistemlər üçün fiziki təchizat istiqamətində inkişaf etdirməyi planlaşdırmıram. İcma burada hansısa funksionallıq istəyirsə, mən qətiyyən etiraz etmirəm.
Saxlamaya cavabdeh olan komandalarımız var. Və özümüzü o qədər yaxşı hiss edirik ki, biz deyilik, fayllarımızı təhlükəsiz olduğu yerə qoyan xüsusi insanlar var. Müəyyən sayda faylın itirilməsinə tab gətirmək üçün orada hər cür ağıllı kodlaşdırma aparırlar. Onlar şəbəkə bant genişliyinə cavabdehdirlər. Bir barmeniniz olduqda, birdən çox trafikə malik kiçik verilənlər bazalarının eyni serverdə toplandığını öyrənə bilərsiniz. Deyəsən, orada çox yer var, amma nədənsə hər şey şəbəkəyə uyğun gəlmir. Bunun əksi də ola bilər. Orada çoxlu şəbəkələr var, prosessor nüvələri var, amma burada disklər yoxdur. Və biz bu nəyisə hoqqa çıxarmaq ehtiyacından bezdik və məlumatların saxlanmasının ayrıca xüsusi insanların məsuliyyət daşıdığı ayrıca bir xidmət olduğuna keçdik.
PS Yeni versiya buraxıldı , burada siz default olaraq postgres ev kataloqunda yerləşən .walg.json konfiqurasiya faylından istifadə edə bilərsiniz. Siz bash skriptlərindən imtina edə bilərsiniz. Bu məsələdə .walg.json nümunəsidir
Video:
Mənbə: www.habr.com