Şema migrasyonu: veritabanı değişikliklerini kod gibi yönetmek

Şema migrasyonu nedir, neden gerekir?

Şema migrasyonu, bir veritabanının yapısındaki değişiklikleri (tablo ekleme, kolon değiştirme, indeks oluşturma, kısıt tanımlama) sıralı, kayıtlı ve tekrarlanabilir adımlar olarak uygulama pratiğidir. Amaç, geliştirme, test ve üretim ortamlarındaki veritabanlarının aynı değişiklik geçmişine sahip olmasını ve herhangi bir ortamın durumunun bilinmesini sağlamaktır.

Migrasyon yönetimi olmayan ekiplerde değişiklikler genellikle elle, bir yönetim aracından ya da gelişigüzel betiklerle yapılır. Sonuç tanıdıktır: test ortamında çalışan kod üretimde ‘kolon yok’ hatası verir, kimin hangi değişikliği ne zaman yaptığı bilinmez ve yeni bir ortam kurmak günler alır. Migrasyon araçları veritabanı yapısını uygulama kodu gibi sürüm kontrolüne alır; değişiklik gözden geçirilir, sırayla uygulanır ve geçmişi tutulur.

Bu yaklaşım ayrıca yeni geliştiricinin yerel ortamı kurmasını, bir ortamın sıfırdan yeniden oluşturulmasını ve felaket sonrası kurtarmayı kolaylaştırır.

Temel mantık: sıralı, kayıtlı ve değişmez migrasyonlar

Migrasyon araçlarının ortak mantığı basittir. Her değişiklik bir migrasyon dosyasına yazılır. Araç, veritabanında hangi migrasyonların daha önce uygulandığını bir kayıt tablosunda tutar ve henüz uygulanmamış olanları sırayla çalıştırır. Bir ortamda hangi değişikliklerin yapıldığı bu kayıttan okunur.

Temel kurallar şunlardır: • Sıra önemlidir: migrasyonlar belirli bir düzende uygulanır ve ortamdan ortama aynı sırada çalışmalıdır. • Uygulanmış migrasyon değiştirilmez: araçlar çoğunlukla dosyanın özetini (checksum) saklar ve içerik değişirse hata verir. Hatayı düzeltmek için yeni bir migrasyon yazılır. • Her değişiklik küçük ve tek amaçlıdır: büyük ve karışık bir migrasyon, hata durumunda neyin uygulandığını anlamayı zorlaştırır. • Elle değişiklik yapılmaz: üretimde araç dışı değişiklik, ortamlar arasında sapmaya (drift) yol açar. • Migrasyonlar sürüm kontrolünde, uygulama kodu ile aynı depoda ve aynı inceleme sürecindedir.

Flyway ve Liquibase: farklı yaklaşımlar

Flyway ve Liquibase en bilinen migrasyon araçlarıdır; amaçları aynıdır ama yaklaşımları farklıdır.

Flyway, doğrudan SQL ile çalışmayı tercih eder. Her migrasyon sürüm bilgisini taşıyan adı olan bir dosyadır; araç dosyaları sürüm sırasına göre uygular. Sürümlü migrasyonlara ek olarak, her değişiklikte yeniden uygulanabilen tekrarlanabilir migrasyonlar da (örneğin görünüm ve yordam tanımları için) desteklenir. SQL bilen ekipler için öğrenme eğrisi düşüktür; veritabanına özgü ifadeleri doğrudan kullanabilirsiniz.

Liquibase ise değişiklikleri değişiklik setleri (changeset) olarak tanımlar ve bunları bir değişiklik günlüğünde (changelog) toplar. Değişiklik setleri XML, YAML, JSON ya da SQL ile yazılabilir; soyut tanımlar, aracın farklı veritabanları için uygun SQL’i üretmesini sağlar. Her değişiklik seti kimlik ve yazar bilgisiyle tanımlanır, ön koşul ve bağlam (hangi ortamda çalışacağı) belirtilebilir. Birden fazla veritabanı türünü destekleyen ürünlerde bu esneklik avantajdır.

Seçim, ekip alışkanlığına, desteklenecek veritabanı çeşitliliğine ve geri alma ihtiyacına bağlıdır. Her araçta temel disiplin aynıdır; araç yalnızca bu disiplini uygulayan mekanizmadır.

Geriye dönük uyumlu şema tasarımı

Kesintisiz dağıtımda veritabanı ve uygulama aynı anda güncellenmez. Dağıtım sırasında bir süre eski uygulama sürümü yeni şema ile, yeni sürüm ise eski şema ile çalışabilir. Bu yüzden şema değişiklikleri geriye dönük uyumlu olmalıdır.

Bunun için yaygın desen, değişikliği aşamalara bölmektir (genişlet, taşı, daralt): • Genişlet: yeni kolon ya da tabloyu ekleyin; eski yapıya dokunmayın. Yeni kolonu başlangıçta boş değer kabul edecek şekilde tanımlayın. • Uygulamayı güncelle: kod hem eski hem yeni yapıya yazsın, önce eskiyi okusun. • Veriyi taşı: mevcut veriyi yeni yapıya kopyalayın ve tutarlılığı doğrulayın. • Okumayı yeni yapıya çevir: uygulama yalnızca yeni yapıyı kullansın. • Daralt: eski kolonu, yeni yapı yeterince doğrulandıktan sonra kaldırın.

