Veritabanı Göçleri: Şema Değişikliklerini Sürümlemek
Yerelde çalışan yeni özellik canlıda hata veriyor: "böyle bir sütun yok". Çünkü tabloya eklediğiniz sütunu canlı veritabanına eklemeyi unuttunuz. Kod sürüm kontrolünde ama veritabanı yapısı değil — ve bu ayrım, en sık yaşanan yayın sorunlarından birini üretir.
Bu yazı, şema değişikliklerinin yönetimini ele alıyor.
Elle Yapmanın Sorunu
| Elle yönetim | Göç dosyaları |
|---|---|
| Unutulabilir | Kodla birlikte gider |
| Sıra bilinmez | Sıra kayıtlıdır |
| Ortamlar farklılaşır | Ortamlar aynı olur |
| Geçmiş yoktur | Değişim izlenebilir |
Üçüncü satır zamanla en büyük soruna dönüşür: elle yönetilen veritabanlarında geliştirme, test ve canlı ortam yavaş yavaş birbirinden ayrışır — bir süre sonra hangi ortamda hangi sütunun olduğunu kimse bilmez.
Bu farklılaşma testleri güvenilmez kılar.
Yerelde çalışan kod canlıda çalışmaz.
Göç dosyaları bu ayrışmayı kökten engeller.
Nasıl Çalışır
- Her değişiklik bir dosyaya yazılır.
- Dosyalar sıralı numaralanır.
- Uygulananlar tabloda tutulur.
- Eksikler sırayla çalıştırılır.
Üçüncü madde mekanizmanın kalbidir: veritabanında hangi göçlerin uygulandığını tutan küçük bir tablo, aynı değişikliğin iki kez çalışmasını önler ve yeni bir ortamı sıfırdan doğru yapıya getirir.
Bu tablo otomatik oluşturulur.
Dördüncü madde ise dağıtım adımına dahil edilir.
Kod yüklendikten sonra göçler çalıştırılır.
Geri Alma
- Her göçün geri alma adımı olmalı.
- Bazı işlemler geri alınamaz.
- Veri kaybı riski değerlendirilmeli.
İkinci madde dürüst bir sınırı kabul eder: bir sütunu silen göçün geri alınması sütunu geri getirir ama içindeki veriyi getirmez — yapı geri döner, veri dönmez.
Bu nedenle silme işlemleri iki aşamalı yapılmalıdır.
Önce kullanımdan kaldırılır, sonra silinir.
Aradaki sürede sorun çıkarsa geri dönmek kolaydır.
Canlıda Büyük Tablolar
| İşlem | Risk |
|---|---|
| Küçük tabloya sütun ekleme | Sorunsuz |
| Milyonluk tabloya sütun ekleme | Uzun kilit |
| Dizin ekleme | Uzun sürebilir |
| Sütun türü değiştirme | Tablo yeniden yazılır |
Dördüncü satır en tehlikelisidir: sütun türünü değiştirmek çoğu veritabanında tablonun tamamının yeniden yazılması demektir — büyük bir tabloda bu işlem dakikalarca sürer ve o süre boyunca site yanıt veremez.
Bu tür göçler bakım penceresinde yapılmalıdır.
Modern sürümler bazı işlemleri kilitsiz yapabilir.
Hangi işlemin kilitli olduğu önceden kontrol edilmelidir.
Veri Göçleri
- Yapı değişikliği ayrı tutulur.
- Veri dönüşümü ayrı tutulur.
- Büyük veri parça parça işlenir.
Üçüncü madde zaman aşımlarını önler: milyonlarca satırı tek bir göç adımında güncellemek, zaman aşımına uğrayıp yarım kalabilir ve veritabanını tutarsız bırakır — parça parça ilerleyen bir betik daha güvenlidir.
Bu betik kaldığı yerden devam edebilmelidir.
Birinci ve ikinci maddelerin ayrılması ise geri almayı kolaylaştırır.
Yapı geri alınabilir, veri dönüşümü genellikle alınamaz.
Geriye Dönük Uyumluluk
- Eski kod yeni şemayla çalışabilmeli.
- Dağıtım anında ikisi bir arada olur.
- Sütun silme ertelenmeli.
İkinci madde çoğu kişinin düşünmediği bir andır: göç çalıştıktan sonra kod yüklenene kadar geçen sürede eski kod yeni şema üzerinde çalışır — bu kısa aralıkta eski kodun kırılmaması gerekir.
Bu nedenle sütun silme aynı yayında yapılmamalıdır.
Önce kod sütunu kullanmayı bırakır.
Sonraki yayında sütun silinir.
Bu iki aşamalı desen kesintisiz yayın için gereklidir.
Göçleri Test Etmek
| Test | Amaç |
|---|---|
| Boş veritabanında çalıştırma | Sıfırdan kurulum doğru mu |
| Üretim kopyasında çalıştırma | Süre ve kilit ölçümü |
| Geri alma denemesi | Kurtarma yolu |
İkinci satır sürprizleri önler: yerelde saniyeler süren bir göç, milyonlarca satırlık üretim verisinde dakikalar sürebilir — bu süre ancak gerçek veri kopyasında ölçülerek bilinir.
Ölçüm, bakım penceresi planlamasını gerçekçi kılar.
Birinci satır ise yeni ortam kurulumunu doğrular.
Tüm göçler baştan sona çalışabilmelidir.
Paylaşımlı Barındırmada
- Komut satırı olmayabilir.
- Web üzerinden çalıştırma gerekir.
- Erişim kısıtlanmalıdır.
Üçüncü madde kritik bir güvenlik önlemidir: göç çalıştıran bir web adresini korumasız bırakmak, herkesin veritabanı yapınızı değiştirebilmesi demektir — bu adres mutlaka kimlik doğrulama ardında olmalı veya kullanımdan sonra kaldırılmalıdır.
Anahtar ile korumak pratik bir yöntemdir.
Çalıştırma sonrası dosya silinmelidir.
Zaman aşımı sınırı da dikkate alınmalıdır.
Göç betiklerini komut satırından çalıştırabilmek işleri belirgin kolaylaştırır; paylaşımlı hosting paketleri ile terminal ve veritabanı erişimini birlikte kullanabilirsiniz.
Sonuç
Kod sürüm kontrolündeyse veritabanı yapısı da öyle olmalıdır. Elle yönetilen veritabanlarında ortamlar yavaşça ayrışır ve bir süre sonra hangi ortamda hangi sütunun olduğunu kimse bilmez. Göç dosyaları bunu çözer. Büyük tablolarda dikkatli olun — sütun türü değiştirmek tablonun tamamının yeniden yazılması demektir — ve sütun silmeyi bir sonraki yayına bırakın.
Sıkça Sorulan Sorular (SSS)
Göç dosyalarına neden ihtiyacım var?
Elle yönetimde geliştirme, test ve canlı ortam yavaşça ayrışır; bir süre sonra hangi ortamda hangi sütunun olduğunu kimse bilmez ve yerelde çalışan kod canlıda çalışmaz. Göç dosyaları kodla birlikte gider ve tüm ortamları aynı yapıda tutar.
Büyük tabloda göç çalıştırmak riskli mi?
Bazı işlemler riskli. Sütun türü değiştirmek çoğu veritabanında tablonun tamamının yeniden yazılması demektir; büyük bir tabloda dakikalarca sürer ve o süre boyunca site yanıt veremez. Böyle göçleri bakım penceresinde yapın.
Kullanılmayan sütunu hemen silebilir miyim?
Aynı yayında silmeyin. Göç çalıştıktan sonra kod yüklenene kadar geçen sürede eski kod yeni şema üzerinde çalışır. Önce kod sütunu kullanmayı bırakmalı, silme bir sonraki yayına kalmalıdır.
Komut satırım yoksa nasıl çalıştırırım?
Web üzerinden çalıştırabilirsiniz ama o adresi korumasız bırakmayın; herkesin veritabanı yapınızı değiştirebilmesi demektir. Kimlik doğrulama ardına alın veya anahtarla koruyun ve çalıştırma sonrası dosyayı silin.
