Çıxışında Andrey Borodin sizə bir əlaqə hovuzu dizayn edərkən PgBouncer miqyası təcrübəsini necə nəzərə aldıqlarını izah edəcək. , onu istehsalda necə yaydılar. Bundan əlavə, biz yeni versiyalarda hovuzun hansı funksiyalarını görmək istədiyimizi müzakirə edəcəyik: bizim üçün təkcə ehtiyaclarımızı ödəmək deyil, həm də istifadəçi icmasını inkişaf etdirmək vacibdir. .
Video:
Hamıya salam! Mənim adım Andrew.
Yandex-də mən açıq mənbə məlumat bazaları inkişaf etdirirəm. Və bu gün əlaqə hovuzu əlaqələri haqqında bir mövzumuz var.
Əgər siz rus dilində əlaqə hovuzuna necə zəng edəcəyinizi bilirsinizsə, mənə deyin. Mən, həqiqətən, texniki ədəbiyyatda müəyyən edilməli olan yaxşı bir texniki termin tapmaq istəyirəm.
Mövzu olduqca mürəkkəbdir, çünki bir çox verilənlər bazasında əlaqə hovuzu quraşdırılmışdır və bu barədə bilmək lazım deyil. Bəzi parametrlər, əlbəttə ki, hər yerdədir, lakin Postgres-də bu işləmir. Paralel olaraq (HighLoad++ 2019-da) Postgres-də sorğuların qurulması ilə bağlı Nikolay Samoxvalovun hesabatı var. Mən başa düşürəm ki, bura artıq sorğuları mükəmməl şəkildə konfiqurasiya etmiş insanlar gəlib və bunlar şəbəkə, resurs istifadəsi ilə bağlı daha nadir sistem problemləri ilə üzləşən insanlardır. Bəzi yerlərdə isə problemlərin aşkar olmaması mənasında kifayət qədər çətin ola bilər.
Yandex-də Postgres var. Bir çox Yandex xidmətləri Yandex.Cloud-da yaşayır. Postgres-də saniyədə ən azı bir milyon sorğu yaradan bir neçə petabayt məlumatımız var.
Və biz bütün xidmətlər üçün kifayət qədər tipik bir klaster təqdim edirik - bu, qovşağın əsas əsas nodu, adi iki replika (sinxron və asinxron), ehtiyat nüsxə, replikada oxu sorğularının miqyası.
Hər bir klaster qovşağı Postgres-dir, onun üzərində Postgres və monitorinq sistemlərinə əlavə olaraq bir əlaqə hovuzu da quraşdırılmışdır. Bağlantı hovuzu qılıncoynatma üçün və onun əsas məqsədi üçün istifadə olunur.
Bağlantı hovuzunun əsas məqsədi nədir?
Postgres verilənlər bazası ilə işləmək üçün proses modelini qəbul edir. Bu o deməkdir ki, bir əlaqə bir proses, bir Postgres backenddir. Və bu backenddə çoxlu müxtəlif keşlər var ki, onları müxtəlif əlaqələr üçün fərqli etmək olduqca bahalıdır.
Həmçinin, Postgres kodunda procArray adlı massiv var. O, şəbəkə əlaqələri haqqında əsas məlumatları ehtiva edir. Və demək olar ki, bütün procArray emal alqoritmləri xətti mürəkkəbliyə malikdir, onlar bütün şəbəkə əlaqələrini əhatə edir. Bu olduqca sürətli bir dövrdür, lakin daha çox daxil olan şəbəkə əlaqələri ilə işlər bir az daha bahalaşır. Və işlər bir az bahalaşdıqda, çoxlu sayda şəbəkə bağlantısı üçün çox yüksək qiymət ödəyirsiniz.
3 mümkün yanaşma var:
- Tətbiq tərəfində.
- Verilənlər bazası tərəfində.
- Və arasında, yəni bütün mümkün birləşmələr.
Təəssüf ki, daxili hovuzer hazırda inkişaf mərhələsindədir. PostgreSQL Professional-dakı dostlar bunu daha çox edir. Nə vaxt görünəcəyini proqnozlaşdırmaq çətindir. Və əslində, bir memar seçimi üçün iki həll yolumuz var. Bunlar proqram tərəfi hovuzu və proxy hovuzudur.
Tətbiq tərəfi hovuzu ən asan yoldur. Və demək olar ki, bütün müştəri sürücüləri sizə bir yol təqdim edir: kodda milyonlarla əlaqənizi verilənlər bazası ilə bir neçə onlarla əlaqə kimi təqdim etmək.
Müəyyən bir nöqtədə arxa ucunu miqyaslaşdırmaq istədiyiniz bir problem var, onu bir çox virtual maşınlara yerləşdirmək istəyirsiniz.
Onda hələ də başa düşürsən ki, daha bir neçə əlçatanlıq zonası, bir neçə məlumat mərkəzi var. Və müştəri tərəfinin birləşdirilməsi yanaşması böyük rəqəmlərə gətirib çıxarır. Böyük olanlar təxminən 10 əlaqədir. Bu, yaxşı işləyə bilən bir kənardır.
Proksi hovuzçular haqqında danışsaq, çox şey edə bilən iki hovuzçu var. Onlar təkcə hovuzçu deyillər. Onlar hovuzçulardır + daha sərin funksionallıq. Bu и .
Ancaq təəssüf ki, hər kəs bu əlavə funksionallığa ehtiyac duymur. Və bu ona gətirib çıxarır ki, hovuzçular yalnız sessiyanın birləşdirilməsini dəstəkləyir, yəni verilənlər bazasına bir gələn müştəri, bir gedən müştəri.
Bu, tapşırıqlarımız üçün çox uyğun deyil, ona görə də biz əməliyyatların birləşdirilməsini həyata keçirən PgBouncer-dən istifadə edirik, yəni server əlaqələri yalnız əməliyyat müddətində müştəri əlaqələri ilə əlaqələndirilir.
Və bizim yükümüzdə - bu doğrudur. Ancaq bir sıra problemlər var.
Problemlər bir seansa diaqnoz qoymaq istədiyiniz zaman başlayır, çünki bütün daxil olan əlaqələr yerlidir. Hər kəs loopback ilə gəldi və birtəhər sessiyanı izləmək çətinləşir.
Əlbəttə ki, application_name_add_host istifadə edə bilərsiniz. Bu, application_name-ə IP ünvanı əlavə etmək üçün Bouncer yan yoludur. Lakin proqram_adı əlavə əlaqə ilə təyin olunur.
Bu diaqramda sarı xəttin real sorğular, mavi xəttin isə verilənlər bazasına uçan sorğular olduğu yerdir. Və bu fərq məhz proqram_adı parametridir, bu, yalnız izləmə üçün lazımdır, lakin heç də pulsuz deyil.
Bundan əlavə, Bouncer bir hovuzu, yəni hər bir verilənlər bazası üçün istifadəçi başına verilənlər bazası bağlantılarının sayını məhdudlaşdıra bilməz.
Bu nəyə gətirib çıxarır? Sizin C++ dilində yazılmış yüklənmiş xidmətiniz və yaxınlıqda baza ilə heç bir problemi olmayan qovşaqda kiçik bir xidmətiniz var, lakin onun sürücüsü dəli olur. 20 əlaqə açır və qalan hər şey gözləyəcək. Hətta kodunuz düzgündür.
Əlbəttə ki, biz Bouncer üçün bu parametri əlavə edən, yəni müştəriləri hovuza məhdudlaşdıran kiçik bir yamaq yazdıq.
Bunu Postgres tərəfində etmək, yəni verilənlər bazasındakı rolları bağlantıların sayı ilə məhdudlaşdırmaq mümkün olardı.
Lakin sonra siz niyə serverlə heç bir əlaqənizin olmadığını anlamaq qabiliyyətini itirirsiniz. PgBouncer əlaqə xətası yaratmır, həmişə eyni məlumatı qaytarır. Siz isə başa düşə bilmirsiniz: bəlkə parolunuz dəyişib, ola bilsin ki, verilənlər bazası sadəcə çöküb, ola bilsin ki, nəsə səhv olub. Ancaq diaqnoz yoxdur. Sessiya qurmaq mümkün deyilsə, bunun niyə edilə bilməyəcəyini bilməyəcəksiniz.
Müəyyən bir nöqtədə, tətbiqin qrafiklərinə baxırsınız və tətbiqin işləmədiyini görürsünüz.
Yuxarıya baxın və görün Bouncer tək yivlidir. Bu, xidmətin həyatında dönüş nöqtəsidir. Siz başa düşürsünüz ki, bir il yarım ərzində verilənlər bazasını genişləndirməyə hazırlaşırsınız və siz hovuzu genişləndirməlisiniz.
Daha çox PgBouncers-ə ehtiyacımız olduğu qənaətinə gəldik.
Bouncer bir az yamaqlandı.
Və bunu elə etdilər ki, TCP portunun təkrar istifadəsi ilə bir neçə Bouncer qaldırıla bilər. Və artıq əməliyyat sistemi avtomatik olaraq round-robin'om vasitəsilə onların arasında daxil olan TCP bağlantılarını köçürür.
Bu, müştərilər üçün şəffafdır, yəni sizin bir Bounceriniz var, lakin çalışan Bouncers arasında boş bağlantıların parçalanması var.
Və bir nöqtədə, bu 3 Bouncerin hər birinin öz nüvəsini 100% yediyini görə bilərsiniz. Sizə bir neçə Bouncer lazımdır. Niyə?
Çünki sizdə TLS var. Şifrələnmiş bağlantınız var. Postgres-i TLS-li və TLS-siz müqayisə etsəniz, şifrələmə aktiv olduqda qurulmuş bağlantıların sayının demək olar ki, iki miqyasda azaldığını görəcəksiniz, çünki TLS əl sıxması CPU resurslarını sərf edir.
Və yuxarıda, daxil olan əlaqələr dalğası zamanı yerinə yetirilən bir neçə kriptoqrafik funksiyanı görə bilərsiniz. Birincilimiz əlçatanlıq zonaları arasında keçid edə bildiyindən, daxil olan əlaqələr dalğası kifayət qədər tipik bir vəziyyətdir. Yəni, nədənsə köhnə birincil mövcud deyildi, bütün yük başqa bir məlumat mərkəzinə göndərildi. Onların hamısı eyni anda TLS-ə salam deməyə gələcəklər.
Və çoxlu sayda TLS əl sıxması Bouncer ilə onsuz da salamlaşa bilməz, ancaq boğazını sıxa bilər. Daxil olan əlaqə dalğası fasilə səbəbindən söndürülə bilər. Əgər eksponensial geriləmə olmadan bazaya yenidən cəhd etsəniz, onlar ardıcıl dalğada təkrar-təkrar geri qayıtmayacaqlar.
Budur, 16 nüvəni 16% yükləyən 100 PgBouncers nümunəsi.
Kaskadlı PgBouncer-ə çatdıq. Bu, Bouncer yükümüzdə əldə edə biləcəyimiz ən yaxşı konfiqurasiyadır. Xarici Bouncerlərimiz TCP-nin əl sıxması üçün xidmət edir və daxili Bouncers xarici əlaqələri çox parçalamamaq üçün həqiqi birləşdirmə üçün xidmət edir.
Bu konfiqurasiyada yumşaq yenidən başlatma mümkündür. Bütün bu 18 Bouncerləri bir-bir yenidən başlada bilərsiniz. Ancaq belə bir konfiqurasiyanı saxlamaq olduqca çətindir. Sistem administratorları, DevOps və bu server üçün həqiqətən məsul olan insanlar bu sxemdən çox məmnun olmayacaqlar.
Görünür ki, bütün təkmilləşdirmələrimiz açıq mənbədə təşviq edilə bilər, lakin Bouncer çox yaxşı dəstəkləmir. Məsələn, eyni portda birdən çox PgBouncer-i işə salmaq imkanı bir ay əvvəl verilmişdi. Bu xüsusiyyət ilə bir çəkmə sorğusu bir neçə il əvvəl idi.
Və ya daha bir misal. Postgres-də siz əlavə identifikasiya olmadan sirri başqa bir əlaqəyə göndərməklə çalışan sorğunu ləğv edə bilərsiniz. Ancaq bəzi müştərilər sadəcə olaraq TCP sıfırlaması göndərirlər, yəni şəbəkə bağlantısını pozurlar. Bouncer bununla nə edəcək? O, heç nə etməyəcək. O, sorğunu yerinə yetirməyə davam edəcək. Kiçik istəklərlə təməl qoyan çox sayda əlaqə almısınızsa, sadəcə Bouncer-dən əlaqəni kəsmək kifayət etməyəcək, verilənlər bazasında işləyən sorğuları da tamamlamalısınız.
Bu düzəldildi və problem hələ də Bouncer-in yuxarı axınına birləşdirilməyib.
Və beləliklə, belə bir nəticəyə gəldik ki, bizə inkişaf etdiriləcək, düzəldiləcək, problemləri tez bir zamanda həll etmək mümkün olacaq və əlbəttə ki, çox yivli olmalıdır.
Biz əsas vəzifə kimi multithreading qoyduq. Gələn TLS bağlantılarının dalğasını yaxşı idarə etməyi bacarmalıyıq.
Bunun üçün biz şəbəkə bağlantısının maşın vəziyyətlərini seriya kodu kimi təsvir etmək üçün nəzərdə tutulmuş Machinarium adlı ayrıca kitabxana hazırlamalı olduq. Əgər siz libpq mənbə koduna baxsanız, nəticəni sizə qaytara bilən olduqca mürəkkəb zənglər görəcəksiniz və “Biraz sonra mənə zəng edin. Hazırda məndə IO var, lakin IO keçəndə prosessorda yük var. Və bu çox səviyyəli bir sxemdir. Şəbəkə qarşılıqlı əlaqəsi adətən dövlət maşını ilə təsvir olunur. "Əgər mən əvvəllər N ölçülü paket başlığı almışamsa, indi N bayt gözləyirəm", "Sync paketi göndərmişəmsə, indi nəticə metadatası olan paketi gözləyirəm" kimi bir çox qaydalar. Nəticə olduqca çətin bir əks-intuitiv koddur, sanki labirint xətt skanına çevrildi. Biz bunu elə etdik ki, dövlət maşını əvəzinə proqramçı əsas qarşılıqlı əlaqə yolunu adi imperativ kod şəklində təsvir etsin. Məhz bu imperativ kodda, icra kontekstini başqa bir korutinə (yaşıl ip) ötürərək, şəbəkədən məlumat gözləməklə icra ardıcıllığının kəsilməsi lazım olan yerləri daxil etməlisiniz. Bu yanaşma, labirintdə ən çox gözlənilən yolu ard-arda yazmağımıza və sonra ona budaqlar əlavə etməyimizə bənzəyir.
Nəticə olaraq, TCP-ni qəbul edən və round-robin bir çox işçiyə TPC bağlantısını ötürən bir ipimiz var.
Bu halda, hər bir müştəri bağlantısı həmişə bir prosessorda işləyir. Və bu, onu önbelleğe uyğunlaşdırmağa imkan verir.
Bundan əlavə, sistem TCP yığınını boşaltmaq üçün kiçik paketlərin bir böyük paketə yığılmasını bir qədər yaxşılaşdırdıq.
Bundan əlavə, biz Odyssey, konfiqurasiya edildikdə, şəbəkə bağlantısı nasazlığı halında LƏĞV və GERİ GÖNDƏRMƏ göndərə bilməsi mənasında tranzaksiyaların birləşdirilməsini təkmilləşdirdik, yəni heç kim sorğu gözləmirsə, Odyssey verilənlər bazasına yerinə yetirməyə çalışmamağı deyəcək. qiymətli resursları israf edə biləcək tələb.
Və mümkün olduqda, biz eyni müştəri ilə əlaqə saxlayırıq. Bu, application_name_add_host-u yenidən quraşdırmaq məcburiyyətinin qarşısını alır. Mümkünsə, diaqnostika üçün lazım olan parametrlərin əlavə sıfırlanması yoxdur.
Biz Yandex.Cloud-un maraqlarına uyğun işləyirik. Əgər siz idarə olunan PostgreSQL-dən istifadə edirsinizsə və sizdə quraşdırılmış əlaqə hovuzu varsa, məntiqi replikasiyadan istifadə edərək xaricə doğru məntiqi replikasiya yarada bilərsiniz, yəni istəsəniz bizi tərk edin. Bouncer axını xaricində məntiqi təkrarlama verməz.
Bu, məntiqi təkrarlamanın qurulmasına bir nümunədir.
Bundan əlavə, xarici fiziki təkrarlama üçün dəstəyimiz var. Buludda, əlbəttə ki, mümkün deyil, çünki o zaman klaster özü haqqında sizə həddən artıq çox məlumat verəcəkdir. Ancaq quraşdırmalarınızda Odyssey-də əlaqə hovuzu vasitəsi ilə fiziki təkrarlamaya ehtiyacınız varsa, bu mümkündür.
Odyssey PgBouncer ilə tam uyğun monitorinqə malikdir. Demək olar ki, bütün eyni əmrləri yerinə yetirən eyni konsolumuz var. Əgər bir şey çatışmırsa, çəkmə sorğusu göndərin və ya ən azı GitHub-da bir problem varsa, biz lazımi əmrləri yerinə yetirəcəyik. Amma bizdə artıq PgBouncer konsolunun əsas funksionallığı var.
Və əlbəttə ki, səhv yönləndirməmiz var. Baza tərəfindən bildirilən xətanı qaytaracağıq. Siz bazada olmadığınızı deyil, niyə bazada olmadığınız barədə məlumat alacaqsınız.
PgBouncer ilə 100% uyğunluq tələb olunarsa, bu funksiya deaktiv edilir. Biz hər ehtimala qarşı Bouncer kimi davrana bilərik.
İnkişaf
Odyssey mənbə kodu haqqında bir neçə kəlmə.
Məsələn, "Pause / Resume" əmrləri var. Onlar adətən verilənlər bazasını yeniləmək üçün istifadə olunur. Postgres-i təkmilləşdirməyə ehtiyacınız varsa, onu əlaqə hovuzunda dayandıra, pg_upgrade edə və sonra davam etdirə bilərsiniz. Müştəri tərəfdən isə verilənlər bazası sadəcə yavaşlayırmış kimi görünəcək. Bu funksionallıq bizə icmadan olan insanlar tərəfindən gətirilib. O, hələ ölməyib, amma tezliklə hər şey olacaq. (artıq ölü)
- artıq ölü
Bundan əlavə, PgBouncer-in yeni xüsusiyyətlərindən biri də Yandex.Cloud-da işləməyən bir şəxs tərəfindən bizə gətirilən SCRAM Authentication dəstəyidir. Hər ikisi mürəkkəb funksionaldır və vacibdir.
Buna görə də, indi bəzi kodlar yazmaq istəsəniz, Odyssey-nin nədən hazırlandığını sizə demək istərdim.
İki əsas kitabxanaya əsaslanan orijinal Odyssey bazanız var. Kivi kitabxanası Postgres mesaj protokolunun tətbiqidir. Yəni, Postgres-in doğma proto 3, frontend və backendlərin mübadilə edə biləcəyi standart mesajlardır. Onlar Kivi kitabxanasında həyata keçirilir.
Machinarium kitabxanası mövzu tətbiqetmə kitabxanasıdır. Bu Machinarium-un kiçik bir fraqmenti assemblerdə yazılmışdır. Amma narahat olmayın, cəmi 15 sətir var.
Odyssey memarlığı. Korutinləri idarə edən əsas maşın var. Bu maşın daxil olan TCP bağlantılarını qəbul etməyi və işçilər arasında paylamağı həyata keçirir.
Bir işçi daxilində bir neçə müştəri üçün işləyici işləyə bilər. Həm də əsas mövzuda konsol və hovuzda artıq lazım olmayan əlaqələri aradan qaldırmaq üçün kron tapşırıqlarının işlənməsi fırlanır.
Odyssey standart Postgres test paketindən istifadə etməklə sınaqdan keçirilir. Biz sadəcə olaraq Bouncer və Odyssey vasitəsilə quraşdırma-yoxlama aparırıq, null div əldə edirik. Bouncer və Odyssey-də eyni uğursuz tarix formatı ilə bağlı bir neçə test var.
Bundan əlavə, öz testləri olan bir çox sürücü var. Və biz Odyssey-i sınamaq üçün onların testlərindən istifadə edirik.
Həmçinin, kaskad konfiqurasiyamız səbəbindən müxtəlif paketləri sınaqdan keçirməliyik: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, əgər Odyssey kaskadın hər hansı bir hissəsindədirsə, yenə də gözlənildiyi kimi işlədiyinə əmin olmaq üçün .
Dırmıq
Biz istehsalda Odyssey-dən istifadə edirik. Və hər şeyin sadəcə işlədiyini desəm ədalətli olmaz. Xeyr, yəni bəli, amma həmişə deyil. Məsələn, istehsalda hər şey sadəcə işləyirdi, sonra PostgreSQL Professional-dan dostlarımız gəlib dedilər ki, bizdə yaddaş sızması var. Onlar həqiqətən idi, biz onları düzəltdik. Amma sadə idi.
Sonra əlaqə hovuzunun daxil olan TLS bağlantılarına və gedən TLS bağlantılarına malik olduğunu gördük. Və bağlantılar üçün müştəri sertifikatları və server sertifikatları lazımdır.
Bouncer və Odyssey server sertifikatları pcache tərəfindən yenidən oxunur, lakin müştəri sertifikatlarının pcache-dən yenidən oxunmasına ehtiyac yoxdur, çünki bizim miqyaslana bilən Odyssey nəhayət bu sertifikatı oxuyan sistemin performansına əsaslanır. Bu, bizim üçün sürpriz oldu, çünki o, dərhal dincəlmədi. Əvvəlcə xətti miqyas aldı və 20 daxil olan eyni vaxtda əlaqədən sonra bu problem özünü göstərdi.
Pluggable Authentication Method daxili lunux alətləri ilə autentifikasiya etmək imkanıdır. PgBouncer-də o, elə həyata keçirilir ki, PAM-dan cavab gözləyən ayrıca bir ip var və cari əlaqəyə xidmət edən və onlardan PAM ipində yaşamalarını xahiş edə bilən əsas PgBouncer ipi var.
Bunu bir sadə səbəbdən həyata keçirmədik. Çoxlu axınlarımız var. Niyə bizə lazımdır?
Nəticədə, bu problemlər yarada bilər ki, əgər sizdə PAM autentifikasiyası və qeyri-PAM autentifikasiyası varsa, o zaman böyük PAM identifikasiyası dalğası PAM olmayan autentifikasiyanı əhəmiyyətli dərəcədə gecikdirə bilər. Düzəltmədiyimiz şeylərdən biridir. Ancaq bunu düzəltmək istəyirsinizsə, bunu edə bilərsiniz.
Başqa bir dırmıq, bütün daxil olan əlaqələri qəbul edən bir ipimizin olması ilə idi. Və sonra onlar TLS əl sıxma mərasiminin keçiriləcəyi işçi hovuzuna köçürülür.
Nəticədə, 20 şəbəkə bağlantısının ardıcıl dalğası varsa, onların hamısı qəbul ediləcək. Müştəri tərəfində isə libpq fasilələri bildirməyə başlayacaq. Varsayılan olaraq, orada 000 saniyə kimidir.
Əgər onlar eyni anda bazaya daxil ola bilmirlərsə, o zaman bazaya daxil ola bilməzlər, çünki bütün bunlar eksponensial olmayan təkrar cəhdlə əhatə oluna bilər.
Qəbul etdiyimiz TCP bağlantılarının sayını azaltmaq üçün PgBouncer sxemini buraya köçürdük.
Əlaqələri qəbul etdiyimizi görsək, lakin onların sonda əl sıxmağa vaxtları yoxdur, onları növbəyə qoyuruq ki, CPU resurslarını istehlak etməsinlər. Bu ona gətirib çıxarır ki, gələn bütün əlaqələr üçün eyni vaxtda əl sıxma həyata keçirilə bilməz. Ancaq yük kifayət qədər güclü olsa belə, heç olmasa kimsə verilənlər bazasına daxil olacaq.
Yol
Odisseydə gələcəkdə nə görmək istərdiniz? Biz özümüzü inkişaf etdirməyə nə hazırıq və cəmiyyətdən nə gözləyirik?
Avqust 2019 üçün.
Odyssey yol xəritəsi avqust ayında belə görünürdü:
- SCRAM və PAM identifikasiyası istədik.
- Oxunma sorğularını gözləmə rejiminə yönləndirmək istədik.
- Mən onlayn-yenidən başlamaq istərdim.
- Və serverdə fasilə vermək imkanı.
Bu yol xəritəsinin yarısı bizim tərəfimizdən deyil. Və bu yaxşıdır. Beləliklə, qalanları müzakirə edək və daha çox əlavə edək.
? İstəkləri yerinə yetirmədən sadəcə havanı qızdıracaq replikalarımız var. Bizə əvəzetmə və keçid təmin etmək üçün lazımdır. Məlumat mərkəzlərindən birində problem yaranarsa, onları faydalı işlə məşğul etmək istərdim. Çünki biz eyni mərkəzi prosessorları, eyni yaddaşı fərqli şəkildə konfiqurasiya edə bilmirik, çünki təkrarlama başqa cür işləməyəcək.
Prinsipcə, Postgres-də 10-dan başlayaraq qoşulma zamanı session_attrs təyin etmək mümkündür. Siz əlaqədəki bütün verilənlər bazası hostlarını sadalaya və verilənlər bazasına niyə getdiyinizi deyə bilərsiniz: yaz və ya yalnız oxu. Sürücü özü isə siyahıda ən çox bəyəndiyi, session_attrs tələblərinə cavab verən birinci hostu seçəcək.
Lakin bu yanaşmanın problemi onun replikasiya gecikməsinə nəzarət etməməsidir. Xidmətiniz üçün qəbuledilməz vaxtdan geri qalan bir növ replikanız ola bilər. Replikada oxunma sorğularının tam funksiyalı icrasını təmin etmək üçün əslində Odyssey-də oxumaq mümkün olmayanda işləməmək qabiliyyətini dəstəkləməliyik.
Odyssey vaxtaşırı verilənlər bazasına getməli və birincidən replikasiya məsafəsini soruşmalıdır. Əgər limitə çatmışdırsa, verilənlər bazasına yeni sorğuların daxil olmasına icazə verməyin, müştəriyə əlaqələri yenidən başlatmağınız lazım olduğunu bildirin və ola bilsin ki, sorğuları yerinə yetirmək üçün başqa host seçin. Bu, verilənlər bazasına replikasiya gecikməsini tez bir zamanda bərpa etməyə və sorğu ilə cavab vermək üçün yenidən qayıtmağa imkan verəcək.
Tətbiq tarixlərini adlandırmaq çətindir, çünki açıq mənbədir. Ancaq ümid edirəm ki, PgBouncer-dən olan həmkarları kimi 2,5 il deyil. Bu, Odyssey-də görmək istədiyim xüsusiyyətdir.
. İndi hazırlanmış bəyanatı iki yolla yarada bilərsiniz. Birincisi, bir SQL əmrini yerinə yetirə bilərsiniz, yəni "hazırlanmış". Bu SQL əmrini başa düşmək üçün Bouncer tərəfində SQL-i necə başa düşəcəyimizi öyrənməliyik. Bu həddən artıq çox olardı, çünki bizə bütün təhlilçi lazımdır. Biz hər SQL əmrini təhlil edə bilmirik.
Ancaq proto3-də mesaj protokolu səviyyəsində hazırlanmış bir bəyanat var. Və bu, hazırlanmış bəyanatın yaradıldığı barədə məlumatın strukturlaşdırılmış formada gəldiyi yerdir. Və biz başa düşə bilərik ki, bəzi server bağlantılarında müştəri hazırlanmış bəyanatlar yaratmağı xahiş edir. Və hətta əməliyyat bağlansa belə, biz hələ də server və müştərini bağlı saxlamalıyıq.
Ancaq burada dialoqda uyğunsuzluq var, çünki kimsə deyir ki, müştərinin hansı hazırlanmış ifadələri yaratdığını başa düşməlisən və server bağlantısını bu server bağlantısını yaradan bütün müştərilər arasında paylaşmalısan, yəni belə hazırlanmış bəyanatı yaradan.
Andres Freund dedi ki, əgər sizə başqa server bağlantısında artıq belə hazırlanmış bəyanat yaratmış müştəri gəlibsə, onda onu onun üçün yaradın. Ancaq müştəri əvəzinə verilənlər bazasında sorğuların yerinə yetirilməsi bir az səhv görünür, lakin verilənlər bazası ilə qarşılıqlı əlaqə üçün protokol yazan tərtibatçının nöqteyi-nəzərindən ona sadəcə şəbəkə bağlantısı verilsə rahat olardı. ki, belə hazırlanmış bir tələb var.
Və həyata keçirməli olduğumuz daha bir xüsusiyyət. İndi PgBouncer ilə uyğun monitorinqimiz var. Sorğunun orta icra müddətini qaytara bilərik. Amma orta vaxt xəstəxanada orta temperaturdur: kimsə soyuqdur, kimsə istidir - orta hesabla hər kəs sağlamdır. Bu doğru deyil.
Biz faizlər üçün dəstək tətbiq etməliyik ki, bu da resursları istehlak edən yavaş sorğuların olduğunu göstərir və monitorinqi daha məqbul edir.
Ən əsası odur ki, mən 1.0 versiyasını istəyirəm (versiya 1.1 artıq buraxılıb). Fakt budur ki, indi Odyssey 1.0rc versiyasındadır, yəni buraxılış namizədidir. Və sadaladığım bütün rake, yaddaş sızması istisna olmaqla, eyni versiya ilə düzəldilmişdir.
1.0 versiyası bizim üçün nə demək olacaq? Biz Odyssey-i bazalarımıza yayırıq. O, artıq verilənlər bazalarımızda işləyir, lakin saniyədə 1 sorğu nöqtəsinə çatdıqda, bunun buraxılış versiyası olduğunu və bunun 000 adlandırıla bilən bir versiya olduğunu söyləyə bilərik.
Cəmiyyətdəki bir neçə nəfər 1.0 versiyasında daha çox fasilə və SCRAM tələb etdi. Lakin bu o deməkdir ki, biz növbəti versiyanı istehsala yaymalı olacağıq, çünki nə SCRAM, nə də pauza hələ birləşdirilməyib. Amma çox güman ki, bu məsələ kifayət qədər tez həll olunacaq.
Çəkmə istəyinizi gözləyirəm. Bouncer ilə bağlı hansı problemləriniz olduğunu da eşitmək istərdim. Gəlin onları müzakirə edək. Bəlkə sizə lazım olan bəzi funksiyaları həyata keçirə bilərik.
Bununla mənim hissəmi yekunlaşdırıram, sizdən eşitmək istərdim. Çox sağ ol!
Suallar
Mən öz application_name-ni qoysam, Odyssey-də əməliyyatların birləşdirilməsi daxil olmaqla, düzgün atılacaqmı?
Odyssey yoxsa Bouncer?
Odisseydə. Bouncer atılır.
Bir dəst hazırlayacağıq.
Və əgər mənim həqiqi əlaqəm digər bağlantılar üzərindən keçərsə, ötürüləcəkmi?
Biz sadalanan bütün parametrlər toplusunu edəcəyik. proqram_adının bu siyahıda olub olmadığını deyə bilmərəm. Deyəsən, onu orada görüb. Bütün eyni parametrləri təyin edəcəyik. Bir sorğu ilə dəst başlanğıc zamanı müştəri tərəfindən quraşdırılmış hər şeyi edəcək.
Hesabat üçün Andrey təşəkkür edirik! Yaxşı hesabat! Mən şadam ki, Odyssey hər dəqiqə daha sürətli və daha sürətli inkişaf edir. Eyni şəkildə davam etmək istərdim. Odyssey-in eyni vaxtda müxtəlif verilənlər bazalarına, yəni qul ustasına qoşula bilməsi üçün sizdən çoxlu məlumat mənbəyi bağlantısına sahib olmağı xahiş etmişik və sonra uğursuzluqdan sonra avtomatik olaraq yeni master-a qoşula biləsiniz.
Bəli, deyəsən o müzakirəni xatırlayıram. İndi bir neçə anbar var. Amma onların arasında keçid yoxdur. Bizim tərəfimizdən serverdən onun hələ də canlı olduğunu sorğulamalı və pg_recovery-yə zəng edəcək bir uğursuzluğun baş verdiyini başa düşməliyik. Ustaya gəlmədiyimizi başa düşmək üçün standart bir yolum var. Və biz səhvlərdən bir şəkildə başa düşməliyik və ya necə? Yəni ideya maraqlıdır, müzakirə olunur. Daha çox şərh yazın. Əgər C-ni bilən işləyən əlləriniz varsa, bu ümumiyyətlə gözəldir.
Replikalar üzrə miqyaslandırma məsələsi də bizim üçün maraqlıdır, çünki biz təkrarlanan klasterlərin qəbulunu proqram tərtibatçıları üçün mümkün qədər sadə etmək istəyirik. Amma burada daha çox şərh istərdim, yəni bunu necə etmək olar, necə yaxşı etmək olar.
Sual həm də replikalara aiddir. Belə çıxır ki, sizin usta və bir neçə replikanız var. Və aydındır ki, onlar əlaqə üçün ustadan daha az replikaya gedirlər, çünki onlar arasında fərq ola bilər. Dediniz ki, məlumatlardakı fərq elə ola bilər ki, işiniz sizi qane etməyəcək və təkrarlanana qədər ora getməyəcəksiniz. Eyni zamanda, ora uzun müddət getməmisinizsə və sonra getməyə başlamısınızsa, sizə lazım olan məlumatlar dərhal mövcud olmayacaq. Yəni, biz daim ustaya gediriksə, onda önbellek orada qızdırılır və önbellek replikada bir az geri qalır.
Bəli doğrudur. İstədiyiniz pcache-də heç bir məlumat bloku olmayacaq, real keşdə istədiyiniz cədvəllər haqqında məlumat olmayacaq, planlarda təhlil edilmiş sorğular olmayacaq, ümumiyyətlə heç bir şey olmayacaq.
Bir növ klasteriniz olduqda və ora yeni bir replika əlavə etdikdə, işə başlayanda hər şey pisdir, yəni önbelleğini böyüdür.
Mən fikir aldım. Düzgün yanaşma əvvəlcə replikada sorğuların kiçik bir faizini yerinə yetirmək olardı ki, bu da keşi qızdırır. Kobud desək, bir şərtimiz var ki, ustadan 10 saniyədən çox geri qalmamalıyıq. Və bu vəziyyət bir dalğaya daxil edilməməlidir, lakin bəzi müştərilər üçün rəvan olmalıdır.
Bəli, çəkini artırın.
Bu yaxşı fikirdir. Ancaq əvvəlcə bu bağlanmanı həyata keçirməlisiniz. Əvvəlcə söndürməliyik, sonra necə yandıracağımızı düşünəcəyik. Bu, rəvan yandırmaq üçün əla xüsusiyyətdir.
nginx-də bu seçim var slowly start server üçün klasterdə. Və o, tədricən yükü artırır.
Bəli, əla fikir, buna çatanda cəhd edəcəyik.
Mənbə: www.habr.com