🥇Fayl sistemlərinin incə təminatı LinuxÜç Terabaytlıq MySQL Verilənlər Bazasının İşçi Nüsxələrini 20 Saniyədə Necə Yaratmaq olar

Mənim adım Yuridir və mən Citymobil şirkətində sistem administrasiyası qrupunun rəhbəriyəm. Bu gün fayl sistemləri üçün nazik təminat texnologiyası ilə işləmək təcrübəmi sizinlə bölüşəcəyəm. Linux Bunun şirkətin CI/CD proseslərində necə tətbiq oluna biləcəyini izah edəcəyəm. Kodu istehsalata çatdırarkən avtomatik olaraq test etmək üçün MySQL verilənlər bazasının istehsal versiyasına mümkün qədər yaxın oxuma-yazma nüsxələrinə ehtiyac duyduğumuz bir vəziyyəti araşdıracağıq.

Giriş: Niyə pis məsləhət verirsiniz?

Məntiqi sual, çünki verilənlər bazası sxemlərinin test mühitlərinə köçürülməsi üçün sübut edilmiş mexanizmlər mövcuddur. Niyə hətta əsas qeyri-parçalanmamış DBMS-ni belə həcmlərə genişləndirmək lazımdır? Və bütün məlumatlar sınaq üçün lazım deyil. Mən izah etməyə çalışacağam.

Təxminən bir il əvvəl, taksi aqreqatorumuzun aktiv böyüməsi fonunda (2018-ci ildə tamamlanan səfərlər təxminən 15 dəfə artdı), məlumatların həcmi, serverlərə yüklənmə və buraxılışların tezliyi artdı. Biz özümüzü aşağıdakı vəziyyətdə tapdıq:

Əsas MySQL verilənlər bazası ümumi həcmi 1000 TB olan təxminən 2,5 cədvələ qədər böyüdü və böyüməyə davam etdi.
Tez parçalanmaq və bazanı məhv etmək üçün heç bir yol yox idi. Buna köhnə yanaşma “Mən verilənlər bazasına nə istədiyimi və necə istədiyimi yazıram”, bir dəstə JOIN və daxili cədvəl asılılığı ilə icazə verilmədi.
Verilənlər bazası sxemini test mühitlərinə köçürmək üçün heç bir mexanizm yox idi.
Yerləşdirmə zamanı kodun avtomatik sınaqdan keçirilməsi yox idi.

Son problemi mümkün qədər tez həll etmək istədim. Əsas PHP monolitini yoxlamaq üçün poçtalyon testləri artıq yazılmışdı, lakin müasir verilənlər bazası yox idi. Eyni zamanda, biz gecə bir nüsxə yarada, onu usta hala gətirə və gün ərzində onu parçalanmağa buraxa bilməzdik: çox sayda buraxılış və dəyişikliklər, o cümlədən məlumat və verilənlər bazası sxemində, günün ortasında stend işləmir. Təklifləri yalnız bir iş günü ilə məhdudlaşdırmaq səmərəsiz olardı.

Buna baxmayaraq, tapşırıq yerinə yetirildi: iki həftə ərzində ilk işçi stendi aldıq. Keçən il ərzində bir çox dəyişikliklərə məruz qaldı və istifadə olunmağa davam edir.

Sonra, həllimizin bütün mərhələlərini və inkişaf mərhələlərini ətraflı təsvir edəcəyəm. Bu metodun mövcud olmaq hüququna layiq olduğunu görəcəksiniz.

"Nazik artıqlıq" nədir?
Bu, mövcud olandan daha çox tələb olunan resurs ayırmağa imkan verən aparat və ya proqram təminatı texnologiyasıdır (digər adı seyrək həcmlərdir). Bu halda, ayrılmış həcm kifayət qədər (lazım olduğu qədər) və tam vaxtında (lazım olan vaxt üçün) meyarlarına cavab verməlidir. Əsasən, nazik rezervasiya müxtəlif saxlama sistemlərində, həqiqətən mövcud olanları üstələyən tələb olunan həcmlərdə disk sahəsini təmin etmək üçün istifadə olunur. Texnologiya müxtəlif fayl sistemləri tərəfindən dəstəklənir, məsələn, LVM2, ZFS, BTRFS. Virtualizasiya hipervizorlarında geniş istifadə olunur. İncə ehtiyat nüsxə bizə əsas bölmənin anlıq görüntülərindən lazım olan qədər bu bölmənin nüsxələrini (MySQL DBMS-nin məlumat kataloqu) məlumatları ilə tez yaratmağa imkan verdi.

