Citymobil-də biz MySQL verilənlər bazasından əsas davamlı məlumat yaddaşımız kimi istifadə edirik. Müxtəlif xidmətlər və məqsədlər üçün bir neçə verilənlər bazası klasterimiz var.

Ustanın daimi mövcudluğu bütün sistemin və onun ayrı-ayrı hissələrinin fəaliyyətinin kritik göstəricisidir. Master nasazlığı halında avtomatik klaster bərpası insidentlərə cavab müddətini və sistemin dayanma müddətini xeyli azaldır. Bu yazıda mən MySQL klasteri üçün yüksək əlçatanlıq (HA) dizaynına baxacağam. MySQL orkestratoru və virtual IP ünvanları (VIP).

VIP əsaslı HA həlli

Əvvəlcə məlumat saxlama sistemimizin nə olduğunu sizə qısaca deyim.

Biz bir yazmaq üçün əlçatan master və çoxlu yalnız oxumaq üçün replika ilə klassik replikasiya sxemindən istifadə edirik. Çoxluqda aralıq master ola bilər - həm replika, həm də başqaları üçün master olan qovşaq. Müştərilər HAProxy vasitəsilə replikalara daxil olurlar ki, bu da yükün bərabər paylanmasına və asan miqyaslamasına imkan verir. HAProxy-dən istifadə tarixi səbəblərlə bağlıdır və biz hazırda ProxySQL-ə keçid prosesindəyik.

Replikasiya əsasında yarı sinxron rejimdə həyata keçirilir GTID. Bu o deməkdir ki, ən azı bir replika uğurlu hesab edilməzdən əvvəl əməliyyatı daxil etməlidir. Bu təkrarlama rejimi master node nasazlığı halında performans və məlumat təhlükəsizliyi arasında optimal tarazlığı təmin edir. Əsasən bütün dəyişikliklər masterdən replikalara köçürülür Row Based Replication (RBR), lakin bəzi qovşaqlar ola bilər mixed binlog format.

Orkestrator vaxtaşırı klaster topologiyasının vəziyyətini yeniləyir, alınan məlumatları təhlil edir və problem yaranarsa, avtomatik bərpa prosedurunu işə sala bilər. Tərtibatçı prosedurun özü üçün məsuliyyət daşıyır, çünki o, müxtəlif yollarla həyata keçirilə bilər: VIP, DNS əsasında, xidmət kəşfi xidmətlərindən və ya öz-özünə yazılmış mexanizmlərdən istifadə etməklə.

Uğursuzluq halında ustanı bərpa etməyin sadə yollarından biri üzən VIP ünvanlardan istifadə etməkdir.

İrəli getməzdən əvvəl bu həll haqqında nə bilmək lazımdır:

• VIP, xüsusi fiziki şəbəkə interfeysi ilə əlaqəli olmayan bir IP ünvanıdır. Bir qovşaq uğursuz olarsa və ya planlaşdırılan texniki xidmət zamanı, biz VIP-ni minimum fasilə ilə başqa resursa keçirə bilərik.
• Virtual IP ünvanının azad edilməsi və verilməsi ucuz və sürətli bir əməliyyatdır.
• VIP ilə işləmək üçün SSH vasitəsilə serverə daxil olmaq və ya xüsusi yardım proqramlarından istifadə etmək lazımdır, məsələn, keepalived.

Sihirbazımızla bağlı mümkün problemlərə baxaq və avtomatik bərpa mexanizminin necə işlədiyini təsəvvür edək.

Master ilə şəbəkə bağlantısı itdi və ya hardware səviyyəsində problem yarandı və server əlçatan deyil

1. Orkestrator klaster topologiyasını yeniləyir, hər bir replika ustanın əlçatmaz olduğunu bildirir. Orkestrator yeni ustanın roluna uyğun replikanın seçilməsi prosesinə başlayır və bərpa etməyə başlayır.
2. Köhnə ustadan VIP-i çıxarmağa çalışırıq - müvəffəqiyyətsiz.
3. Replika usta roluna keçir. Topologiya yenidən qurulur.
4. VIP ilə yeni şəbəkə interfeysinin əlavə edilməsi. VIP-i silmək mümkün olmadığı üçün biz vaxtaşırı fonda sorğu göndərməyə başlayırıq pulsuz ARP. Bu tip sorğu/cavab sizə qoşulmuş açarlarda IP və MAC ünvanlarının xəritələşdirilməsi cədvəlini yeniləməyə imkan verir və bununla da VIP-mizin köçürülməsi barədə sizə xəbər verir. Bu, ehtimalı minimuma endirir split brain köhnə ustanı qaytararkən.
5. Bütün yeni əlaqələr dərhal yeni master-a yönləndirilir. Köhnə əlaqələr uğursuz olur və verilənlər bazasına təkrar zənglər proqram səviyyəsində edilir.

