Veri Tabanı Geçişi: Kesintiyi Azaltan Migration Planı

Şema değişikliğinin etkilediği tüketicileri çıkarın

Web uygulaması dışında kuyruk çalışanı, rapor, veri aktarımı ve mobil uygulama eski alanı kullanıyor olabilir. Migration planında bütün yazan ve okuyan bileşenler listelensin. Yalnızca yeni web sürümünün test edilmesi, arka plandaki eski işi korumaz.

Alan adı değişikliği kadar anlam değişikliği de önemlidir. “Durum” alanı yeni sürümde farklı değerler taşıyorsa eski kod yanlış karar verebilir. Veri tipi ve iş anlamını aynı değişiklik belgesinde açıklayın. Etkilenen raporlar ve entegrasyonlar kabul kapsamına dahil olsun.

Tek adım yerine aşamalı geçişi değerlendirin

Önerilen yaklaşımda önce yeni yapı eklenir, sonra veri doldurulur ve uygulama yeni yapıyı kullanmaya geçirilir. Eski alan ancak bütün tüketicilerin geçişi doğrulandıktan sonra kaldırılır. Bu, her proje için zorunlu tek yöntem değil, geriye uyumluluğu korumak için değerlendirilebilecek bir plandır.

PostgreSQL tablo değiştirme dokümantasyonu farklı değişiklik işlemlerinin davranışını açıklar. [1] Hangi komutun veri yeniden yazımı veya uzun işlem yaratabileceği kullanılan sürüm ve işlemle birlikte incelenmelidir. Küçük geliştirme tablosunda hızlı bitmesi büyük üretim tablosunda aynı sonucu kanıtlamaz.

Örnek: tam ad alanını iki alana ayırmak

Varsayımsal CRM’de tek “ad soyad” alanı yeni sürümde iki alana ayrılıyor. Metni ilk boşluktan bölmek her kayıt için doğru değildir. Veri dönüşümü belirsiz kayıtları incelemeye ayırmalı; orijinal değeri geçiş tamamlanana kadar korumalıdır.

Bu örnek, veri dönüşümünün sadece teknik biçim değişikliği olmadığını gösterir. İş anlamı kayboluyorsa komut başarıyla çalışmış olsa bile geçiş başarılı değildir.

Kilit ve uzun işlem riskini prova edin

Şema değişiklikleri diğer işlemlerle kilit etkileşimi yaşayabilir. PostgreSQL kilitleme rehberi farklı kilit türleri ve çakışmaları açıklar. [2] Planı gerçekçi veri büyüklüğü ve eşzamanlı iş yüküyle test edin. Süresi aşan işlemde ne yapılacağı önceden belirlenmelidir.

Geçiş sırasında biriken kuyruklar ve bekleyen kullanıcı işlemleri izlenmelidir. Komut iptal edildiğinde sistemin hangi durumda kaldığı bilinmelidir. “Gece yaparız” ifadesi teknik risk analizi yerine geçmez; gece çalışan raporlar veya dış entegrasyonlar da etkilenebilir.

Geri dönüşün sınırlarını açık yazın

Eski uygulama sürümüne dönmek, yeni biçimde yazılmış veriyi otomatik olarak eskiye çevirmeyebilir. Geri dönüş planında kod, şema ve veri ayrı değerlendirilmelidir. Bazı değişikliklerde geri almak yerine düzeltme sürümüyle ilerlemek daha uygun olabilir; karar önceden araştırılmalıdır.

Veri doldurma işi tekrar çalıştırıldığında aynı kaydı bozmamalıdır. Kontrol noktası, kaynak sürümü ve işlem sonucu tutulabilir. Hatalı partiler için yeniden deneme yolu bulunmalı; bütün tabloyu yeniden başlatmak tek seçenek olmamalıdır.

Yayın kararını kontrol dosyasıyla verin

Öncesi-sonrası kayıt sayıları, kritik alan kontrolleri, ilişkiler ve örnek iş akışları doğrulansın. Yedek ve geri yükleme provası, migration’dan önce planın parçası olmalıdır. Canlı veriye işlem yapma yetkisi ve zamanlaması ayrıca açıkça onaylanmalıdır.

Teslimde çalıştırılan sürüm, komutlar, kontrol sonuçları ve kalan istisnalar kayıtlı olsun. Kesintisiz çalışma garantisi vermek yerine hangi risklerin nasıl azaltıldığını ve hangi koşulların henüz test edilmediğini açıklayın.

Sık sorulan sorular

### Sütun eklemek her zaman risksiz mi? İşlemin türü, varsayılan değer, tablo büyüklüğü ve sürüme bağlıdır. Gerçek komutun davranışı doğrulanmadan genel güvence verilmemelidir.

Yedek varsa geri dönüş planına gerek var mı?

Gerek vardır. Yedeği geri getirme süresi, yeni işlemlerin uzlaştırılması ve uygulama uyumu ayrıca planlanmalıdır.