Sıfır dayanma ilə verilənlər bazası miqrasiyası istehsal mühitində cədvəl, indeks və ya məlumat modelini dəyişərkən istifadəçilərin işləməsini dayandırmamaq üçün tətbiq edilən mərhələli yanaşmadır. Praktik hədəf “heç nə baş verə bilməz” demək deyil; riskli dəyişiklikləri kiçik, müşahidə olunan və geri dönə bilən addımlara bölməkdir. Ən etibarlı model adətən expand → backfill → validate → contract ardıcıllığıdır.

Bu yanaşma xüsusilə aktiv istifadəçisi olan veb platformalarda, mobil tətbiqlərdə, ödəniş, sifariş, bildiriş və inteqrasiya axınlarında vacibdir. Mobil tətbiqin köhnə versiyası istifadəçilərin cihazlarında günlərlə və ya aylarla qala bilər. Buna görə backend və verilənlər bazası yalnız yeni tətbiq releasini deyil, keçid dövründə köhnə versiyaları da dəstəkləməlidir. POLADO-nun texniki dəstək və konsaltinq xidməti məhz belə istehsal dəyişiklikləri üçün release planı, müşahidəetmə və əməliyyat sahibliyini təşkil etməyə kömək edir.

Niyə birbaşa deploy risklidir?

Birbaşa dəyişiklik, məsələn mövcud sütunun adını dəyişmək, onu silmək, dərhal NOT NULL məhdudiyyəti əlavə etmək və ya böyük cədvəldə indeks yaratmaq, tətbiqin bir hissəsini köhnə sxemlə işləməz vəziyyətə sala bilər. Risk yalnız tətbiq kodunda deyil: background worker-lər, cron işləri, BI sorğuları, webhook istehlakçıları, admin paneli və köhnə mobil klientlər də eyni məlumat modelindən asılı ola bilər.

  • Yeni kod hələ yayımlanmamışkən sxem köhnə kodu pozur.
  • Uzunmüddətli DDL əməliyyatı yazıları bloklayır və sorğuların gecikməsi artır.
  • Bir dəfəlik böyük UPDATE transaction log-u, replikasiya gecikməsini və ya lock gözləməsini artırır.
  • Yeni sahə boş və ya köhnə formatdadır, amma biznes qaydası onu artıq etibarlı sayır.
  • Rollback zamanı köhnə tətbiq yeninin yazdığı məlumatı oxuya və ya düzgün şərh edə bilmir.

PostgreSQL kimi sistemlərdə indeksin adi yaradılması yazıları bloklaya bilər; uyğun hallarda CREATE INDEX CONCURRENTLY yazıları dayandırmadan indeks qurmağa imkan verir, lakin daha uzun çəkir və əməliyyat məhdudiyyətləri var. Bu səbəbdən konkret DB mühərriki, cədvəl həcmi, transaction müddəti və lock davranışı release planının bir hissəsi olmalıdır.

Expand-and-contract database migration strategiyası

1. Expand: əvvəlcə uyğunluğu genişləndirin

Birinci release köhnə davranışı silmir; yeni struktur əlavə edir. Məsələn, orders.customer_name sahəsini normalizasiya olunmuş customer_id ilə əvəz etmək istəyirsinizsə, əvvəl customer_id sahəsini nullable şəkildə əlavə edin. Köhnə sahəni silməyin, API cavabından çıxarmayın və köhnə kodun gözlədiyi kontraktı dəyişməyin.

Bu mərhələdə tətbiq yeni sahəni oxumağa hazır ola bilər, amma köhnə dəyərə fallback etməlidir. Yeni yazılar üçün iki seçim var:

  • Dual-write: tətbiq bir müddət həm köhnə, həm yeni nümayəndəliyi yazır. Keçid qısadırsa və atomik transaction daxilində hər iki yazını idarə etmək mümkündürsə, bu praktik ola bilər.
  • Single writer + törəmə məlumat: yalnız canonical məlumat yazılır, digər sahə worker, trigger və ya idarə olunan proseslə yenilənir. Bu, iki yazı yolunun uyğunsuzluq riskini azalda bilər, lakin gecikmə və bərpa qaydası aydın olmalıdır.