Server normal rejimdə işləyir, DBMS səviyyəsində nasazlıq baş verdi

Alqoritm əvvəlki vəziyyətə bənzəyir: topologiyanın yenilənməsi və bərpa prosesinin başlaması. Server mövcud olduğundan, biz VIP-i köhnə master üzərində uğurla buraxırıq, onu yenisinə köçürür və bir neçə ARP sorğusu göndəririk. Köhnə ustanın mümkün qaytarılması yenidən qurulmuş klasterə və tətbiqin işinə təsir etməməlidir.

Digər problemlər

Replikaların və ya ara ustaların uğursuzluğu aparmır avtomatik hərəkətlərə və əl müdaxiləsini tələb edir.

Virtual şəbəkə interfeysi həmişə müvəqqəti olaraq əlavə olunur, yəni server yenidən işə salındıqdan sonra VIP avtomatik olaraq təyin edilmir. Hər bir verilənlər bazası nümunəsi defolt olaraq yalnız oxumaq üçün rejimdə başlayır, orkestrator avtomatik olaraq yeni masteri yazmağa keçir və quraşdırmağa çalışır. read only köhnə ustanın üstündə. Bu hərəkətlər ehtimalı azaltmağa yönəlib split brain.

Bərpa prosesi zamanı problemlər yarana bilər ki, bu da standart monitorinq alətlərinə əlavə olaraq orkestr UI vasitəsilə xəbərdar edilməlidir. Bu funksiyanı əlavə etməklə REST API-ni genişləndirdik (PR hazırda nəzərdən keçirilir).

HA məhlulunun ümumi diaqramı aşağıda təqdim olunur.

Yeni usta seçimi

Orkestr kifayət qədər ağıllıdır və seçim etməyə çalışır ən uyğun replikadır aşağıdakı meyarlara uyğun olaraq yeni usta kimi:

• replika ustadan geri qalır;
• Master və replikanın MySQL versiyası;
• replikasiya növü (RBR, SBR və ya qarışıq);
• eyni və ya fərqli məlumat mərkəzlərində yerləşmə;
• mövcudluğu errant GTID — replikada icra edilmiş və masterdə olmayan əməliyyatlar;
• xüsusi seçim qaydaları da nəzərə alınır.

Hər işarə usta üçün ideal namizəd deyil. Məsələn, replika məlumatların ehtiyat nüsxəsini çıxarmaq üçün istifadə edilə bilər və ya server daha zəif aparat konfiqurasiyasına malikdir. orkestr dəstəkləyir Namizəd seçiminizi ən çox üstünlük veriləndən rədd edilənə qədər fərdiləşdirə biləcəyiniz manuel qaydalar.

Cavab və bərpa müddəti

Hadisə baş verdikdə, sistemin dayanma müddətini minimuma endirmək vacibdir, ona görə də orkestrator tərəfindən klaster topologiyasının yaradılmasına və yenilənməsinə təsir edən MySQL parametrlərini nəzərdən keçirək:

• slave_net_timeout — əlaqə itmiş və yenidən qoşulmuş kimi tanınmazdan əvvəl replikanın masterdən yeni məlumat və ya ürək döyüntüsü siqnalının gəlməsini gözlədiyi saniyələrin sayı. Dəyər nə qədər aşağı olarsa, replika usta ilə əlaqənin pozulduğunu bir o qədər tez müəyyən edə bilər. Bu dəyəri 5 saniyəyə təyin etdik.
• MASTER_CONNECT_RETRY — yenidən qoşulma cəhdləri arasında saniyələrin sayı. Şəbəkə problemləri halında, bu parametr üçün aşağı dəyər tez yenidən qoşulmağa imkan verəcək və klasterin bərpası prosesinin başlamasına mane olacaq. Tövsiyə olunan dəyər 1 saniyədir.
• MASTER_RETRY_COUNT — yenidən qoşulma cəhdlərinin maksimum sayı.
• MASTER_HEARTBEAT_PERIOD — ustanın ürək döyüntüsü siqnalını göndərdiyi saniyələrlə interval. Defolt dəyərin yarısıdır slave_net_timeout.

Orkestr seçimləri:

• DelayMasterPromotionIfSQLThreadNotUpToDate - bərabər olduqda true, sonra replikanın SQL mövzusu Relay Log-dan bütün tətbiq olunmamış əməliyyatları tamamlayana qədər əsas rol namizəd replikada tətbiq edilməyəcək. Bütün namizəd replikaları geridə qaldıqda əməliyyatları itirməmək üçün bu seçimdən istifadə edirik.
• InstancePollSeconds — topologiyanın qurulması və yenilənməsi tezliyi.
• RecoveryPollSeconds — topologiya təhlilinin tezliyi. Problem aşkar edilərsə, topologiyanın bərpası başlayır. Bu daimi, 1 saniyəyə bərabərdir.

