İstənilən böyük layihə bir neçə serverlə başladı. Əvvəlcə bir DB server var idi, sonra oxunuşun miqyası üçün ona qullar əlavə edildi. Və sonra - dayan! Bir ağa var, amma çoxlu qul var; qullardan biri getsə, onda hər şey yaxşı olacaq, amma master getsə, pis olacaq: fasilələr, adminlər serveri qaldırmağa çalışırlar. Nə etməli? Usta rezerv edin. Bu barədə həmkarım Pavel artıq yazıb , təkrar etməyəcəyəm. Bunun əvəzinə sizə MySQL üçün Orchestrator niyə mütləq lazım olduğunu söyləyəcəyəm!
Əsas sualdan başlayaq: "Usta gedəndə kodu yeni maşına necə keçirəcəyik?"
- Ən çox VIP (Virtual IP) ilə sxemi bəyənirəm, bu barədə aşağıda danışacağıq. Bu, açıq bir məhdudiyyətə malik olsa da, ən sadə və ən açıqdır: rezerv edəcəyimiz master yeni maşınla L2 seqmentində olmalıdır, yəni ikinci DC-ni unuda bilərik. Və mehriban bir şəkildə, böyük bir L2-nin pis olması qaydasına əməl etsəniz, çünki L2 yalnız rack başına, L3 isə raflar arasındadır və belə bir sxem daha çox məhdudiyyətlərə malikdir.
- Siz kodda DNS adını yaza və onu /etc/hosts vasitəsilə həll edə bilərsiniz. Əslində, heç bir həll yolu olmayacaq. Sxemin üstünlüyü: birinci metodun heç bir məhdudiyyət xarakteristikası yoxdur, yəni çarpaz DC təşkil etmək mümkündür. Ancaq sonra açıq sual yaranır: dəyişikliyi Puppet-Ansible vasitəsilə /etc/hosts-a nə qədər tez çatdıra bilərik?
- İkinci üsulu bir az dəyişə bilərsiniz: kodun əsas verilənlər bazasına gedəcəyi bütün veb serverlərdə keş DNS-ni quraşdırın. DNS-də bu giriş üçün TTL 60 təyin edə bilərsiniz. Görünür, düzgün həyata keçirilsə, üsul yaxşıdır.
- Konsulun istifadəsini nəzərdə tutan xidmət kəşfi ilə sxem və s.
- ilə maraqlı bir seçim . ProxySQL vasitəsilə bütün trafiki MySQL-ə yönləndirmək lazımdır; ProxySQL özü kimin master olduğunu müəyyən edə bilər. Yeri gəlmişkən, bu məhsuldan istifadə variantlarından biri haqqında mənim məqaləmdə oxuya bilərsiniz .
Github-da işləyən Orchestrator müəllifi əvvəlcə VIP ilə ilk sxemi həyata keçirdi, sonra konsulla sxemə çevirdi.
Tipik infrastruktur planı:
Dərhal nəzərə alınmalı olan açıq vəziyyətləri təsvir edəcəyəm:
- VIP ünvanı heç bir serverdə konfiqurasiyada qeyd edilməməlidir. Gəlin bir vəziyyəti təsəvvür edək: usta yenidən başladı və yüklənərkən Orchestrator uğursuzluq rejiminə keçdi və qullardan birini master etdi; sonra qoca usta qalxdı, indi VİP iki maşındadır. Bu pisdir.
- Orkestr üçün köhnə ustaya və yeni ustaya zəng etmək üçün bir skript yazmalısınız. Köhnə master-da ifdown, yeni master-da isə ifup vip-i işə salmaq lazımdır. Bu skriptə uğursuzluq halında, hər hansı bir splitbrain qarşısını almaq üçün köhnə master keçidindəki portun sadəcə söndürüldüyünü daxil etmək yaxşı olardı.
- Orkestrator əvvəlcə VIP-i çıxarmaq və/yaxud keçiddəki portu söndürmək üçün skriptinizə zəng etdikdən və sonra yeni master-da VIP yüksəltmə skriptini çağırdıqdan sonra hər kəsə yeni VIP-in indi olduğunu bildirmək üçün arping əmrindən istifadə etməyi unutmayın. burada.
- Bütün qullar yalnız_oxu=1 olmalıdır və siz qulu ustaya təqdim edən kimi o, yalnız_oxu=0 olmalıdır.
- Unutmayın ki, bunun üçün seçdiyimiz hər hansı bir qul usta ola bilər (Orkestratorun bütöv bir üstünlük mexanizmi var, hansı qulu ilk növbədə yeni ustaya namizəd kimi nəzərdən keçirməli, hansı ikinci və hansı qul olmalıdır heç bir halda usta seçilə bilməz). Əgər qul ağa olarsa, onda qulun yükü onun üzərində qalacaq və ağanın yükü əlavə olunacaq, bunu nəzərə almaq lazımdır.
Orkestr yoxdursa niyə sizə lazımdır?
- Orchestrator bütün topologiyanı göstərən çox istifadəçi dostu qrafik interfeysə malikdir (aşağıdakı ekran görüntüsünə baxın).
- Orkestrator hansı qulların geridə qaldığını və replikasiyanın ümumiyyətlə pozulduğunu izləyə bilər (SMS göndərmək üçün Orchestrator-a əlavə edilmiş skriptlərimiz var).
- Orchestrator sizə hansı qulların GTID səhvinin olduğunu söyləyir.
Orkestr interfeysi:
GTID səhvi nədir?
Orkestratorun işləməsi üçün iki əsas tələb var:
- Pseudo GTID-in MySQL klasterindəki bütün maşınlarda aktiv olması lazımdır; bizdə GTID aktivdir.
- Hər yerdə bir növ binlog olması lazımdır, siz ifadədən istifadə edə bilərsiniz. Bizdə master və əksər qulların Sıraya malik olduğu və ikisinin tarixən Qarışıq rejimdə qaldığı bir konfiqurasiyamız var idi. Nəticədə Orchestrator sadəcə olaraq bu qulları yeni ustaya bağlamaq istəmədi.
Unutmayın ki, istehsal qulunda ən vacib şey onun usta ilə uyğunluğudur! Əgər siz həm master, həm də qulda Qlobal Transaction ID-ni (GTID) aktivləşdiribsinizsə, o zaman gtid_subset funksiyasından istifadə edərək, verilənlərin dəyişdirilməsi üçün eyni sorğuların həqiqətən bu maşınlarda icra edilib-edilmədiyini öyrənə bilərsiniz. Bu barədə ətraflı oxuya bilərsiniz .
Beləliklə, Orchestrator sizə GTID səhvi vasitəsilə qulda masterdə olmayan əməliyyatların olduğunu göstərir. Bu niyə baş verir?
- Read_only=1 qulda aktiv edilməyib, kimsə qoşulub və datanın dəyişdirilməsi sorğusunu tamamlayıb.
- Super_read_only=1 qulda aktiv deyil, sonra admin serveri çaşdıraraq içəri daxil olub sorğunu orada yerinə yetirdi.
- Əvvəlki hər iki məqamı nəzərə alsanız, onda daha bir hiylə var: MySQL-də binlogları təmizləmək tələbi də binlog-a gedir, buna görə də ilk silmədə master və bütün kölələrdə GTID səhvi görünəcək. Bunun qarşısını necə almaq olar? Perona-5.7.25-28 binlog_skip_flush_commands=1 parametrini təqdim etdi ki, bu da binloglara flush yazmağı qadağan edir. mysql.com saytında qurulmuş biri var .
İcazə verin yuxarıdakıların hamısını ümumiləşdirim. Orchestrator-u hələ uğursuzluq rejimində istifadə etmək istəmirsinizsə, onu müşahidə rejiminə qoyun. Onda sizin gözləriniz qarşısında həmişə MySQL maşınlarının qarşılıqlı əlaqə xəritəsi və hər bir maşında replikasiyanın hansı növü olduğu, qulların geridə qalıb-qalmaması, ən əsası isə onların master ilə nə qədər ardıcıl olması barədə vizual məlumat olacaq!
Açıq sual budur: "Orkestr necə işləməlidir?" O, cari qullardan yeni master seçməli və sonra bütün qulları ona yenidən qoşmalıdır (bu, GTID üçün lazımdır; əgər köhnə mexanizmdən binlog_name və binlog_pos ilə istifadə edirsinizsə, o zaman qulu cari masterdan yenisinə keçirin. sadəcə mümkün deyil!). Orkestrimiz olmamışdan əvvəl mən bir dəfə bütün bunları əl ilə etməli idim. Köhnə usta arabası Adaptec nəzarətçisinə görə asılmışdı; onun təxminən 10 qulu var idi. Mənə VIP-i ustadan qullardan birinə köçürməli və bütün digər qulları ona yenidən bağlamalı idim. Neçə konsol açmalı idim, neçə eyni vaxtda əmrlər daxil etdim... Gecə 3-ə qədər gözləməli oldum, ikidən başqa bütün qullardan yükü götürdüm, iki ustadan birinci maşını düzəltdim, dərhal ikinci maşını bağladım. ona görə də bütün digər qulları yeni ustaya bağlayın və yükü qaytarın. Ümumiyyətlə, dəhşətli...
Orchestrator uğursuzluq rejiminə keçəndə necə işləyir? Bu, ustanı indi olduğundan daha güclü, daha müasir maşın etmək istədiyimiz bir vəziyyətin nümunəsi ilə ən asan şəkildə təsvir olunur.
Şəkil prosesin ortasını göstərir. Bu vaxta kimi artıq nə edilib? Biz dedik ki, hansısa qulu yeni usta etmək istəyirik, Orchestrator sadəcə olaraq bütün digər qulları ona yenidən qoşmağa başladı, yeni usta isə tranzit maşın kimi fəaliyyət göstərdi. Bu sxemlə heç bir səhv baş vermir, bütün qullar işləyir, Orchestrator VIP-i köhnə masterdən çıxarır, yenisinə köçürür, yalnız read_only=0 edir və köhnə master haqqında unudur. Hamısı! Xidmətimizin dayanma müddəti 2-3 saniyə olan VIP köçürmə vaxtıdır.
Bu günə qədər bu qədər, hamınıza təşəkkür edirəm. Tezliklə Orchestrator haqqında ikinci məqalə olacaq. Məşhur sovet filmi "Qaraj"da bir personaj dedi: "Mən onunla kəşfiyyata getməzdim!" Beləliklə, orkestr, mən də sizinlə kəşfiyyata gedərdim!
Mənbə: www.habr.com