Veritabanı Migrasyonu Nedir?

Şema değişikliği de kod gibi sürümlenir

Bir geliştirici yerel veritabanına elle bir sütun ekleyip unutursa, aynı değişiklik test sunucusunda, diğer geliştiricilerin makinelerinde ve canlıda eksik kalır. Migrasyonlar bu sorunu, her şema değişikliğini sıralı ve sürümlü bir dosyaya dönüştürerek çözer:

migrations/
  20260915093000_create_customers.sql
  20260921110500_create_orders.sql
  20261003140500_add_phone_to_customers.sql

-- 20261003140500_add_phone_to_customers.sql
ALTER TABLE customers ADD COLUMN phone text;

Migrasyon aracı veritabanında, hangi dosyaların uygulandığını tutan bir kayıt tablosu saklar ve her çalıştırmada yalnızca eksik olanları sırayla uygular. Flyway ve Liquibase gibi bağımsız araçlar, Rails, Django ve Laravel'in yerleşik migrasyonları, Prisma Migrate ya da SQLAlchemy için Alembic aynı fikrin farklı uygulamalarıdır. Not: “migrasyon” kelimesi bir veritabanından diğerine veri taşımak ya da bir web sitesini yeni altyapıya geçirmek için de kullanılır; bu madde şema migrasyonunu anlatır.

Uygulanmış bir migrasyon asla düzenlenmez

Bir migrasyon herhangi bir ortamda, bir ekip arkadaşının makinesinde bile çalıştıysa, o dosya artık tarihtir. Dosyayı sonradan değiştirmek, aynı sürüm numarasının farklı ortamlarda farklı şemalar anlamına gelmesine yol açar; değişiklik, migrasyonu zaten uygulamış ortamlara hiçbir zaman ulaşmaz. Bazı araçlar uygulanmış dosyaların sağlama toplamını (checksum) saklar ve dosya değiştiğinde çalışmayı reddeder. Hata düzeltmenin doğru yolu, yeni bir migrasyon eklemektir.

Aynı nedenle veri dönüştüren migrasyonlar uygulamanın güncel model sınıflarına bağımlı olmamalıdır. Altı ay sonra model değiştiğinde, sıfırdan kurulan bir ortamda eski migrasyon artık var olmayan bir alanı arayıp kırılabilir.

Kesintisiz değişiklik: expand/contract

Kademeli veya blue-green deployment sırasında eski ve yeni uygulama sürümü bir süre aynı veritabanıyla birlikte çalışır. Bu yüzden bir sütunu tek adımda yeniden adlandırmak, henüz güncellenmemiş sunuculardaki kodu anında bozar. name sütununu full_name yapmak için güvenli sıra şudur:

1. Genişlet (expand): Yeni full_name sütununu boş bırakılabilir olarak ekleyin.
2. Uygulamayı her iki sütuna da yazacak şekilde yayına alın.
3. Eski kayıtları küçük partiler hâlinde yeni sütuna kopyalayın (backfill).
4. Okumaları yeni sütuna taşıyın ve eski sütuna yazmayı bırakın.
5. Daralt (contract): Eski sütunu ancak sonraki bir sürümde, hiçbir kod onu kullanmadığında silin.

Daha fazla adım gibi görünse de her adım tek başına geri alınabilir; tek seferlik bir değişiklikte bu esneklik yoktur.

Kilit, süre ve geri dönüş riskleri

• Kilitler: Bazı ALTER TABLE işlemleri tabloyu yeniden yazar veya yazmaları uzun süre bekletir; aynı komutun maliyeti veritabanına ve sürümüne göre değişir. PostgreSQL'de lock_timeout ayarlamak, kilit alamayan bir migrasyonun bütün trafiği arkasında biriktirmesini önler. Büyük tablolarda indeks eşzamanlı (CONCURRENTLY) oluşturulmalıdır.
• Uzun veri dönüşümleri: Milyonlarca satırı tek işlemde güncellemek yerine partilere bölmek, kilitleri ve replikasyon gecikmesini sınırlar.
• Geri dönüş: “Down” migrasyonları yazmak faydalıdır, ama silinmiş bir sütunun verisini geri getiremez. Kodda rollback çoğu zaman mümkündür; şemada ise genellikle ileriye doğru düzeltme tercih edilir. Riskli bir migrasyondan önce doğrulanmış bir yedek alınmalıdır.

Yayın sürecindeki yeri

Migrasyonlar her yayında bir kez ve tek bir süreç tarafından çalıştırılmalıdır; uygulamanın her örneğinin açılışta migrasyon denemesi yarış durumlarına yol açabilir. CI hattında migrasyonların boş bir veritabanına baştan sona uygulanabildiğini doğrulamak, canlıya benzer veri hacmine sahip bir staging ortamında da süreyi ölçmek, sürprizlerin çoğunu canlıya çıkmadan yakalar.