Məqalənin tərcüməsi kursun tələbələri üçün xüsusi hazırlanmışdır . Bu istiqamətdə inkişaf etməkdə maraqlısınız? Sizi dəvət edirik , burada proqram, onlayn formatın xüsusiyyətləri, səriştələr və təlimdən sonra məzunları gözləyən karyera perspektivləri haqqında ətraflı danışırıq.
PostgreSQL və əlaqəyə xüsusi yazı ardıcıllığı parametrləri
Compose-da biz bir çox verilənlər bazası ilə məşğul oluruq ki, bu da bizə onların funksionallığı və çatışmazlıqları ilə daha yaxından tanış olmaq imkanı verir. Yeni verilənlər bazalarının xüsusiyyətlərini sevməyi öyrəndikcə, bəzən uzun müddətdir işlədiyimiz daha yetkin alətlərdə oxşar xüsusiyyətlərin olmasının nə qədər gözəl olacağını düşünməyə başlayırıq. PostgreSQL-də görmək istədiyim yeni xüsusiyyətlərdən biri bütün klasterdə hər bir əlaqə üçün konfiqurasiya edilə bilən yazma ardıcıllığı idi. Və göründüyü kimi, bizdə artıq var və bu gün ondan necə istifadə edə biləcəyiniz barədə məlumatı sizinlə bölüşmək istəyirik.
Mənə niyə lazımdır?
Klasterin necə davranması tətbiqinizdən asılıdır. Məsələn, faktura ödəmə proqramını götürək. Sizə klaster üzrə XNUMX% ardıcıllıq lazımdır, ona görə də verilənlər bazanız bütün dəyişikliklərin edilməsini gözləməsi üçün sinxron tapşırıqları aktivləşdirməli olacaqsınız. Bununla belə, əgər ərizəniz sürətlə böyüyən sosial şəbəkədirsə, yəqin ki, XNUMX% ardıcıllıqdan daha sürətli cavaba üstünlük verəcəksiniz. Buna nail olmaq üçün klasterinizdə asinxron öhdəliklərdən istifadə edə bilərsiniz.
Kompromislə tanış olun
Məlumatların ardıcıllığı və performansı arasında güzəştlər etməlisiniz. PostgreSQL ardıcıllıqdan uzaqlaşır, çünki defolt konfiqurasiya daha sonra proqnozlaşdırıla bilər və gözlənilməz sürprizlər olmadan. İndi kompromislərə baxaq.
Mübadilə 1: Performans
PostgreSQL klasteri ardıcıllıq tələb etmirsə, asinxron işləyə bilər. Yazı klaster rəhbərinə edilir və yeniləmələr bir neçə millisaniyə sonra onun replikalarına göndəriləcək. PostgreSQL klasteri ardıcıllıq tələb etdikdə o, sinxron işləməlidir. Yazma klaster rəhbərinə ediləcək, o, replikalara yeniləmə göndərəcək və hər birinin uğurlu olduğunu yazmağa başlayan müştəriyə təsdiq göndərməzdən əvvəl yazdığının təsdiqini gözləyəcək. Bu yanaşmalar arasındakı praktik fərq ondan ibarətdir ki, asinxron metod iki şəbəkə hoppunu tələb edir, sinxron metod isə dörd tələb edir.
Mübadilə 2: Ardıcıllıq
Bu iki yanaşmada liderin uğursuzluğu halında nəticə də fərqli olacaq. Əgər iş asinxron şəkildə yerinə yetirilirsə, onda belə bir səhv baş verərsə, replikalar tərəfindən bütün qeydlər aparılmayacaq. Nə qədər itiriləcək? Tətbiqin özündən və təkrarlamanın effektivliyindən asılıdır. Tərtib edilmiş replikasiya replikanın lider olmasının qarşısını alacaq, əgər onun içindəki məlumatın miqdarı liderdən 1 MB azdırsa, yəni asinxron əməliyyat zamanı potensial olaraq 1 MB-a qədər qeyd itirilə bilər.
Sinxron rejimdə bu baş vermir. Lider uğursuz olarsa, bütün replikalar yenilənir, çünki liderdə təsdiqlənmiş hər hansı yazı replikalarda təsdiqlənməlidir. Bu ardıcıllıqdır.
Sinxron davranış, ardıcıllığın ardıcıllıq və performans arasında rəqabətdə açıq üstünlüyə malik olduğu faktura tətbiqində məna kəsb edir. Belə bir tətbiq üçün ən vacib şey etibarlı məlumatlardır. İndi əsas vəzifəsinin sorğulara mümkün qədər tez cavab verməklə istifadəçinin diqqətini saxlamaqdan ibarət olduğu bir sosial şəbəkə haqqında düşünün. Bu halda, daha az şəbəkə atlamaları və daha az gözləmə ilə performans prioritet olacaqdır. Bununla belə, performans və ardıcıllıq arasındakı mübadilə, düşünməli olduğunuz yeganə şey deyil.
Mübadilə 3: Qəzalar
Uğursuzluq zamanı klasterin necə davrandığını başa düşmək çox vacibdir. Bir və ya bir neçə replikanın uğursuz olduğu bir vəziyyəti nəzərdən keçirin. Öhdəliklər asinxron şəkildə işləndikdə, lider çatışmayan replikaları gözləmədən işləməyə davam edəcək, yəni yazıları qəbul edib emal edəcək. Replikalar klasterə qayıdanda liderə çatırlar. Sinxron replikasiya ilə replikalar cavab vermirsə, o zaman liderin seçimi qalmayacaq və replika klasterə qayıdana və yazını qəbul edib icra edə bilənə qədər öhdəliyin təsdiqini gözləməyə davam edəcək.
Hər əməliyyat üçün bir əlaqə?
Hər bir tətbiq ardıcıllıq və performansın fərqli birləşməsinə ehtiyac duyur. Əlbəttə ki, bu, bizim tamamilə ardıcıl olduğunu təsəvvür etdiyimiz ödənişli tətbiqimiz və ya demək olar ki, müvəqqəti sosial şəbəkə tətbiqimiz olmasa. Bütün digər hallarda, bəzi əməliyyatların sinxron, bəzilərinin isə asinxron olması lazım olduğu vaxtlar olacaq. Söhbətə göndərilən mesajın qəbuluna qədər sistemin gözləməsini istəməyə bilərsiniz, lakin ödəniş eyni proqramda həyata keçirilirsə, siz gözləməli olacaqsınız.
Bütün bu qərarlar, əlbəttə ki, proqram tərtibatçısı tərəfindən verilir. Hər bir yanaşmanın nə vaxt istifadə ediləcəyi ilə bağlı düzgün qərarların qəbul edilməsi, klasterinizdən maksimum fayda əldə etməyə kömək edəcək. Tərtibatçının əlaqələr və əməliyyatlar üçün SQL səviyyəsində onlar arasında keçid edə bilməsi vacibdir.
Praktikada nəzarətin təmin edilməsi
Varsayılan olaraq, PostgreSQL ardıcıllığı təmin edir. Bu server parametri ilə idarə olunur synchronous_commit. Varsayılan olaraq vəziyyətdədir on, lakin onun üç başqa variantı var: local, remote_write və ya off.
Parametr təyin edərkən off bütün sinxron tapşırıqlar, hətta yerli sistemdə də dayandırılır. Lokal parametr yerli sistem üçün sinxron rejimi müəyyən edir, lakin replikalara yazılar asinxron şəkildə həyata keçirilir. Remote_write daha da irəli gedir: replikalara yazılar asinxron edilir, lakin replika yazmağı qəbul edib diskə yazmadıqda geri qaytarılır.
Mövcud variantları nəzərə alaraq, biz davranış seçirik və bunu nəzərə alaraq on – bunlar sinxron yazılardır, biz seçəcəyik local şəbəkə üzərindən asinxron öhdəçiliklər üçün, yerli icraları isə sinxron tərk edir.
İndi biz sizə bunu necə quracağınızı bir azdan deyəcəyik, ancaq bizim qurduğumuzu təsəvvür edin synchronous_commit в local server üçün. Parametrin dəyişdirilməsinin mümkün olub-olmaması ilə maraqlandıq synchronous_commit tez və məlum oldu ki, bu nəinki mümkün, hətta bunun iki yolu var. Birincisi, əlaqənizin sessiyasını aşağıdakı kimi təyin etməkdir:
SET SESSION synchronous_commit TO ON;
// Your writes go hereSessiyadakı bütün sonrakı yazılar, əlaqəli müştəriyə müsbət nəticə qaytarmazdan əvvəl replikalara yazılanları təsdiq edəcək. Əlbəttə ki, parametrləri dəyişdirməyincə synchronous_commit yenidən. Siz hissəni buraxa bilərsiniz SESSION əmrdə, çünki standart dəyərdə olacaq.
İkinci üsul, yalnız bir əməliyyat üçün sinxron replikasiya əldə etdiyinizə əmin olmaq istədiyiniz zaman yaxşıdır. Bir çox NoSQL nəsil verilənlər bazasında əməliyyatlar anlayışı mövcud deyil, lakin PostgreSQL-də mövcuddur. Bu halda siz əməliyyata başlayırsınız və sonra təyin edirsiniz synchronous_commit в on əməliyyat üçün girişi yerinə yetirməzdən əvvəl. COMMIT hər hansı parametr dəyərindən istifadə edərək əməliyyatı həyata keçirəcək synchronous_commit, o zaman təyin edilmişdi, baxmayaraq ki, digər tərtibatçıların yazmaların asinxron olmadığını başa düşmələrinə əmin olmaq üçün dəyişəni əvvəlcədən təyin etmək daha yaxşıdır.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Verilənlər bazası əlaqəli müştəriyə müsbət cavab qaytarmazdan əvvəl bütün əməliyyat öhdəlikləri indi replikalara yazıldığı kimi təsdiqlənəcək.
PostgreSQL konfiqurasiyası
Bundan əvvəl biz PostgreSQL sistemini təsəvvür edirdik synchronous_commit, quraşdırılmışdır local. Bunu server tərəfində reallaşdırmaq üçün iki server konfiqurasiya variantını təyin etməlisiniz. Daha bir parametr synchronous_standby_names nə vaxt özünə gələcək synchronous_commit içəridə olacaq on. O, hansı replikaların sinxron tapşırıqlar üçün uyğun olduğunu müəyyən edir və biz bunu təyin edəcəyik *, bu, bütün replikaların iştirak etdiyini bildirir. Bu dəyərlər adətən konfiqurasiya edilir əlavə etməklə:
synchronous_commit = local
synchronous_standby_names='*'Parametr təyin etməklə synchronous_commit mənaya keçir local, biz yerli disklərin sinxron qaldığı bir sistem yaradırıq, lakin şəbəkə replikasının icrası defolt olaraq asinxrondur. Təbii ki, yuxarıda göstərildiyi kimi bu öhdəlikləri sinxronlaşdırmağa qərar verməsək.
Əgər inkişafı izləyirsinizsə , bəzi son dəyişiklikləri müşahidə etmisiniz (, ), Qubernator istifadəçilərinə bu parametrləri sınamağa və onların ardıcıllığına nəzarət etməyə imkan verdi.
Daha bir neçə söz...
Cəmi bir həftə əvvəl sizə deyərdim ki, PostgreSQL-i bu qədər incə tənzimləmək mümkün deyil. Məhz o zaman Compose platforma komandasının üzvü Kurt belə bir fürsətin mövcud olduğunu israr etdi. O, etirazlarımı sakitləşdirdi və PostgreSQL sənədlərində tapdı :
Bu parametr istənilən vaxt dəyişdirilə bilər. Hər hansı bir əməliyyatın davranışı, törədilmə zamanı qüvvədə olan parametrlə müəyyən edilir. Buna görə də, bəzi əməliyyatların sinxron, digərləri üçün isə asinxron şəkildə həyata keçirilməsi mümkündür və faydalıdır. Məsələn, birini məcbur etmək multistatement Parametrin defolt dəyəri əks olduqda, asinxron şəkildə icra etmək üçün əməliyyat təyin edin SET LOCAL synchronous_commit TO OFF bir əməliyyatda.
Konfiqurasiya faylına edilən bu kiçik dəyişikliklə biz istifadəçilərə onların ardıcıllığına və performansına nəzarət etdik.
Mənbə: www.habr.com