Birinci stend, Thin LVM texnologiyası

Bu fəsil həmçinin “Böyük həcmli məlumatların ən sürətli şəklini necə etmək olar” adlandırıla bilər. İncə LVM, fayl sisteminin və MySQL DBMS-nin sabitliyini nalayiq səviyyələrə endirmək.

Əsas OS arakəsmələrini qurmaq üçün artıq LVM-dən istifadə etdiyimiz üçün ondan başlamağa qərar verdik. Başlamaq üçün bizə ayrıca fiziki maşın lazım idi - əsas MySQL verilənlər bazamızın nüsxəsi, onun üzərində sorğu əsasında replikanın snapshotunu yarada və onu ayrıca MySQL instansiyasının yanında qaldıra bilərik. Sınaq zamanı biz bu instansiyada dəyişdirmə əməliyyatlarının istifadəsinə icazə verdik və sınaqlar başa çatdıqdan sonra onu təhlükəsiz şəkildə sildik. Server konfiqurasiyası belə idi:

2 x Intel Silver 4114 (10x2,2 GHz HT)
8 x 32 GB DDR4
RAID-8-da Adaptec RAID nəzarətçisində 1920 x 10 GB Intel SSD

RAID nəzarətçisi və RAID MD proqramı arasında seçim etmək mövzusunda ayrıca məqalə yaza bilərsiniz. Sadəcə onu deyim ki, seçimimizə iki amil təsir etdi:

Problem formalaşan zaman biz bütün DBMS-ləri RAID kontrollerlərində quraşdırdıq, buna görə də bunun tarixən baş verdiyini deyə bilərik.
Sintetik fayl sistemi testləri və müxtəlif MySQL əməliyyatları ilə testlər arasında performans fərqi minimal idi.

Yaranan RAID-10-u böldük: bütün həcm üçün (təxminən 6,7 GB yüklə) vahid Həcm Qrupu (VG) yaratdıq və 50 GB sistem üçün məntiqi bölmə (Məntiqi Həcm, LV) yaratdıq. Normal bir vəziyyətdə, biz yerin qalan hissəsini MySQL bölməsi kimi təyin edirik. Lakin bizə nazik ehtiyat nüsxəsinə ehtiyacımız var idi, ona görə də əvvəlcə sözdə hovuz yaratdıq, onun daxilində 3,5 TB-lik /var/lib/mysql bölməsi yaratdıq (təxmini verilənlər bazası həcmlərinə əsasən):

lvcreate -l 100%FREE -T vga/thin
lvcreate -V 3.5T -T vga/thin -n mysql

Biz bölməni ext4-də formatladıq, quraşdırdıq, replikasını yazdıq və orijinal stendi əldə etdik. Sonra API şəklində bağlama etdik, o, anlıq görüntülər yaratmalı, verilmiş portda MySQL verilənlər bazası nümunəsini qaldırmalı və yaradılmış nümunəni silməlidir. Bu, yalnız sistem zənglərindən istifadə etdiyi üçün biz skript dili kimi adi bash-i seçdik və HTTP → bash API-ni birləşdirmək üçün açıq mənbə həllini tətbiq etdik. ifşa etmək, Go ilə yazılmışdır.

Nə vaxtsa biz bash skriptlərimizi açıq mənbəyə buraxacağıq, lakin hələlik mən sadəcə əsas alqoritmi təsvir edəcəyəm:

Əsas snapshot snapmain yaradılması:

Əsas replikanın dayandırılması.
Snapmain snapshot ilə əməliyyatlara blok qoyuruq.
Yeni snapshot snapmain yaradın.
MySQL-i işə salın və kilidi çıxarın.

Snapmain-dən ixtiyari portda verilənlər bazası yaratmaq:

