Şema Değişiklikleri Neden Risklidir?

Üretim veritabanında kolon yeniden adlandırmak, veri tipini değiştirmek, yeni ilişki eklemek veya indeks oluşturmak yalnızca bir DDL komutu çalıştırmaktan ibaret değildir. Uzun süren kilitler, bekleyen sorgular, replica gecikmesi, uygulama sürümleri arasındaki uyumsuzluk ve yarım kalmış veri taşıma işlemleri kesintiye ya da sessiz veri bozulmasına yol açabilir.

Güvenli bir değişikliğin hedefleri şunlardır:

• Eski ve yeni uygulama sürümlerinin belirli bir süre birlikte çalışabilmesi.
• Değişikliğin küçük, gözlemlenebilir ve geri alınabilir adımlara ayrılması.
• Veri bütünlüğünün yalnızca uygulama koduna bırakılmaması.
• Her adımın süre, kilit, hata, kaynak tüketimi ve tutarlılık açısından ölçülmesi.

Expand-Contract ile Geriye Uyumlu Geçiş

Genel olarak en güvenli yaklaşım üç aşamalıdır: genişletme, geçiş ve daraltma.

1. Genişletme: Yeni kolon, tablo veya indeks eklenir; mevcut uygulamanın çalışması bozulmaz. Yeni kolon zorunlu olacaksa önce NULL değer kabul edebilir. Gerekli varsayılan değerler, tabloyu uzun süre kilitlemeyecek bir yöntemle ve ölçülerek uygulanmalıdır.
2. Geçiş: Uygulama bir süre hem eski hem yeni alanı okuyup yazacak şekilde geriye uyumlu hale getirilir. Mevcut kayıtlar küçük partilerle taşınır ve yeni sürümün doğru çalıştığı doğrulanır.
3. Daraltma: Tüm okuma ve yazma trafiğinin yeni yapıyı kullandığı kanıtlandıktan sonra eski kolon, tablo veya kod kaldırılır. Gecikmeli worker'lar, eski uygulama sürümleri ve raporlama süreçleri hesaba katılmadan bu adım uygulanmamalıdır.

Kolon yeniden adlandırma gibi görünen basit değişikliklerde bile doğrudan rename yerine yeni alan eklemek, veriyi taşımak ve tüketicileri kademeli olarak geçirmek çoğu üretim sisteminde daha düşük risklidir.

Transaction, Kilit ve İzolasyon Kontrolleri

Migration öncesinde ilgili sorguların hangi izolasyon seviyesinde çalıştığı, hangi satır veya tabloları kilitlediği ve bekleyen işlemlerle nasıl etkileştiği incelenmelidir. Migration oturumunda makul bir lock timeout ve statement timeout kullanmak, işlemin sonsuza kadar beklemesini önler; ancak timeout değerleri belirlenirken uygulamanın normal transaction süresi ve yeniden deneme davranışı dikkate alınmalıdır.

• Başlamadan önce aktif transaction'lar ve uzun süren sorgular kontrol ediliyor mu?
• DDL beklenenden uzun sürerse güvenli biçimde durdurulabiliyor mu?
• Backfill aynı kayıtları yeniden işlerse sonuç yine doğru kalıyor mu?
• Uygulama ve migration eşzamanlı çalışırken kısmi yazım oluşabilir mi?
• Foreign key, unique ve NULL kuralları geçiş boyunca korunuyor mu?
• Retry mekanizması aynı işlemi tekrarladığında veri çoğalması veya çift kayıt oluşuyor mu?

Yeni bir constraint doğrudan tüm tabloya uygulanamıyorsa önce mevcut ihlaller raporlanmalı, veriler düzeltilmeli ve constraint doğrulanarak etkinleştirilmelidir. Kısıtı geçici olarak etkisizleştirmek, kısa vadede kolay görünse de sonradan güvenilir bir doğrulama kanıtı üretmeyi zorlaştırır.

Backfill ve Çift Yazma Tasarımı

Backfill deterministik sıralanmalı, kaldığı yerden devam edebilmeli ve başarısız parçalar güvenle yeniden çalıştırılabilmelidir. Büyük bir tabloyu tek transaction içinde güncellemek yerine birincil anahtar aralıkları veya uygun bir cursor ile küçük batch'ler kullanmak transaction süresini, kilit baskısını ve rollback maliyetini azaltır.

• Batch boyutunu trafik, lock bekleme süresi ve replica gecikmesine göre ayarlayın.
• Her batch için başlangıç-bitiş anahtarı, işlenen kayıt sayısı, hata sayısı ve süreyi kaydedin.
• Aynı kaydın birden fazla worker tarafından işlenmesini önleyin veya işlemi idempotent tasarlayın.
• Yeni ve eski alanlar arasında mümkün olduğunca tam tutarlılık kontrolü yapın.
• Tablo büyümesini, disk kullanımını, indeks boyutunu ve replikasyon gecikmesini izleyin.

Çift yazma kullanılacaksa iki alanın aynı transaction içinde güncellenmesi tercih edilir. Yine de yönetim komutları, toplu içe aktarımlar, eski worker sürümleri ve doğrudan çalışan bakım araçları kapsanmıyorsa çözüm eksik kalır. Tutarlılık kontrolünde yalnızca toplam kayıt sayısına bakmayın; NULL oranı, benzersiz değer sayısı, ilişkisiz kayıtlar, toplamlar ve alan bazlı güvenli özetleri de karşılaştırın. Hassas verileri loglamak yerine sayaç ve geri döndürülemez özetler kullanın.

Ölçümleme, Yayına Alma ve Geri Dönüş

Değişiklikten önce normal sorgu gecikmesi, hata oranı, connection pool kullanımı, lock beklemeleri ve replica gecikmesi için referans ölçüm alınmalıdır. Yayın sırasında en az şu sinyaller izlenmelidir:

• DDL ve backfill süresi ile batch başına işlenen kayıt sayısı.
• Kilit bekleme süresi, deadlock ve lock timeout sayısı.
• Birincil veritabanı ile replikalar arasındaki gecikme.
• Uygulama hata oranı, sorgu p95/p99 gecikmesi ve connection pool doluluğu.
• Eski ve yeni alan arasındaki tutarsız kayıt sayısı.
• Disk kullanımı, indeks oluşturma süresi ve kaynak tüketimi.

Geri dönüş planı yalnızca “migration'ı geri alırız” dememelidir. Yeni veriler yazıldıktan sonra eski yapının nasıl korunacağı, hangi uygulama sürümüne dönülebileceği, yarım kalan batch'lerin nasıl ele alınacağı ve yeni yazılmış verilerin nasıl kaybolmadan tutulacağı önceden belgelenmelidir. Bazı değişikliklerde fiziksel rollback yerine ileri yönlü düzeltme migration'ı daha güvenlidir.

Üretime Alma Karar Kriteri

Değişiklik başarısız olduğunda bunu kaç dakika içinde fark edeceğiniz, hangi kanıtla veri bütünlüğünü doğrulayacağınız ve kullanıcı trafiğini kesmeden hangi adımı geri alabileceğiniz net değilse migration hazır değildir. Başarı kriterleri, durdurma eşikleri ve sorumlular yayın öncesinde yazılı olmalıdır; ölçülemeyen bir migration, düşük trafikte çalışsa bile üretimde güvenli kabul edilmemelidir.