DevOps mühəndisləri və sistem administratorları üçün virtual maşın (VM) snapshotları təməl bir vasitədir. Onlar riskli bir yamaq (patch), əsas konfiqurasiya dəyişikliyi və ya tətbiq yerləşdirilməsindən əvvəl serverin vəziyyətini ələ keçirmək üçün sürətli və rahat bir yol təqdim edir. Əgər nəsə səhv gedərsə, geri qayıtmaq (roll back) saniyələr çəkir.
Lakin, eyni metodologiya PostgreSQL, MySQL, Oracle və ya Microsoft SQL Server kimi tranzaksiya bazalarına tətbiq edildikdə, VM snapshotları təhlükəsizlik torundan çıxıb işləyən bir saatlı bombaya çevrilir.
Məlumat bazası ehtiyat nüsxələri üçün standart hipervizor snapshotlarına güvənmək məlumatların korlanması, “cırılmış səhifələr” (torn pages) və bərpa olunmayan istehsal dayanmalarının ən çox yayılmış səbəblərindən biridir. Bu məqalədə biz hipervizorlar və məlumat bazası mühərrikləri arasındakı memarlıq toqquşmasını, snapshotlar zamanı məlumatların korlanması mexanizmlərini və virtualizasiya edilmiş məlumat bazalarını təhlükəsiz şəkildə ehtiyat nüsxələmək üçün tələb olunan mühəndislik ən yaxşı təcrübələrini araşdıracağıq.
Memarlıq Toqquşması: Hipervizorlar vs. Məlumat Bazası Mühərrikləri
VM snapshotlarının məlumat bazalarını niyə təhlükəyə atdığını başa düşmək üçün əvvəlcə hər iki sistemin vəziyyəti və I/O əməliyyatlarını necə idarə etdiyini araşdırmalıyıq.
Hipervizorlar Snapshotları Necə İcra Edir
Hipervizor (məsələn, VMware ESXi, Microsoft Hyper-V və ya KVM) snapshot götürdükdə, diski kopyalamır. Bunun əvəzinə, cari virtual disk faylını (məsələn, .vmdk və ya .vhdx) yalnız oxuna bilən vəziyyətə dondurur və yeni bir delta disk (fərqləndirici disk) yaradır. Sonrakı bütün yazmalar bu delta diskə yönəldilir.
Snapshot silindikdə, hipervizor delta diskdəki məlumatları əsas diskə köçürməli (birləşdirməli) olur. Standart snapshotlar qonaq əməliyyat sistemində işləyən tətbiqlərdən tamamilə xəbərsizdir. Onlar disk vəziyyətini tam olaraq o mikrosaniyədə mövcud olduğu kimi ələ keçirirlər.
Tranzaksiya Məlumat Bazaları Vəziyyəti Necə İdarə Edir
Tranzaksiya məlumat bazaları ACID xüsusiyyətləri (Atomiklik, Ardıcıllıq, İzolyasiya, Davamlılıq) ətrafında dizayn edilmişdir. ACID uyğunluğunu qoruyarkən yüksək performansa nail olmaq üçün məlumat bazaları hər tranzaksiyanı dərhal diskdəki əsas məlumat fayllarına yazmır. Bunun əvəzinə, onlar mürəkkəb, çox səviyyəli bir memarlıqdan istifadə edirlər:
- Buffer Pool / Shared Buffers: Məlumatlar oxunur və sistem yaddaşında dəyişdirilir.
- Write-Ahead Log (WAL) / Redo Logs: Dəyişikliklər davamlılığı təmin etmək üçün diskdəki yüksək optimallaşdırılmış loq faylına ardıcıl olaraq yazılır.
- Checkpoints / Lazy Writers: Məlumat bazası vaxtaşırı olaraq dəyişdirilmiş (çirkli) səhifələri yaddaşdan diskdəki faktiki məlumat fayllarına köçürür.
Bu memarlığa görə, diskdəki fiziki məlumat faylları demək olar ki, həmişə məlumat bazasının faktiki vəziyyəti ilə sinxronizasiyadan kənarda olur. Məlumat bazasının əsl vəziyyəti yalnız diskdəki məlumat faylları, WAL/Redo loqları və hazırda yaddaşda olan məlumatların birləşməsi kimi mövcuddur.
Təhlükə Zonası: VM Snapshotu Zamanı Nə Baş Verir
Məlumat bazası serverinin standart VM snapshotunu götürdükdə, siz qəza-ardıcıl (crash-consistent) bir vəziyyəti ələ keçirirsiniz.
Qəza Ardıcıllığı vs. Tətbiq Ardıcıllığı
Qəza-ardıcıl snapshot, fiziki serverin elektrik kabelini çıxarmağa bərabərdir. Disk vəziyyəti ələ keçirilir, lakin yaddaşda olan hər şey itirilir və saxlama nəzarətçisinə (storage controller) gedən hər şey qəfil kəsilir.
Müasir məlumat bazaları gözlənilməz elektrik kəsilməsindən sonra Write-Ahead Log-u yenidən oynadaraq bərpa olunmaq üçün dizayn edilsə də, qəza bərpasına əsas ehtiyat nüsxə strategiyanız kimi güvənmək çox təhlükəlidir. Əgər məlumat bazanız bir neçə virtual diskə yayılıbsa (məsələn, məlumat faylları Drive D:-də və WAL Drive E:-də), hipervizor hər iki diski eyni mikrosaniyədə snapshot etməyə bilər. Əgər WAL diski snapshotu məlumat diski snapshotundan bir saniyənin fraksiyası qədər gec çəkilərsə, məlumat bazası bərpa zamanı ardıcıllıq nömrələrini uzlaşdıra bilməz və bu, ölümcül korlanmaya səbəb olur.
Yüksək Tranzaksiyalı Sistemlərdə “VM Stun” Effekti
Snapshot yaratma prosesi və daha da əhəmiyyətlisi, snapshotun birləşdirilməsi prosesi “VM Stun” kimi tanınan bir fenomene səbəb olur.
I/O-nu əsas diskdən delta diskə təhlükəsiz şəkildə keçirmək üçün hipervizor virtual maşını qısa müddətə dayandırmalıdır (stun). Yüngül yüklənmiş veb server üçün bu dayanma 10-50 millisaniyə çəkə bilər və nəzərə çarpmaya bilər. Lakin, kütləvi I/O-ya malik yüksək ötürücülü məlumat bazası üçün böyük bir delta diski birləşdirmək VM-i bir neçə saniyə ərzində dondura bilər.
VM dayanması zamanı:
* Şəbəkə bağlantıları kəsilir, bu da tətbiq vaxt aşımına (timeout) səbəb olur.
* Yüksək əlçatanlıq klasterləri (SQL Server Always On, PostgreSQL Patroni və ya MySQL Galera kimi) ürək döyüntüsü (heartbeat) yoxlamalarını qaçırır.
* Klaster dondurulmuş qovşağın öldüyünü güman edərək lazımsız və dağıdıcı bir failover (split-brain ssenarisi) başladır.
Cırılmış Səhifələr (Torn Pages) və I/O Uyğunsuzluğu
Məlumat bazası mühərrikləri adətən məlumatları xüsusi səhifə ölçülərində (məsələn, PostgreSQL və SQL Server üçün 8KB, InnoDB üçün 16KB) yazır. Lakin, əsas əməliyyat sistemi və saxlama massivləri I/O-nu daha kiçik bloklarla (məsələn, 4KB və ya 512 bayt) emal edir.
Əgər hipervizor məlumat bazası 8KB-lıq bir səhifəni yazarkən snapshot götürərsə, snapshot yeni məlumatın ilk 4KB-nı və köhnə məlumatın son 4KB-nı ələ keçirə bilər. Bu, cırılmış səhifə yaradır. Snapshotu bərpa etməyə çalışdıqda, məlumat bazası səhifəni oxuyacaq, checksum yoxlamasından keçə bilməyəcək və məlumat bazasını korlanmış kimi işarələyəcək.
Xüsusi Məlumat Bazası Mühərrikləri üçün Real Dünya Nəticələri
Müxtəlif məlumat bazası mühərrikləri qəza-ardıcıl snapshotlara müxtəlif yollarla reaksiya verir, lakin heç biri istehsal mühitində bunu düzgün idarə etmir.
- PostgreSQL: PostgreSQL
pg_walkataloquna çox güvənir. Əgər snapshot məlumat kataloqunu ($PGDATA) və WAL-ı sinxronizasiyadan kənar ələ keçirərsə, PostgreSQL işə düşməyəcək vəPANIC: could not locate a valid checkpoint recordxətası verəcək. - MySQL/InnoDB: InnoDB cırılmış səhifələrin qarşısını almaq üçün doublewrite buffer-dən istifadə edir ki, bu da qəza-ardıcıl vəziyyətlərə qarşı müəyyən qoruma təmin edir. Lakin,
ibdata1faylı vəib_logfilesinxronizasiyadan kənar ələ keçirilərsə, InnoDB mühərriki bərpa zamanı çökəcək. - Microsoft SQL Server: SQL Server I/O dondurulmasına qarşı çox həssasdır. Düzgün VSS (Volume Shadow Copy Service) inteqrasiyası olmadan, SQL Server-i standart VM snapshotundan bərpa etmək çox vaxt şübhəli məlumat bazalarına və qırılmış loq zəncirlərinə səbəb olacaq, bu da Point-in-Time Recovery (PITR) imkanlarınızı məhv edəcək.
Virtualizasiya edilmiş Məlumat Bazalarını Təhlükəsiz Ehtiyat Nüsxələmək üçün Ən Yaxşı Təcrübələr
Tranzaksiya məlumat bazalarını qorumaq üçün qəza-ardıcıl ehtiyat nüsxələrdən tətbiq-ardıcıl (application-consistent) ehtiyat nüsxələrə keçməlisiniz. Bu, ehtiyat nüsxə mexanizminin məlumat bazası mühərriki ilə əlaqə qurmasını, yaddaşı diskə boşaltmağa məcbur etməsini və snapshot götürülərkən I/O əməliyyatlarını müvəqqəti dayandırmasını tələb edir.
1. Tətbiq-Məlumatlı Quiescing (VSS və fsfreeze) istifadə edin
Windows üçün (SQL Server):
Ehtiyat nüsxə həllinizin Microsoft Volume Shadow Copy Service (VSS) istifadə etdiyinə həmişə əmin olun. VSS-məlumatlı ehtiyat nüsxə başladıldıqda, SQL Server VSS Writer məlumat bazası I/O-nu dondurur, gözləyən tranzaksiyaları diskə boşaldır və snapshotun mükəmməl tətbiq-ardıcıl olmasını təmin edir.
Linux üçün (PostgreSQL / MySQL):
Linux-un VSS-ə yerli ekvivalenti yoxdur. Tətbiq ardıcıllığına nail olmaq üçün hipervizorun qonaq alətləri (məsələn, VMware Tools) ilə birlikdə pre-freeze və post-thaw skriptlərindən istifadə etməlisiniz.
Budur PostgreSQL 15+ üçün məlumat bazasını snapshot üçün təhlükəsiz şəkildə hazırlayan VMware pre-freeze-script nümunəsi:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Bu skriptin icra edilə bilən (chmod +x) olduğundan əmin olun
# 1. PostgreSQL-ə ehtiyat nüsxə üçün hazırlaşmağı tapşırın
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Fayl sistemi buferlərini diskə boşaldın
sync
# 3. Fayl sistemini dondurun (məlumatların /var/lib/pgsql-də olduğunu fərz edərək)
fsfreeze -f /var/lib/pgsql
Və əməliyyatları bərpa etmək üçün müvafiq post-thaw-script:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Fayl sisteminin dondurulmasını dayandırın
fsfreeze -u /var/lib/pgsql
# 2. PostgreSQL-ə ehtiyat nüsxənin tamamlandığını bildirin
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Yerli Məlumat Bazası Ehtiyat Nüsxə Vasitələrindən istifadə edin
Tətbiq-ardıcıl snapshotlar standart snapshotlardan daha yaxşı olsa da, onlar hələ də VM stun riski daşıyır. Məlumat bazası ehtiyat nüsxələri üçün ən təhlükəsiz yanaşma, hipervizordan müstəqil işləyən yerli, axınlı (streaming) ehtiyat nüsxə vasitələrindən istifadə etməkdir.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Bu vasitələr məlumat fayllarını kopyalayaraq və eyni zamanda redo loqundakı dəyişiklikləri izləyərək isti, bloklamayan ehtiyat nüsxələr götürür.
mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass
SQL Server (T-SQL):
BACKUP DATABASE [ProductionDB]
TO DISK = N'Z:BackupsProductionDB.bak'
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO
3. Loq Arxivləmə vasitəsilə Point-in-Time Recovery (PITR) tətbiq edin
Gündəlik snapshot və ya tam ehtiyat nüsxə sizi yalnız çəkildiyi ana qədər qoruyur. Əgər məlumat bazanız saat 16:00-da çökərsə və son snapshotunuz saat 02:00-da olubsa, siz 14 saatlıq tranzaksiya məlumatını itirirsiniz.
Əsl müəssisə dayanıqlılığına nail olmaq üçün tam tətbiq-ardıcıl ehtiyat nüsxələri davamlı loq arxivləmə (WAL, Redo Logs və ya Tranzaksiya Loqlarını hər bir neçə dəqiqədən bir ehtiyat nüsxələmək) ilə birləşdirməlisiniz. Bu, DBA-lara məlumat bazasını fəlakətdən əvvəl müəyyən bir dəqiqəyə və ya hətta xüsusi bir tranzaksiya ID-sinə bərpa etməyə imkan verir.
CloudSave ilə Müəssisə Ehtiyat Nüsxə Strategiyaları
Xüsusi pre-freeze skriptlərini, yerli dump-lar üçün cron işlərini və onlarla məlumat bazası serverində loq göndərilməsini idarə etmək DevOps komandaları üçün əməliyyat kabusudur. Məhz burada CloudSave kimi müəssisə səviyyəli platforma kritik əhəmiyyət kəsb edir.
CloudSave virtualizasiya və məlumat bazası memarlığı arasındakı boşluğu doldurur. Kor-koranə hipervizor snapshotlarına güvənmək əvəzinə, CloudSave SQL Server, PostgreSQL, MySQL və Oracle ilə yerli şəkildə inteqrasiya olunan tətbiq-məlumatlı agentlərdən istifadə edir.
CloudSave ehtiyat nüsxəni başlatdıqda:
1. Yerli API-lər vasitəsilə (Windows üçün VSS və ya Linux üçün yerli WAL axını kimi) birbaşa məlumat bazası mühərriki ilə əlaqə qurur.
2. Dağıdıcı VM stun-larına səbəb olmadan yaddaş buferlərinin diskə boşaldılmasını orkestr edir.
3. Məlumat fayllarını təhlükəsiz şəkildə ələ keçirir və tranzaksiya loqunun kəsilməsini avtomatik idarə edir.
4. Tranzaksiya loqlarını davamlı olaraq ehtiyat nüsxələyir, bir neçə kliklə qranulyar Point-in-Time Recovery (PITR) imkanı verir.
Tətbiq ardıcıllığının mürəkkəbliyini CloudSave-ə yükləməklə, DBA-lar və sistem administratorları istehsal klasterlərinin performansını və ya əlçatanlığını qurban vermədən məlumat bütövlüyünə zəmanət verə bilərlər.
Nəticə
Virtual maşın snapshotları infrastruktur idarəetməsi üçün inanılmaz bir vasitədir, lakin onlar tranzaksiya məlumat bazalarının ACID tələbləri ilə fundamental olaraq uyğun deyil. Qəza-ardıcıl hipervizor snapshotlarına güvənmək təşkilatınızı cırılmış səhifələr, qırılmış replikasiya zəncirləri və fəlakətli məlumat itkisi ilə üz-üzə qoyur.
Missiya üçün kritik məlumatlarınızı qorumaq üçün tətbiq-məlumatlı quiescing tətbiq etməli, yerli məlumat bazası ehtiyat nüsxə metodologiyalarından istifadə etməli və davamlı tranzaksiya loqu arxivlərini saxlamalısınız. Məqsədli müəssisə ehtiyat nüsxə həllərini qəbul etməklə, məlumat bazalarınızın yüksək əlçatan, tam bərpa oluna bilən və tamamilə təhlükəsiz qalmasını təmin edə bilərsiniz.