Müəyyən bir verilənlər bazası nümunəsinə (port) kilid qoyuruq.
Əsas görüntünün yaradılmasının bloklandığını yoxlayırıq. Əgər oradadırsa, hər 5 saniyədən bir gözləyirik və yenidən yoxlayırıq.
Nümunənin köhnə LV bölməsinin olub olmadığını yoxlayırıq.
3.1 Əgər varsa, MySQL instansiyasını dayandırmaq və LV bölməsini silmək üçün kill -9 istifadə edin.
Snapmain-dən yeni bir nümunə yaradırıq.
Biz bu nümunə üçün qovluqlar hazırlayır və quraşdırırıq.
Biz qulun (faylların) atributlarını çıxarırıq və MySQL instansiyasını işə salırıq.
Gəlin onu ustad edək.
Bloklamanı aradan qaldırırıq.

Təsadüfi portda verilənlər bazasını silmək:

Müəyyən bir verilənlər bazası nümunəsinə (port) kilid qoyuruq.
kill -9 istifadə edərək MySQL nümunəsini öldürün.
Gəlin qovluqları ayıraq.
LV bölməsini silirik və kilidi çıxarırıq.

Yeni verilənlər bazası nümunəsinin bölmələrinin klonlanması üçün nümunə əmrlər:

lvcreate -n stage_3307 -s vga/snapmain
lvchange -ay -K vga/stage_3307
mount -o noatime,nodiratime,data=writeback /dev/mapper/vga-stage_3307 /mnt/stage_3307

İndi sizə nazik ehtiyatdan istifadə edərkən qarşılaşdığımız əsas problem haqqında danışacağam. Biz SSD sürücülərinin performansında ilişib qalmışıq. Bu, Thin LVM-in xüsusiyyətləri ilə əlaqədar baş verdi: o, əsasən 4 MB standart ölçüsü olan aşağı səviyyəli parçalarla cihaz səviyyəsində işləyir. Nə kimi görünürdü:

Əsas bölmədən snapshot yaradın /var/lib/mysql.
Ustadı tutmaq üçün replikasiyaya başlayırıq.
Replika cədvəllərindəki hər hansı dəyişiklik köhnə, dəyişməmiş məlumat hissələrini snapshot bölməsində saxlamağa məcbur edir.
Yüksəltilmiş test nümunəsinə edilən hər hansı dəyişiklik köhnə, dəyişdirilməmiş məlumat hissələrinin həmin nümunə üçün klonlanmış snapshot bölməsində saxlanmasına səbəb olur.
Biz cihazda 100% I/O əməliyyatlarının yüklənməsini, istənilən əməliyyatların yavaşlamasını və replikanın tədricən ləngiməsini alırıq.
İş gününün sonunda bir neçə saat geridə qalan stend alırıq.

Daha sağlam nəticə əldə etmək üçün bununla necə məşğul olduq (əsas məqamlar):

RAID nəzarətçi:

Bütün keşləmə növləri standart olaraq qeyri-aktivdir.
Geri yazmağı təyin edin (məlumatlar buferə daxil olduqda, diskə faktiki saxlama yerinə yetirilməzdən əvvəl yazı tamamlanır).

Fayl sistemi:

/var/lib/mysql bağlama nöqtəsində yazdıq noatime,nodiratime,data=writeback
tune4fs istifadə edərək ext2 girişi deaktiv edildi.

MySQL:

Müəyyən edilmişdir innodb_flush_method = O_DSYNC (qeydiyyat sürətinin artması, bununla da etibarlılığı azaldır).
Qeydiyyat deaktiv edilib, bizə jurnal lazım deyil.
Müəyyən edilmişdir innodb_buffer_pool_size = 4G (InnoDB hovuz ölçüsü nə qədər kiçik olsa, MySQL dayandırıldıqda bir o qədər tez bağlanacaq və bir o qədər sürətli şəkil yaradacağıq).

Bu, xüsusilə MySQL üçün tam siyahı deyil. Bununla belə, qalan dəyişikliklər kiçikdir və çox vaxt həmişə və ya dəqiq şəkildə tətbiq olunmur. Məsələn, diskləri boşaltmaq cəhdində hətta götürdük innodb_parallel_doublewrite_path /dev/shm-də, bəzi hallarda səhv dayandırılmış nümunəni işə saldıqda bizi 5 saniyəyə qədər saxladı.

