Neden Şema Değişiklikleri Risklidir?

Üretimde çalışan bir SaaS uygulamasında tabloya kolon eklemek veya bir alanı yeniden adlandırmak yalnızca veritabanı işlemi değildir. Aynı anda eski uygulama sürümü, yeni sürüm, arka plan işçileri ve raporlama süreçleri aynı veriye erişebilir. Bu bileşenlerden biri yeni şemayı beklerken diğeri eski davranışı varsayarsa deploy sonrasında hata, veri kaybı veya uzun süreli kilitlenme oluşabilir.

Temel hedef, uygulama ile veritabanını tek adımda değiştirmek yerine geriye dönük uyumlu küçük adımlarla ilerlemektir. Böylece sorun yaşandığında tüm sistemi geri almak yerine yalnızca son değişikliği durdurmak mümkün olur.

Expand-Contract Yaklaşımı

Güvenli şema değişikliklerinde yaygın yöntem üç aşamalıdır:

• Expand: Yeni kolon, tablo veya indeks eski uygulamayı bozmayacak şekilde eklenir. Yeni kolon başlangıçta NULL kabul edilebilir veya güvenli bir varsayılanla oluşturulabilir.
• Migrate: Uygulama yeni ve eski alanları kontrollü biçimde destekler. Mevcut kayıtlar küçük partiler hâlinde taşınır; tek bir uzun transaction ile tüm tablo kilitlenmez.
• Contract: Trafik ve kayıtların yeni yapıyı kullandığı doğrulandıktan sonra eski kolon, kod yolu veya indeks kaldırılır.

Örneğin full_name alanını first_name ve last_name olarak ayırmak için önce yeni kolonlar eklenir. Uygulama bir süre yeni alanları yazarken eski alanı da günceller. Backfill tamamlanıp okuma trafiği yeni alanlara geçirildikten sonra eski kolon kaldırılır. Yeniden adlandırma işlemini doğrudan yapmak, eski sürüm çalışan sunucuların sorgularını bozabileceği için tercih edilmemelidir.

Migration Tasarımında Kontrol Listesi

Her migration için aşağıdaki sorular yanıtlanmalıdır:

• İşlem tabloyu ne kadar süre kilitleyebilir?
• Mevcut tablo boyutu büyüdüğünde migration süresi nasıl değişir?
• İndeks oluşturma işlemi veritabanının çevrim içi çalışma seçeneklerine uygun mu?
• Migration yarıda kalırsa güvenli şekilde yeniden çalıştırılabilir mi?
• Uygulamanın eski ve yeni sürümü aynı anda çalışırken sorgular bozulur mu?
• Geri dönüş planı gerçekten uygulanabilir mi, yoksa yalnızca teorik bir not mu?

Büyük tablolarda backfill işlemi sayfalama, primary key aralığı veya küçük batch boyutlarıyla yürütülmelidir. Her batch sonrasında kısa beklemeler ve izleme yapılması, normal kullanıcı trafiğinin kaynak tüketimini sınırlayabilir. Migration dosyaları sürüm kontrolünde tutulmalı; elle çalıştırılan üretim komutlarıyla kalıcı şema değişikliği yapılmamalıdır.

Kod, Test ve CI/CD Güvenceleri

Şema değişikliğinin yalnızca migration testinden geçmesi yeterli değildir. Uygulamanın veri erişim katmanı, API davranışı ve arka plan görevleri de test edilmelidir. Özellikle şu senaryolar değerlidir:

• Eski uygulama sürümü yeni şemayla çalışabiliyor mu?
• Yeni uygulama sürümü eski kayıtları eksik veriyle güvenli biçimde okuyabiliyor mu?
• Backfill sırasında oluşan yeni kayıtlar da doğru şekilde taşınıyor mu?
• Aynı migration ikinci kez çalıştırıldığında veri bozuluyor mu?
• Deploy geri alındığında yeni kolon veya tablo nedeniyle hata oluşuyor mu?

CI/CD hattında migration önce izole bir veritabanında, sonra üretime benzer veri hacminde denenmelidir. Kod incelemesinde yalnızca SQL sözdizimine değil, kilitlenme davranışına, transaction sınırlarına ve beklenen çalışma süresine de bakılmalıdır. Migration ile uygulama deploy sırası açıkça tanımlanmalı ve otomatik deploy adımı başarısız olduğunda uygulamanın hangi sürümde kalacağı bilinmelidir.

Gözlemleme, Geri Dönüş ve Operasyon

Deploy sonrasında hata oranı, sorgu gecikmesi, veritabanı kilitleri, bağlantı havuzu kullanımı ve backfill ilerlemesi izlenmelidir. Yeni alanın doluluk oranı ile eski ve yeni okuma sonuçlarının tutarlılığı ayrıca ölçülebilir.

Bir migration için geri dönüş planı şu ayrımı içermelidir: Uygulama kodunu geri almak çoğu zaman kolaydır; veritabanındaki veri dönüşümünü tersine çevirmek ise kayıplı olabilir. Bu nedenle eski kolonu hemen silmek yerine gözlem süresi boyunca korumak, kritik verilerde yedek veya doğrulanabilir snapshot almak daha güvenlidir. Geri dönüş kararı ölçülebilir eşiklere bağlanmalıdır; örneğin belirli bir hata oranı, kilitlenme süresi veya veri tutarsızlığı görüldüğünde işlem durdurulabilir.

Sonuç olarak güvenli şema değişikliği, tek seferlik bir SQL komutundan çok kontrollü bir ürün ve operasyon sürecidir. Küçük uyumlu adımlar, otomatik testler, izlenebilir migration kayıtları ve gerçekçi bir geri dönüş planı bakım maliyetini düşürür; ekiplerin hızlı geliştirme yaparken üretim güvenilirliğini korumasını sağlar.