Örneğin bir kolonu yeniden adlandırmak tek adımda yapıldığında, eski kodu çalıştıran sunucular hata verir. Genişlet-taşı-daralt akışında ise hiçbir aşamada çalışan sürümlerden biri bozulmaz. Süreç uzar ama kesinti riski ortadan kalkar.

Büyük veri setlerinde güvenli migrasyon

Küçük tabloda saniyeler süren bir değişiklik, büyük tabloda uzun süre kilit tutarak uygulamayı durdurabilir. Büyük tablolara dokunmadan önce değişikliğin veritabanı motorunuzda nasıl davrandığını bilmek gerekir: hangi işlemler tabloyu kilitler, hangileri yeniden yazım gerektirir, hangileri çevrimiçi yapılabilir. Bu davranış veritabanına ve sürüme göre değişir; belgelerine bakın.

Güvenli uygulama için şu pratikler işe yarar: • Büyük veri taşımalarını tek işlemde değil, küçük partiler halinde yapın; her partinin ardından kısa bekleyin ve yükü izleyin. • Yeni kolon eklerken ağır varsayılan değer hesaplamalarından kaçının; veriyi arka planda doldurun. • İndeksleri üretimi kilitlemeyen yöntemlerle oluşturun (veritabanınız destekliyorsa). • Kilit zaman aşımı ve ifade zaman aşımı tanımlayın; migrasyon beklerken uygulama sorgularını tıkamasın. • Üretim büyüklüğüne yakın bir kopyada prova edin ve süreyi ölçün. • Yoğun olmayan bir zaman penceresi seçin, bir geri dönüş planı hazırlayın.

Bu önlemler migrasyonu daha yavaş ama öngörülebilir kılar. Üretimde öngörülebilirlik hız kadar önemlidir.

Pipeline entegrasyonu ve geri alma stratejisi

Migrasyonlar sürekli teslim hattının bir parçası olmalıdır. Tipik akışta her değişiklikte boş bir veritabanında tüm migrasyonlar baştan çalıştırılır, uygulama testleri bu şemaya karşı koşulur ve geçerse bir test ortamında gerçekçi veriyle prova edilir. Üretimde uygulama ise onaylı ve izlenen bir adım olarak yapılır.

Geri alma konusunda farklı yaklaşımlar vardır. Biri, her migrasyona ters yönde bir betik yazmaktır. Diğeri ileri doğru düzeltmedir: sorun çıkarsa yeni bir migrasyonla durumu düzeltmek. Veri silen ya da dönüştüren değişikliklerde ters betik çoğu zaman gerçek bir geri dönüş sağlamaz; bu yüzden uygulama öncesi yedek ve geriye dönük uyumlu tasarım daha güvenilir güvencedir.

Pipeline’a şu kontroller eklenebilir: tehlikeli ifadelerin (örneğin koşulsuz silme, tablo düşürme) uyarıya takılması, migrasyon sürelerinin raporlanması, şema ile migrasyon geçmişi arasındaki sapmanın tespiti ve migrasyonu çalıştıran hesabın yetkilerinin sınırlandırılması.

Yönetişim: kim, ne zaman, nasıl değiştirir?

Teknik araç kadar süreç de önemlidir. Migrasyon dosyaları koddaki gibi gözden geçirilmeli, özellikle veri silme, kolon kaldırma ve büyük tablolara dokunan değişiklikler için ek bir uzman onayı istenmelidir. Her migrasyonun bir sahibi olmalı ve amacı açıklamasında yazılı olmalıdır.

Birden fazla ekibin aynı veritabanını değiştirdiği yapılarda çakışma sık sorundur. Sürüm numaralandırma kuralı, dallar arasında sıra çakışmalarını çözme yöntemi ve ortak şema için sorumlu ekip net olmalıdır. Servis başına ayrı veritabanı modeli çakışmayı azaltır ama veri tutarlılığı sorumluluğunu uygulama katmanına taşır.

Son olarak acil durum yolu tanımlanmalıdır. Üretimde acil müdahale gerekirse, elle yapılan değişikliğin ardından aynı değişiklik migrasyon olarak depoya geri işlenmelidir; aksi halde ortamlar sapar ve bir sonraki dağıtım beklenmedik biçimde başarısız olur.

Nasıl öğrenilir ve Mindset'te nerede çalışılır?

Başlangıçta yerel bir veritabanında bir araç seçip birkaç migrasyon yazmak, bir hatayı yeni migrasyonla düzeltmek ve checksum hatasını bilerek tetikleyip anlamak mantığı oturtur. Ardından geriye dönük uyumlu değişiklikler, büyük tablo provası ve pipeline entegrasyonu çalışılır.

Mindset'in Veritabanı Şema Migrasyonları ve Sürümleme (Liquibase, Flyway) programının modülleri şunlardır: veritabanı değişiklik yönetimi temelleri, Flyway ile migrasyon uygulamaları, Liquibase ile değişiklik setleri, geriye dönük uyumlu şema tasarımı, büyük veri setlerinde güvenli migrasyon, pipeline entegrasyonu ve yönetişim.