Niyə bir şəkil çəkməzdən əvvəl MySQL-i dayandırırıq? Axı biz onu işləyən replikadan silə bilərik. Düzdür, lakin bu snapshotdakı yeni verilənlər bazası nümunəsi defolt olaraq zədələnmiş hesab ediləcək və başlanğıcda tam skan tələb olunacaq. Replikanın dayandırılması mütləq daha sürətlidir, baxmayaraq ki, bu, bütün prosesdə ən uzun əməliyyatdır.

Nəticədə daha məqbul vaxtlar və istifadəyə hazır stend əldə etdik. Baxmayaraq ki, əsas replikanın replikasiya gecikməsinin ən parlaq qrafikindən göründüyü kimi, vəziyyət hələ də idealdan uzaqdır:

Digər çatışmazlıqlar arasında Thin LVM hovuzunun monitorinqinin praktiki mümkünsüzlüyünü qeyd etmək lazımdır: sistemin standart iostat funksiyalarına əlavə olaraq, məsələn, hazırda hansı hovuz elementinin fayl sisteminə ən çox yük yaratdığını başa düşmək mümkün deyil.

Ayrı-ayrılıqda, yuxarıda təsvir edilən optimallaşdırma ilə əlaqəli bir böyük çatışmazlığı qeyd etmək lazımdır: biz YOLO stendi aldıq. Təxminən bir və ya iki ayda bir dəfə ext4 bu cür sui-istifadəyə tab gətirə bilmədi və düzəlməz şəkildə sıradan çıxdı, bu da replikanın yenidən formatlaşdırılmasını və yenidən yüklənməsini tələb etdi. Sürətdə qalib gələrək, ümidsizcə sabitliyi pozduq.

Thin LVM istifadə edərkən hansı ölçülərə nəzarət etməlisiniz:

İncə hovuz datası %
İncə hovuz metadatası %

Əgər stendimiz məlumat üçün yer çatışmazlığından sağ çıxsa (diskləri təmizləmək kifayətdir), onda metadata üçün yerin tükənməsi hovuzun tam dağılmasına və onu sıfırdan yenidən qurmaq ehtiyacına səbəb olacaq.

Hovuzdakı fayl sistemi zamanla çox parçalanır. Gündə bir dəfə cron əmrini yerinə yetirməyi məsləhət görürəm fstrim -v /var/lib/mysql.

Ara cəmi:

Texnologiyanın tətbiqi LVM-nin özü kimi asandır və xüsusi mühəndis ixtisasları tələb etmir.
Kiçik və çox yüklənməmiş verilənlər bazaları üçün yaxşı uyğun gəlir. Verilənlər bazası nə qədər kiçik olsa, hovuz daxilində fayl sistemi ətrafında bir o qədər az parça hərəkət edər və disklərdəki yük bir o qədər az olar.
Tapşırığımız üçün növbəti hissədə müzakirə ediləcək digər həll yollarını axtarmağa başladıq.

İkinci stend, ZFS texnologiyası

Mən uzun müddət əvvəl ZFS fayl sistemi ilə işləyirdim, amma o vaxtlar ZFS özünün yerli Solaris OS ailəsində etibarlı şəkildə yaxşı işləyirdi. FreeBSD-yə kifayət qədər yaxşı tətbiq səviyyəsinə malik bir port var idi. Həmçinin yarımçıq bir port da var idi. Linux, az adam istifadə edirdi. B-ağaclı məlumat saxlama strukturuna görə (yeri gəlmişkən, MySQL-in InnoDB-si də eyni saxlama strukturuna malikdir), ZFS çox sayda faylı olan quraşdırmalarda zəif nəticə göstərdi. Bu, istifadə etməzdən əvvəl ipləri öyrənmək ehtiyacı ilə birlikdə bu fayl sistemindən uzun müddət istifadə etməyimə səbəb oldu. Ext4 və xfs ortaya çıxdı və standart hala gəldi. Lakin ZFS-in ehtiyaclarımız üçün çox uyğun olduğunu nəzərə alsaq və LinuxRəylərə əsasən, -versiya tamamilə ağlabatan bir məhsula çevrilib (tam dəstəklənməsə də, buna görə də ZFS-də sıfırdan bir sistem quraşdırmaq yalnız müxtəlif vudu texnikalarının köməyi ilə mümkündür), biz onu sınamağa qərar verdik.