Dual-write həmişə standart seçim deyil. İki ayrı sistemə və ya iki asinxron axına yazmaqda qismən uğursuzluq baş verə bilər. Əgər yeni sahə köhnə məlumatdan deterministik hesablanırsa, çox vaxt köhnə sistem canonical qalır, yeni sahə isə backfill və davamlı sinxronizasiya ilə qurulur.

2. Backfill: məlumatı kiçik və təkrar icra edilə bilən paketlərlə köçürün

Backfill bütün tarixi sətrləri yeni formata gətirir. Bunu deploy zamanı tək SQL əmri kimi işlətmək əvəzinə, ayrıca job kimi planlayın. Job sabit sıralama açarından, məsələn primary key diapazonundan istifadə etməli; batch ölçüsü, sürət limiti və retry siyasəti olmalıdır.

  • Hər batch yalnız hədəf sahəsi hələ doldurulmamış sətrləri yeniləsin.
  • İş idempotent olsun: yarımçıq qaldıqdan sonra eyni batch təhlükəsiz təkrar işləsin.
  • İrəliləyişi checkpoint, emal edilmiş sıra sayı və səhv səbəbləri ilə qeyd edin.
  • Peak saatlarda batch ölçüsünü və parallel worker sayını azaldın.
  • Replica lag, DB CPU, lock wait, deadlock və API latency üçün limitlər təyin edin.

Mobil məhsulda profil sahəsinin formatını dəyişdirmək buna yaxşı nümunədir. Yeni formatı əvvəl əlavə edin, yeni tətbiq versiyasının yazdığı məlumatı hər iki formatda və ya çevirmə qatı ilə qəbul edin, sonra mövcud istifadəçiləri hissə-hissə backfill edin. İstifadəçi köhnə tətbiqdən məlumatı dəyişəndə həmin sətrin yenidən köhnə vəziyyətə qayıtmayacağı da nəzərə alınmalıdır.

3. Validate: “job tamamlandı” ilə kifayətlənməyin

Backfill-in 100% işləməsi məlumatın düzgün olduğunu sübut etmir. Yoxlama həm struktur, həm də biznes səviyyəsində aparılmalıdır. Əvvəlcədən ölçülə bilən qəbul meyarları yazın: neçə sətr köçürülməlidir, hansı sahələr bərabər olmalıdır, hansı istisnalar qanunidir və fərq aşkar ediləndə kim qərar verəcək?

  • Sayım yoxlaması: mənbə və hədəf üzrə gözlənilən sətr saylarını müqayisə edin.
  • Invariant yoxlaması: məsələn, sifariş məbləğlərinin cəmi, status paylanması və foreign key uyğunluğu.
  • Nümunə yoxlaması: riskli kənar hallar, son yazılar və tarixi məlumatdan seçilmiş nümunələri müqayisə edin.
  • Canary oxunuş: məhdud istifadəçi və ya daxili əməliyyat üçün yeni oxu yolunu aktiv edin.
  • Metrik müqayisəsi: yeni və köhnə oxu hesablamalarının fərq sayını, boş dəyər faizini və parsing xətalarını ölçün.

Dual-read istifadə olunursa, tətbiq eyni məntiqi məlumatı köhnə və yeni yoldan oxuyub nəticələri müqayisə edə bilər. Lakin bütün cavabı hər sorğuda iki dəfə hesablamaq baha başa gələ bilər. Daha məqsədəuyğun variant seçilmiş trafikdə müqayisə, fon audit job-u və ya yalnız kritik atributların shadow validation-ıdır.

4. Contract: yalnız keçid dövrü bitəndə köhnəni silin

Yeni yazı və oxu yolu stabil olduqdan, backfill yoxlanıldıqdan, köhnə tətbiq versiyalarının davranışı nəzərə alındıqdan sonra köhnə sütun, indeks, kod və feature flag çıxarıla bilər. Bu addımı ilk release ilə birləşdirməyin. Contract ayrıca, planlı və müşahidə olunan release olmalıdır.

Silinməzdən əvvəl dependency siyahısını yoxlayın: ETL, export, analitika, admin əməliyyatları, SQL reportlar, inteqrasiya müqavilələri və mobil minimum versiya siyasəti. Köhnə sütunun son oxunuşunu ölçmək, “artıq heç kim istifadə etmir” ehtimalından daha etibarlıdır.

