Hamıya salam. Vladislav Rodin əlaqə saxlayır. Hazırda OTUS-da proqram təminatının memarlığı və yüksək gərginlikli proqram arxitekturası üzrə kurslar tədris edirəm. Yeni kurs axınının başlaması ərəfəsində Mən sizinlə bölüşmək istədiyim orijinal materialdan qısa bir parça yazmaq qərarına gəldim.
Giriş
HDD yalnız saniyədə təxminən 400-700 əməliyyat yerinə yetirə bildiyinə görə (bu, yüksək yüklü sistemdə tipik rps ilə müqayisə olunmazdır), klassik disk verilənlər bazası arxitekturanın darboğazıdır. Buna görə də, bu anbarın miqyaslı modellərinə xüsusi diqqət yetirmək lazımdır.
Hal-hazırda, verilənlər bazası miqyasının 2 nümunəsi var: təkrarlama və parçalanma. Sharding sizə yazma əməliyyatını miqyaslandırmağa imkan verir və nəticədə klasterinizdə hər serverə yazılan rps-ni azaldır. Replikasiya eyni şeyi etməyə imkan verir, lakin oxu əməliyyatları ilə. Bu məqalənin həsr olunduğu nümunə budur.
replikasiya
Replikasiyaya çox yüksək səviyyədə baxsanız, bu, sadə bir şeydir: bir serveriniz var idi, orada məlumat var idi və sonra bu server bu məlumatları oxumaq yükünün öhdəsindən gələ bilmədi. Siz daha bir neçə server əlavə edirsiniz, məlumatları bütün serverlər arasında sinxronlaşdırırsınız və istifadəçi klasterinizdəki istənilən serverdən oxuya bilər.
Görünən sadəliyinə baxmayaraq, bu sxemin müxtəlif tətbiqlərini təsnif etmək üçün bir neçə variant var:
- Klasterdəki rollara görə (master-master və ya master-slave)
- Göndərilən obyektlərə görə (sətir əsaslı, bəyanata əsaslanan və ya qarışıq)
- Düyün sinxronizasiya mexanizminə görə
Bu gün 3-cü bəndlə məşğul olacağıq.
Əməliyyat öhdəliyi necə baş verir?
Bu mövzu replikasiya ilə birbaşa əlaqəli deyil, bu barədə ayrıca məqalə də yazıla bilər, lakin əməliyyatın icra mexanizmini başa düşmədən əlavə oxumaq faydasız olduğundan, sizə ən əsas şeyləri xatırlatmağa icazə verin. Əməliyyat öhdəliyi 3 mərhələdə baş verir:
- Bir əməliyyatın verilənlər bazası jurnalına daxil edilməsi.
- Verilənlər bazası mühərrikində əməliyyatdan istifadə.
- Müştəriyə əməliyyatın uğurla tətbiq olunduğuna dair təsdiqin qaytarılması.
Fərqli verilənlər bazalarında bu alqoritmin nüansları ola bilər: məsələn, MySQL verilənlər bazasının InnoDB mühərrikində 2 log var: biri replikasiya (ikili jurnal), digəri PostgreSQL-də olarkən ACID (geri al/redo log) saxlamaq üçün hər iki funksiyanı yerinə yetirən bir jurnal var (qabaqda yazmaq log = WAL). Ancaq yuxarıda təqdim olunanlar məhz ümumi konsepsiyadır ki, bu da belə nüansların nəzərə alınmamasına imkan verir.
Sinxron (sinxron) replikasiya
Alınan dəyişiklikləri əməliyyatların icrası alqoritminə təkrarlamaq üçün məntiq əlavə edək:
- Bir əməliyyatın verilənlər bazası jurnalına daxil edilməsi.
- Verilənlər bazası mühərrikində əməliyyatdan istifadə.
- Məlumatların bütün replikalara göndərilməsi.
- Bütün replikalardan onlar üzrə əməliyyatın tamamlandığına dair təsdiqin alınması.
- Müştəriyə əməliyyatın uğurla tətbiq olunduğuna dair təsdiqin qaytarılması.
Bu yanaşma ilə bir sıra çatışmazlıqlar əldə edirik:
- müştəri dəyişikliklərin bütün replikalara tətbiq edilməsini gözləyir.
- klasterdəki qovşaqların sayı artdıqca, yazma əməliyyatının uğurlu olacağı ehtimalını azaldırıq.
Əgər 1-ci nöqtə ilə hər şey az-çox aydındırsa, 2-ci bəndin səbəblərini izah etməyə dəyər. Sinxron replikasiya zamanı ən azı bir qovşaqdan cavab almasaq, əməliyyatı geri qaytarırıq. Beləliklə, klasterdəki qovşaqların sayını artırmaqla, yazma əməliyyatının uğursuz olma ehtimalını artırırsınız.
Yalnız müəyyən bir qovşaq faizindən, məsələn, 51%-dən (kvorum) təsdiq gözləyə bilərikmi? Bəli, edə bilərik, lakin klassik versiyada bütün qovşaqlardan təsdiq tələb olunur, çünki biz klasterdə məlumatların tam ardıcıllığını belə təmin edə bilərik ki, bu da bu tip replikasiyanın şübhəsiz üstünlüyüdür.
Asinxron (async) replikasiya
Əvvəlki alqoritmi dəyişdirək. Biz məlumatları “bir müddət sonra” replikalara göndərəcəyik və “bir müddət sonra” dəyişikliklər replikalara tətbiq olunacaq:
- Bir əməliyyatın verilənlər bazası jurnalına daxil edilməsi.
- Verilənlər bazası mühərrikində əməliyyatdan istifadə.
- Müştəriyə əməliyyatın uğurla tətbiq olunduğuna dair təsdiqin qaytarılması.
- Məlumatların replikalara göndərilməsi və onlara dəyişikliklərin tətbiqi.
Bu yanaşma klasterin tez işləməsinə gətirib çıxarır, çünki biz müştərini məlumatların replikalara çatmasını və hətta təhvil verilməsini gözləmirik.
Lakin məlumatların "bir müddət sonra" replikalara atılması şərti əməliyyatın itirilməsinə və istifadəçi tərəfindən təsdiqlənmiş əməliyyatın itirilməsinə səbəb ola bilər, çünki məlumatların təkrarlanması üçün vaxt yox idisə, müştəriyə təsdiq. əməliyyatın müvəffəqiyyəti haqqında göndərildi və dəyişikliklərin gəldiyi node HDD qəzaya uğradı, biz əməliyyatı itiririk, bu da çox xoşagəlməz nəticələrə səbəb ola bilər.
Yarımsinxron replikasiya
Nəhayət, yarı sinxron replikasiyaya keçirik. Bu tip replikasiya çox yaxşı məlum deyil və ya çox yaygın deyil, lakin o, həm sinxron, həm də asinxron replikasiyanın üstünlüklərini birləşdirə bildiyi üçün kifayət qədər maraq doğurur.
Əvvəlki 2 yanaşmanı birləşdirməyə çalışaq. Biz müştərini uzun müddət saxlamayacağıq, lakin məlumatların təkrarlanmasını tələb edəcəyik:
- Bir əməliyyatın verilənlər bazası jurnalına daxil edilməsi.
- Verilənlər bazası mühərrikində əməliyyatdan istifadə.
- Məlumatların replikalara göndərilməsi.
- Dəyişikliklərin alındığına dair replikadan təsdiqin alınması (onlar “bir müddət sonra” tətbiq olunacaq).
- Müştəriyə əməliyyatın uğurla tətbiq olunduğuna dair təsdiqin qaytarılması.
Nəzərə alın ki, bu alqoritmlə əməliyyat itkisi yalnız dəyişiklikləri qəbul edən node və replika node uğursuz olduqda baş verir. Belə bir uğursuzluq ehtimalı aşağı hesab olunur və bu risklər qəbul edilir.
Ancaq bu yanaşma ilə fantom oxunması riski var. Aşağıdakı ssenarini təsəvvür edək: 4-cü addımda biz heç bir replikadan təsdiq almadıq. Biz bu əməliyyatı geri qaytarmalıyıq və müştəriyə təsdiqi qaytarmamalıyıq. Məlumatlar 2-ci addımda tətbiq olunduğundan, 2-ci addımın sonu ilə əməliyyatın geri qaytarılması arasında vaxt boşluğu var, bu müddət ərzində paralel əməliyyatlar verilənlər bazasında olmamalı olan dəyişiklikləri görə bilər.
İtirməyən yarımsinxron replikasiya
Bir az düşünsəniz, yalnız alqoritmin addımlarını tərsinə çevirə və bu ssenaridə fantom oxunma problemini həll edə bilərsiniz:
- Bir əməliyyatın verilənlər bazası jurnalına daxil edilməsi.
- Replika datası göndərilir.
- Dəyişikliklərin alındığına dair replikadan təsdiqin alınması (onlar “bir müddət sonra” tətbiq olunacaq).
- Verilənlər bazası mühərrikində əməliyyatdan istifadə.
- Müştəriyə əməliyyatın uğurla tətbiq olunduğuna dair təsdiqin qaytarılması.
İndi biz dəyişiklikləri yalnız təkrarlandıqda həyata keçiririk.
Buraxılış
Həmişə olduğu kimi, ideal həll yolları yoxdur, hər birinin öz üstünlükləri və mənfi cəhətləri olan və müxtəlif sinif problemlərinin həlli üçün uyğun olan bir sıra həllər var. Bu, təkrarlanan verilənlər bazasında məlumatların sinxronlaşdırılması mexanizminin seçilməsi üçün tamamilə doğrudur. Yarımsinxron replikasiyanın malik olduğu üstünlüklər toplusu kifayət qədər möhkəm və maraqlıdır ki, onun aşağı yayılmasına baxmayaraq, diqqətə layiq hesab edilə bilər.
Hamısı budur. görüşənədək !
Mənbə: www.habr.com