Aşkar səbəblərə görə stend oxşar konfiqurasiya ilə seçildi (RAID nəzarətçisi istisna olmaqla). Biz səkkiz 1920 GB SSD sürücüsü quraşdırdıq. Serveri çılpaq ZFS-ə yükləmək üçün öz şəbəkə şəklimizi yazmaq istəyi yox idi, ona görə də biz bütün disklərdən 50 GB-ni kəsdik və sistem üçün onlara MD RAID-10 hazırladıq. Hər diskdə qalan 1950 GB RAID-10-un ZFS analoquna birləşdirildi:

zpool create zpool mirror /dev/sda2 /dev/sdb2 mirror /dev/sdc2 /dev/sdd2 mirror /dev/sde2 /dev/sdf2 mirror /dev/sdg2 /dev/sdh2

MySQL üçün bölmələr yaratdıq:

zfs create zpool/mysql
zfs set compression=gzip zpool/mysql
zfs set recordsize=128k zpool/mysql
zfs set atime=off zpool/mysql
zfs create zpool/mysql/data
zfs set recordsize=16k zpool/mysql/data
zfs set primarycache=metadata zpool/mysql/data
zfs set mountpoint=/var/lib/mysql zpool/mysql/data

Nəzərə alın ki, biz yerli gzip məlumat sıxılmasını aktiv etdik. Serverdə çoxlu prosessor resurslarımız var və onlar tam istifadə olunmur.Nəticədə verilənlər bazamızın 3 TB-i 1,6 TB-a çevrildi və zəif keçid əvvəlki vəziyyətdə olduğu kimi, maksimum disk performansı olduğundan, az məlumat bir o qədər yaxşıdır, biz əvvəldən ZFS-dən böyük bonus alırıq! Tam yükdə pik saatda gzip-in işləməsini davam etdirmək üçün 4 nüvəyə qədər vaxt tələb olunur, lakin buna etiraz etmirik.

Sonra tətbiq daha sürətli getdi. MySQL replika parametrləri LVM stendindən karbon surəti kimi köçürüldü. ZFS əmrlərindən istifadə edərək skriptləri yenidən yazmağa bir müddət vaxt sərf etməli oldum, lakin ümumilikdə alqoritmlər eyni qaldı. Snapshot yaratmaq nümunəsi:

zfs set snapdir=visible zpool/mysql/data
zfs create zpool/stage_3307
zfs clone zpool/mysql/data@snapmain zpool/stage_3307/data
zfs set mountpoint=/mnt/stage_3307 zpool/stage_3307/data

Əlavə tənzimləmədən: biz metadata və l2arc və zil logları olan ZFS bölmələrini yaddaşa köçürdük. Tapşırığımız üçün, sonradan məlum oldu ki, bu, lazımsız idi, lakin hələlik bu optimallaşdırmanı tərk etdik, lazım olduqda dəyişdirmək asandır. Mənfi təsirlərdən biri odur ki, serveri yenidən işə saldıqdan sonra müvafiq yaddaş sahələrini yenidən yaratmalısınız. Heç bir məlumat itmir. Zpool status kəsimi:

logs
      /dev/shm/zil_slog.img  ONLINE       0     0     0
cache
      /dev/shm/l2arc.img     ONLINE       0     0     0

Bu konfiqurasiyada biz stendi sınaqdan keçirməyə başladıq və əla nəticələr əldə etdik: anlıq görüntülərdə eyni vaxtda işləyən iki verilənlər bazası nümunəsi (və aktiv əsas replika) ilə diskdən 50-60% istifadə etdik.

Replikasiya lag qrafikində göründüyü kimi əsas problemimizdən xilas olduq (Tin LVM bölməsindəki əvvəlki qrafiklə müqayisə edin):