Release ardıcıllığı: təhlükəsiz production database release nümunəsi

  1. İnventar yaradın: cədvəllər, API-lər, worker-lər, mobil versiyalar, reportlar və xarici inteqrasiyalar.
  2. Expand migrasiyasını yazın və lock/iş müddətini staging mühitində istehsala yaxın həcmdə sınayın.
  3. Uyğun tətbiq kodunu yayımlayın: fallback oxunuşu, observability və feature flag-lər hazır olsun.
  4. Yeni yazı davranışını məhdud trafikdə aktiv edin.
  5. Throttled, idempotent backfill job-u başladın; sistem sağlamlığı limitlərini izləyin.
  6. Sayım, invariant və business reconciliation yoxlamalarını keçirin.
  7. Yeni oxu yolunu canary-dən tam trafikə keçirin.
  8. Rollback pəncərəsi bağlanandan və köhnə istifadəçilər dəstəklənəndən sonra contract release edin.

Rollback nə deməkdir?

Effektiv rollback sadəcə əvvəlki tətbiq image-ni deploy etmək deyil. Sual budur: əvvəlki kod yeni sxem və yeni məlumatla işləyə biləcəkmi? Expand mərhələsinin üstünlüyü budur ki, tətbiq kodunu geri çəkmək adətən məlumat strukturunu geri almağı tələb etmir.

Rollback planında ən azı bunlar olmalıdır:

  • Feature flag ilə yeni oxu/yazı yolunun söndürülməsi.
  • Əvvəlki tətbiq versiyasının yeni nullable sahələr mövcud olduqda işləməsinin təsdiqi.
  • Backfill job-un dayandırılması və ya sürətinin sıfırlanması.
  • Uyğunsuz yazıların necə aşkar ediləcəyi və düzəldiləcəyi.
  • Qərar həddi: məsələn, error rate, p95 latency, deadlock, validation fərqi və ya biznes metrikində qəbul olunmayan dəyişiklik.
  • Komanda rolları, əlaqə kanalı və dəyişiklik qeydləri.

Destruktiv rollback, məsələn yenicə yazılmış məlumatı köhnə sütuna sığdırmaq, çox vaxt “geri qaytarma”dan daha risklidir. Buna görə schema contract addımını gecikdirmək, məlumatın həqiqi geri dönüş nöqtəsini qorumağın əsas yoludur.

Birbaşa deploy etməməyi göstərən xəbərdarlıq işarələri

  • Cədvəl böyükdür və DDL-in lock müddəti ölçülməyib.
  • Bir migration həm sütunu silir, həm kodu dəyişir, həm də milyonlarla sətri yeniləyir.
  • Migrasiya skripti uzun transaction daxilində işləyir və pause/resume imkanı yoxdur.
  • Yeni model üçün data-quality qaydaları, null davranışı və istisnalar müəyyən edilməyib.
  • Köhnə mobil klientlərin nə qədər müddət aktiv qalacağı bilinmir.
  • Rollback “lazım olsa geri deploy edərik” cümləsindən ibarətdir.
  • Monitorinqdə DB lock wait, replication lag, job uğursuzluğu və biznes səviyyəli integrity metrikləri yoxdur.

POLADO bu prosesi necə dəstəkləyə bilər?

Verilənlər bazası dəyişiklikləri məhsulun davamlı sahibliyinin hissəsidir: kod, infrastruktura çıxış, alert-lər, runbook-lar və komanda qərarları bir yerdə işləməlidir. POLADO veb platformaların hazırlanması və mobil tətbiqlərin hazırlanması işlərində schema review, release sequencing, test avtomatlaşdırması, monitoring və incident-ready rollback planlarını məhsulun arxitekturasına uyğun qura bilər.

Qarşıda riskli schema və ya data dəyişikliyi varsa, bizimlə əlaqə saxlayın. Konsultasiya zamanı asılılıqları xəritələyə, expand-and-contract planını hazırlaya, backfill və validation meyarlarını müəyyənləşdirə və istehsal releasi üçün praktik runbook yarada bilərik.