Onilliklər ərzində mysqldump MySQL verilənlər bazasının ehtiyat nüsxələrinin çıxarılması üçün mübahisəsiz “İsveç bıçağı” olmuşdur. O, hər yerdə mövcuddur, sadədir və hər bir MySQL və MariaDB paylaması ilə əvvəlcədən quraşdırılmış şəkildə gəlir. Kiçik və orta ölçülü verilənlər bazaları üçün o, mükəmməl işləyir.
Bununla belə, təşkilatlar böyüdükcə və verilənlər dəstləri 100GB, 500GB və ya bir neçə terabayt həddini keçdikcə, mysqldump-a güvənmək ən yaxşı təcrübədən kritik bir memarlıq zəifliyinə çevrilir. Əgər siz genişmiqyaslı istehsal verilənlər bazalarını idarə edən DBA və ya DevOps mühəndisisinizsə, yəqin ki, məntiqi dump-larla bağlı səssiz uğursuzluqlar, istehsalın pisləşməsi və qəbuledilməz Bərpa Zamanı Hədəfləri (RTO) ilə qarşılaşmısınız.
Bu məqalədə biz mysqldump-ın memarlıq məhdudiyyətlərini təhlil edəcək, onun niyə miqyasda uğursuz olduğunu araşdıracaq və missiya üçün kritik məlumatlarınızı qorumaq üçün müəssisə səviyyəli fiziki ehtiyat nüsxə strategiyalarını necə tətbiq edəcəyinizi ətraflı izah edəcəyik.
mysqldump-ın Memarlıq Məhdudiyyətləri
mysqldump-ın niyə miqyasda uğursuz olduğunu başa düşmək üçün onun necə işlədiyini araşdırmalıyıq. mysqldump məntiqi ehtiyat nüsxələr yaradır. O, verilənlər bazası mühərrikinə sorğu göndərir, məlumatları oxuyur və onları bir sıra SQL ifadələrinə (əsasən CREATE TABLE və INSERT INTO) çevirir.
Bu, yüksək dərəcədə portativ, insan tərəfindən oxuna bilən bir fayl yaratsa da, yüksək ötürmə qabiliyyətinə malik mühitlərdə ciddi darboğazlar yaradır.
1. Biraxınlı (Single-Threaded) Darboğaz
Dizaynına görə, mysqldump biraxınlı əməliyyatdır. O, hər dəfə bir cədvəli, sətir-sətir emal edir. Müasir aparat təminatı onlarla CPU nüvəsinə və saniyədə giqabaytlarla ötürmə qabiliyyətinə malik NVMe yaddaşına sahib olsa da, mysqldump bu resursların yalnız bir hissəsindən istifadə edir.
Hətta InnoDB cədvəlləri üçün standart bayraqlardan istifadə edərkən belə:
mysqldump -u root -p --single-transaction --routines --triggers --events --quick production_db > backup.sql
--quick bayrağı mysqldump-ı bütün cədvəli yaddaşda saxlamaq əvəzinə sətirləri bir-bir götürməyə məcbur edir ki, bu da müştəri tərəfində Yaddaşın Bitməsi (OOM) xətalarının qarşısını alır. Bununla belə, biraxınlı təbiəti o deməkdir ki, 500GB-lıq verilənlər bazasının dump edilməsi 10-15 saat çəkə bilər ki, bu da Bərpa Nöqtəsi Hədəfinizə (RPO) ciddi təsir göstərir.
2. InnoDB Buffer Pool Çirklənməsi
mysqldump hər cədvəlin hər bir sətrini oxuduqda, MySQL mühərrikini həmin məlumatları diskdən InnoDB buffer pool-una yükləməyə məcbur edir. İstehsal mühitində buffer pool-unuz “isti” işçi verilənlər dəstinizlə diqqətlə doldurulur.
Nəhəng bir məntiqi dump buffer pool-u təmizləyəcək, ehtiyat nüsxəsi çıxarılan soyuq məlumatlara yer açmaq üçün tez-tez daxil olunan indeksləri və məlumat səhifələrini çıxaracaq. Bu, istehsal sorğularının diskdən oxumağa məcbur olması səbəbindən disk I/O-da qəfil, kütləvi artıma səbəb olur və ciddi tətbiq gecikmələrinə gətirib çıxarır.
3. Metadata Kilidləri və DDL Münaqişələri
Ardıcıllığı qorumaq üçün DBA-lar --single-transaction bayrağına güvənirlər, bu da əməliyyat izolyasiya səviyyəsini REPEATABLE READ olaraq təyin edir və məlumatları dump etməzdən əvvəl bir əməliyyata başlayır.
Bu, cədvəl səviyyəsində oxuma kilidlərindən (FLUSH TABLES WITH READ LOCK) qaçsa da, Məlumat Tərifləmə Dili (DDL) dəyişikliklərindən qorumur. Əgər mysqldump işləyərkən cədvəl üzərində ALTER TABLE, DROP TABLE və ya TRUNCATE TABLE əmri icra edilərsə, ehtiyat nüsxə table definition has changed, please retry transaction xətası ilə dayanacaq. Tez-tez sxem miqrasiyaları olan CI/CD mühitlərində bu, davamlı ehtiyat nüsxə uğursuzluqlarına səbəb olur.
4. RTO Kabusu: Bərpa Zamanları
mysqldump-ın ən fəlakətli uğursuzluğu ehtiyat nüsxə zamanı deyil, bərpa zamanı baş verir.
Məntiqi dump-ın bərpası MySQL mühərrikindən milyonlarla INSERT ifadəsini təhlil etməyi və icra etməyi tələb edir. Daxil edilən hər bir sətir üçün MySQL aşağıdakıları etməlidir:
* Məhdudiyyətləri yoxlamaq (Xarici Açar, Unikal Açar).
* İkinci dərəcəli indeksləri yenidən qurmaq.
* InnoDB redo log-una yazmaq.
* Binlog-a yazmaq (əgər aktivdirsə).
1TB-lıq verilənlər bazasını məntiqi dump-dan bərpa etmək bir neçə gün çəkə bilər. Əgər biznesinizin RTO-su 4 saatdırsa, mysqldump Xidmət Səviyyəsi Sazişinizi (SLA) pozacağınızı təmin edir.
Müəssisə Səviyyəli Alternativlər: Fiziki Ehtiyat Nüsxələrə Keçid
Böyük verilənlər dəstləri üçün sürətli ehtiyat nüsxələr və bərpalar əldə etmək üçün məntiqi ehtiyat nüsxələrdən imtina edib fiziki ehtiyat nüsxələrə keçməlisiniz.
Fiziki ehtiyat nüsxələr MySQL SQL icra mühərrikini tamamilə yan keçir. Bunun əvəzinə, onlar əsas ikili məlumat fayllarını (.ibd faylları, redo log-lar və undo log-lar) birbaşa fayl sistemindən kopyalayırlar. Onlar sadəcə faylları kopyaladıqları üçün aparat təminatınızın maksimum ardıcıl oxuma/yazma sürəti ilə işləyə bilər və yüksək dərəcədə paralelləşdirilə bilərlər.
Percona XtraBackup: Sənaye Standartı
InnoDB və XtraDB mühərrikləri üçün Percona XtraBackup əsas açıq mənbəli fiziki ehtiyat nüsxə alətidir. O, MySQL verilənlər bazalarının “isti”, bloklamayan ehtiyat nüsxələrini çıxarır.
XtraBackup Necə İşləyir
- Məlumatların Kopyalanması: XtraBackup InnoDB məlumat fayllarını (
.ibd) kopyalamağa başlayır. - Log İzləmə: Verilənlər bazası canlı olduğu üçün fayllar kopyalanarkən məlumatlar dəyişəcək. XtraBackup ehtiyat nüsxə pəncərəsi zamanı baş verən hər hansı əməliyyatlar üçün InnoDB redo log-unu (
ib_logfile0və s.) izləyən və kopyalayan bir fon axını yaradır. - Hazırlıq (Qəza Bərpası): Ehtiyat nüsxədən sonra kopyalanmış məlumat faylları uyğunsuz vəziyyətdə olur. XtraBackup kopyalanmış redo log-ları məlumat fayllarına tətbiq edir (MySQL-in işə salınarkən qəza bərpası etməsinə bənzər), nəticədə ehtiyat nüsxə bitdiyi anda verilənlər bazasının mükəmməl uyğun snapshot-u alınır.
Fiziki Ehtiyat Nüsxə Strategiyasının Tətbiqi
Budur Percona XtraBackup istifadə edərək fiziki ehtiyat nüsxə strategiyasının tətbiqi üçün texniki təlimat.
Addım 1: Ehtiyat Nüsxənin Axın Edilməsi (Streaming)
Nəhəng bir ehtiyat nüsxəni yerli diska yazmaq çox vaxt tutum problemlərinə səbəb olur. Ən yaxşı təcrübə ehtiyat nüsxəni birbaşa arxiv formatına axın etmək, sıxmaq və onu hazırlıq sahəsinə və ya birbaşa ehtiyat nüsxə platformasına göndərməkdir.
xbstream istifadə edərək, biz ehtiyat nüsxəni paralelləşdirə və onu dərhal sıxa bilərik:
xtrabackup --backup
--user=backup_user
--password=SecurePassword!
--parallel=4
--stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
--parallel=4: Məlumat fayllarını eyni vaxtda oxumaq üçün 4 axından istifadə edir.--stream=xbstream: Ehtiyat nüsxəni Percona-nın xüsusi axın formatında çıxarır.lz4: Çox sürətli, aşağı CPU tələb edən sıxılma təmin edir.
Addım 2: Bərpa üçün Ehtiyat Nüsxənin Hazırlanması
Fiziki ehtiyat nüsxə bərpa edilməzdən əvvəl o, “hazırlanmalıdır” (redo log-ların tətbiqi). Əvvəlcə axını çıxarın və sıxılmasını açın:
mkdir -p /data/restore
lz4 -d /mnt/backups/mysql_prod_backup.xbstream.lz4 | xbstream -x -C /data/restore
Sonra, hazırlıq mərhələsini işə salın. Bu addım yaddaş tələb edir, ona görə də serverin kifayət qədər RAM-a malik olduğundan əmin olun:
xtrabackup --prepare --use-memory=4G --target-dir=/data/restore
Addım 3: Verilənlər Bazasının Bərpası
Bərpa etmək üçün hədəf MySQL məlumat kataloqu tamamilə boş olmalıdır. MySQL xidmətini dayandırın, kataloqu təmizləyin və faylları geri kopyalayın:
systemctl stop mysql
rm -rf /var/lib/mysql/*
xtrabackup --copy-back --target-dir=/data/restore
Nəhayət, xidməti işə salmazdan əvvəl fayl sistemi icazələrini düzəldin:
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql
Məlumat faylları artıq qurulduğu və indekslər artıq tərtib edildiyi üçün verilənlər bazası dərhal işə düşür. mysqldump ilə 48 saat çəkən bərpa indi yalnız faylların şəbəkəniz və ya diskiniz üzərində kopyalanması qədər vaxt aparır—bu da çox vaxt RTO-nu dəqiqələrə endirir.
Məntiqi Bərpaların Optimallaşdırılması (İstifadə etməli olduğunuz zaman)
Əgər böyük bir məntiqi dump-ı bərpa etməyə məcbur olsanız (məsələn, müxtəlif əsas MySQL versiyaları və ya fiziki faylların uyğun olmadığı müxtəlif CPU memarlıqları arasında miqrasiya edərkən), nəhəng yazma ötürmə qabiliyyəti üçün MySQL konfiqurasiyanızı müvəqqəti olaraq tənzimləməlisiniz.
Məntiqi bərpaya başlamazdan əvvəl bu parametrləri my.cnf faylınıza tətbiq edin:
[mysqld]
# Əgər bu müstəqil bərpadırsa, binlogging-i müvəqqəti olaraq deaktiv edin
disable_log_bin
# Yazma sürətini maksimuma çatdırmaq üçün diskə yazmanı gecikdirin
innodb_flush_log_at_trx_commit = 2
# İşçi dəstin mümkün qədər çox hissəsini yerləşdirmək üçün buffer pool-u artırın
innodb_buffer_pool_size = <Ümumi RAM-ın 70%-i qədər təyin edin>
# Aqressiv yoxlama nöqtələrinin qarşısını almaq üçün log faylının ölçüsünü artırın
innodb_log_file_size = 2G
# Doublewrite buffer-i deaktiv edin (istehsal üçün risklidir, ilkin yükləmə üçün təhlükəsizdir)
innodb_doublewrite = 0
Qeyd: İstehsal trafikinə icazə verməzdən əvvəl bu parametrləri həmişə ACID-uyğun standartlarına (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) qaytarın və MySQL xidmətini yenidən başladın.
CloudSave ilə Ehtiyat Nüsxələrin Avtomatlaşdırılması və Təhlükəsizliyi
Percona XtraBackup kimi alətlər məlumatların səmərəli çıxarılması mexanikasını həll etsə də, əsl müəssisə fəlakət bərpası strategiyası orkestrləmə, təhlükəsiz ofsayt yaddaşı və həyat dövrü idarəetməsini tələb edir. Fiziki ehtiyat nüsxələri idarə etmək üçün xüsusi bash skriptlərinə və cron işlərinə güvənmək səssiz uğursuzluqlar və uyğunluq pozuntuları riski yaradır.
Məhz burada verilənlər bazası qatınızı CloudSave kimi müəssisə platforması ilə inteqrasiya etmək kritik əhəmiyyət kəsb edir.
CloudSave xam verilənlər bazası yardım proqramları ilə müəssisə uyğunluğu arasındakı boşluğu aradan qaldırır. CloudSave-in skriptdən əvvəl və sonrakı imkanlarından istifadə edərək, DevOps komandaları ardıcıl fiziki snapshot yaratmaq üçün XtraBackup-ı işə sala bilərlər. CloudSave daha sonra ehtiyat nüsxə axınını problemsiz şəkildə qəbul edir, AES-256 şifrələməsini tətbiq edir və onu dəyişməz bulud yaddaşına replikasiya etməzdən əvvəl məlumatları dublikatdan təmizləyir.
Bu memarlıq aşağıdakıları təmin edir:
1. İstehsal Performansı Qorunur: Ehtiyat nüsxələr InnoDB buffer pool-unu çirkləndirmədən yaddaş sürəti ilə işləyir.
2. Ransomware Mühafizəsi: CloudSave daxilindəki dəyişməz yaddaş siyasətləri zərərli aktorların verilənlər bazası arxivlərinizi silməsinin və ya şifrələməsinin qarşısını alır.
3. Avtomatlaşdırılmış Saxlama: Grandfather-Father-Son (GFS) saxlama siyasətləri avtomatik olaraq idarə olunur, bu da məlumat suverenliyi və audit tələblərinə uyğunluğu təmin edir.
4. Proqnozlaşdırıla bilən RTO: CloudSave fiziki fayl arxivlərini idarə etdiyi üçün, bir neçə terabaytlıq verilənlər bazasının yeni bir nümunəyə bərpası sürətlə orkestrləşdirilə bilər və ciddi RTO hədəflərinə çatır.
Nəticə
Genişmiqyaslı verilənlər bazaları üçün mysqldump-dan istifadə etməyə davam etmək təşkilatınızın iş vaxtı və məlumat bütövlüyü ilə qumar oynamaqdır. Biraxınlı təbiəti, buffer pool çirklənməsi və fəlakətli bərpa zamanları onu müasir, yüksək ötürmə qabiliyyətinə malik mühitlər üçün fundamental olaraq yararsız edir.
Percona XtraBackup kimi alətlərdən istifadə edərək fiziki ehtiyat nüsxələrə keçməklə və həyat dövrünü, şifrələməni və ofsayt replikasiyasını CloudSave kimi möhkəm platforma vasitəsilə orkestrləşdirməklə, siz verilənlər bazası ehtiyat nüsxə strategiyanızı kövrək bir öhdəlikdən dayanıqlı, müəssisə səviyyəli bir aktivə çevirirsiniz. Cari RTO və RPO göstəricilərinizi bu gün qiymətləndirin—əgər bərpa biznesinizin oflayn qalmağa dözə biləcəyindən daha çox vaxt aparırsa, mysqldump-ı arxada qoymağın vaxtı çatıb.