Bundan əlavə və bunun sayəsində biz bütün əməliyyatları xeyli sürətləndirmişik: replikanın dayandırılması və işə salınması ilə snapşotun tamamilə yaradılması 40 saniyəyə qədər vaxt aparır, yeni MySQL nümunəsinin snapshotdan yerləşdirilməsi 20 saniyəyə qədər vaxt aparır. Bu həm bizim, həm də proqram kodu testlərimiz üçün qənaətbəxşdir.

Ara cəmi:

Nəticələr kodu sınamaq üçün istehsal məlumat bazasının surətini əldə etmək ehtiyacımızı tam təmin etdi.
Texnologiya giriş tələb edir: ZFS-nin nə olduğunu və onunla necə işləməyi başa düşməlisiniz.
Biz çoxlu sayda (1 milyondan çox) kiçik fayllarla ZFS-nin cari vəziyyətini yoxlamamışıq. Ancaq problemin davam etdiyini güman edirik, ona görə də bu fayl sistemini heç bir fayl saxlama üçün tövsiyə etməzdim.

Növbəti nədir?

Stend çərçivəsində görüləsi başqa bir iş yoxdur, nəticədən razıyıq. Ola bilsin ki, gələcəkdə test üçün lazım olmayan cədvəllərin istisnalarını stend replikasiya quraşdırmasına əlavə edəcəyik; bu, verilənlər bazasının ölçüsünü daha da azaldacaq. Biz BTRFS sistemini və onun nazik ehtiyat texnologiyasının tətbiqini sınaqdan keçirməmişik. Ancaq əsas məqsədə nail olunduğu üçün belə bir vəzifə artıq buna dəyməz. Ümumiyyətlə, əlbəttə ki, yuxarıda təsvir edilən yanaşmadan uzaqlaşmaq istərdim - test mühitinə işləyən verilənlər bazası miqrasiyalarını həyata keçirin, ayrıca test verilənlər bazası sxemi yaradın və əsas verilənlər bazasını parçalamağa başlayın. Biz artıq bunun çox hissəsini praktikada tətbiq edirik, bundan sonrakı məqalələrdə mütləq danışacağıq.

Nəticələri

Orijinal problem qeyri-adi şəkildə də olsa həll olundu. Aralıq nəticələr istifadə olunan texnologiyaların hər birinin üstünlüklərini və mənfi cəhətlərini təsvir etdi, buna görə də hansı texnologiyanın nə vaxt istifadə oluna biləcəyinə qərar verək:

İncə LVM - kiçik verilənlər bazaları üçün və ZFS öyrənmək istəmədiyiniz və ya vaxtınız olmadığı zaman.
ZFS - onunla işləmək təcrübəniz varsa və ya istənilən vəziyyətdə onu öyrənməyə vaxt sərf etmək imkanınız varsa.

Daha yüksək səviyyədə təqdimatda bu məqalə yalnız iki fayl sisteminin texnologiyasının müqayisəsi deyil. Çatdırmaq və gücləndirmək istədiyim əsas fikir ondan ibarətdir ki, işgüzar kritik vəziyyətlərdə qutudan kənarda düşünməkdən qorxmamalı və yalnız hazır reseptlər götürməlisiniz. Bir vaxtlar texniki şöbədə bütövlükdə başımızı yelləyib deyə bilərdik ki, bir dəqiqədən az müddətdə məlumat bazasının üç terabaytlıq nüsxəsini yaratmaq işi mümkün deyil və bizə riskli texnologiyalar lazım deyil, gəlin edək. düzdür. Bu, mümkün idi, lakin sınaqdan keçirmədən və həyata keçirmə zamanı biz təxminən altı aydan bir ilə qədər və çoxlu müştəri səfərlərini (səyahət bizim əsas biznes göstəricimizdir) itirərdik. Qutudan kənarda hərəkət etməklə, biz tətbiqetmədə çox vaxt itirmədik, yeni və unudulmuş köhnə texnologiyalarda təcrübə qazandıq və həqiqətən ehtiyac duyduğumuz bir zamanda sınaqdan keçirdik. Şübhəsiz ki, bu, bütün göstəricilərimizə öz müsbət təsirini göstərdi. Seçim həmişə sizin ixtiyarınızdadır və biz də öz tərəfimizdən bloqumuzda maraqlı cari və gələcək nailiyyətlər haqqında danışmağa davam edəcəyik.

Mənbə: www.habr.com