Hər klaster qovşağı hər dəfə orkestr tərəfindən sorğulanır InstancePollSeconds saniyə Problem aşkar edildikdə, klaster vəziyyəti məcbur edilir yeniləndi, və sonra bərpa etmək üçün son qərar verilir. Müxtəlif verilənlər bazası və orkestrator parametrləri ilə sınaqdan keçirərək, cavab və bərpa müddətini 30 saniyəyə qədər azalda bildik.

Test stendi

Yerlinin inkişafı ilə HA sxemini sınaqdan keçirməyə başladıq test bench və sınaq və istehsal mühitlərində sonrakı tətbiq. Yerli stend Docker əsasında tam avtomatlaşdırılıb və orkestr və şəbəkənin konfiqurasiyası ilə təcrübə aparmağa, klasteri 2-3 serverdən bir neçə onlarla miqyasda genişləndirməyə və təhlükəsiz mühitdə təlimlər keçirməyə imkan verir.

Məşqlər zamanı problemin emulyasiya üsullarından birini seçirik: istifadə edərək ustanı dərhal vur kill -9, yumşaq bir şəkildə prosesi dayandırın və serveri dayandırın (docker-compose stop), istifadə edərək şəbəkə problemlərini simulyasiya edin iptables -j REJECT və ya iptables -j DROP. Aşağıdakı nəticələri gözləyirik:

• orkestr 10 saniyədən çox olmayan müddətdə usta ilə bağlı problemləri aşkar edəcək və topologiyanı yeniləyəcək;
• bərpa proseduru avtomatik olaraq başlayacaq: şəbəkə konfiqurasiyası dəyişəcək, ustanın rolu replikaya keçəcək, topologiya yenidən qurulacaq;
• yeni master yazıla bilən olacaq, yenidən qurma prosesində canlı replikalar itirilməyəcək;
• məlumatlar yeni masterə yazılmağa və təkrarlanmağa başlayacaq;
• Ümumi bərpa müddəti 30 saniyədən çox olmayacaq.

Bildiyiniz kimi, sistem sınaq və istehsal mühitlərində fərqli aparat və şəbəkə konfiqurasiyaları, sintetik və real yükdəki fərqlər və s. Buna görə də, biz vaxtaşırı real şəraitdə təlimlər keçiririk, şəbəkə bağlantısı itirildikdə və ya onun ayrı-ayrı hissələri pozulduqda sistemin necə davrandığını yoxlayırıq. Gələcəkdə biz hər iki mühit üçün tamamilə eyni infrastruktur qurmaq və onun sınaqlarını avtomatlaşdırmaq istəyirik.

Tapıntılar

Əsas saxlama sistemi qovşağının sağlamlığı SRE və əməliyyatlar qrupunun əsas məqsədlərindən biridir. VIP əsasında orkestr və HA həllinin tətbiqi bizə aşağıdakı nəticələrə nail olmağa imkan verdi:

• verilənlər bazası klasterinin topologiyası ilə bağlı problemlərin etibarlı aşkarlanması;
• usta ilə əlaqəli insidentlərə avtomatik və sürətli reaksiya, sistemin dayanma müddətini azaldır.

Bununla belə, həllin məhdudiyyətləri və mənfi cəhətləri var:

• HA sxeminin bir neçə məlumat mərkəzinə miqyası onların arasında vahid L2 şəbəkəsi tələb edəcək;
• Yeni ustaya VIP təyin etməzdən əvvəl onu köhnəsinə buraxmalıyıq. Proses ardıcıldır, bu da bərpa müddətini artırır;
• VIP-in buraxılması serverə SSH girişi və ya uzaqdan prosedurları çağırmaq üçün hər hansı digər üsul tələb edir. Server və ya verilənlər bazası bərpa prosesinə səbəb olan problemlərlə üzləşdiyi üçün VIP silinməsinin uğurla başa çatacağına əmin ola bilmərik. Və bu, eyni virtual IP ünvanı olan iki serverin yaranmasına və problemə səbəb ola bilər split brain.

Qaçmamaq üçün split brain, metodundan istifadə edə bilərsiniz STONIT ("Başındakı Digər Nodu Çək"), problemli düyünü tamamilə təcrid edir və ya söndürür. Klaster yüksək əlçatanlığını həyata keçirməyin başqa yolları da var: VIP və DNS, xidmət kəşfi və proksi xidmətlərinin birləşməsi, sinxron təkrarlama və öz mənfi cəhətləri və üstünlükləri olan digər üsullar.

MySQL əvəzetmə klasterinin yaradılmasına yanaşmamız haqqında danışdım. Onu həyata keçirmək asandır və mövcud şəraitdə məqbul səviyyədə etibarlılıq təmin edir. Bütövlükdə bütün sistem və xüsusən də infrastruktur inkişaf etdikcə, bu yanaşma şübhəsiz inkişaf edəcəkdir.

Mənbə: www.habr.com