Kesin­ti­siz veri­ta­banı mig­ras­yon­ları

Bir sistemin tüm parçaları arasında en affetmeyeni veritabanıdır. Uygulama kodunu devreye alıp geri alabilir, bir servisi yeniden başlatabilir, bir sürümü çöpe atabilirsiniz — ama veritabanı yeniden üretemeyeceğiniz durumu tutar, kodun her bir sürümünden daha uzun yaşar ve çalışan tüm örnekler onu aynı anda paylaşır. Koddaki bir hata bir isteği etkiler; veritabanındaki bir hata herkesi etkiler ve çoğu zaman geri alınamaz.

Tam da bu yüzden veritabanı değişikliğinden o kadar korkulur ki birçok ekip onu bir bakım penceresine sürgün eder: sistemi durdur, değiştir, yeniden başlat. Bu dürüsttür ama ölçeklenmez — sistem ne kadar önemliyse her kesinti dakikası o kadar pahalıdır. Bu yazı diğer yolu gösteriyor: Bir şemanın, sistemi durdurmadan tam yük altında nasıl geliştirildiğini. Örüntüler framework'ler ve veritabanları genelinde geçerlidir; hangi işlemin ne ölçüde kilitlediği ilgili sisteme bağlıdır ve orada kontrol edilmelidir. İlke aynı kalır.

Veritabanı değişiklikleri neden tehlikelidir

Veritabanını üç özellik tehlikeli kılar ve bunlar birlikte etki eder.

Birincisi, birden fazla sürüm tarafından ortak kullanımdır. Kademeli (rolling) bir devreye almada belirli bir süre boyunca kodun eski ve yeni sürümü aynı anda aynı şemaya karşı çalışır. Yalnızca yeni sürüme uyan bir şema, hâlâ istek karşılayan eski sürümü bozar — ve tersi de geçerlidir. Bu yüzden her değişiklik her an çalışan iki sürüme de uymak zorundadır. Bir örnek: Yeni sürüm bir sütunun adını değiştirirse, eski sürüm aynı anda onu hâlâ eski adıyla arar — ve son eski örnek değiştirilene kadar her isteği başarısız olur. Hata kodda değil, yalnızca birine uyan bir şemada iki sürümün buluşmasındadır.

İkincisi kilit davranışıdır. Bazı yapısal değişiklikler, çalıştıkları sürece bir tabloya okuma veya yazma erişimini engelleyen bir kilit alır. Küçük bir tabloda bu görünmezdir; büyük bir tabloda aynı işlem dakikalar sürebilir ve bu sürede bütün sistemi durma noktasına getirebilir — tek bir mantıksal hata olmadan, yalnızca süre ve kilit yüzünden yaşanan bir kesinti.

Üçüncüsü geri döndürülemezliktir. Kod geri alınabilir; silinmiş veriler alınamaz. Yıkıcı bir değişiklik — kaldırılmış bir sütun, silinmiş bir tablo — tek yönlü bir yoldur. İleriye doğru düzeltebilirsiniz, ama geriye dönemezsiniz.

Kesintisiz migrasyon, bu üçünü de aşma disiplinidir: İki sürüm çalışırken uyumlu kalmak; kilitleri kısa, işlemleri eşzamanlı tutmak; ve yıkıcı olanı güvenli hâle gelene kadar ertelemek.

Expand / Contract

Taşıyıcı örüntü hep aynıdır: Mevcut yapıyı asla yerinde değiştirmezsiniz; yeniyi eklersiniz, ona taşınırsınız ve eskiyi kaldırırsınız — ayrı, tek tek devreye alınabilen, geriye dönük uyumlu adımlarla.

Expand şemayı eklemeli olarak genişletir: yeni bir sütun, yeni bir tablo, hiçbir şey kaybolmadan. Migrate boşluğu doldurur: Bir süre hem eskiye hem yeniye aynı anda yazarsınız ve mevcut verileri arka planda doldurursunuz. Contract daraltır: Eskiyi artık hiçbir şey okumadığında veya yazmadığında, ancak o zaman kaldırılır. Bu adımların her biri kendi başına geriye dönük uyumludur — ve böylece sonuncusu hariç tek tek devreye alınabilir ve tek tek geri alınabilir.

Şema: Hiçbir alan değiştirilmez; eklenir, doldurulur, sonra eskisi kaldırılır.

Somut bir örnek — name sütununun adı voller_name olarak değiştirilecek; bu tek adımda yapılırsa eski sürümü bozar. Expand: Yeni voller_name sütunu, name'e dokunulmadan eklemeli olarak eklenir. Migrate: Kod bundan sonra her iki sütuna da yazar ve bir arka plan işi mevcut değerleri name'den voller_name'e kopyalar. Her şey doldurulup kontrol edildiğinde kod okumayı voller_name'e geçirir — buraya kadar her adım geri alınabilir. Contract: Hiçbir sürüm name'i artık okumadığında veya yazmadığında eski sütun kaldırılır. Tehlikeli bir yeniden adlandırma beş zararsız adıma dönüşmüştür.

Öneri: Her kırıcı (breaking) değişikliği tek adımda yapmak yerine Expand, Migrate ve Contract adımlarına bölün. Bedeli, bir değişikliğin günlere yayılan birden fazla devreye almaya dönüşmesi ve bir süre iki durumun yan yana sürdürülmesi gerekmesidir. Kabul edilebilir bir bakım penceresi ve küçük veri miktarı olan bir sistemde farklı karar veririz; orada pencerede yapılan tek seferlik değişiklik, çok aşamalı danstan daha basit ve daha ucuzdur.

Geriye dönük uyumlu şema evrimi

Expand/Contract'ın arkasındaki kural kesin biçimde ifade edilebilir: Her şema durumu o anda çalışan kod sürümüne ve bir sonrakine uymalıdır. Bu geçerli olduğu sürece veritabanına dokunmadan her an devreye alabilir ve geri alabilirsiniz.

Tek bir işlemin bu kurala tek adımda uyup uymadığı türüne — ve veritabanına göre ayrıntılara — bağlıdır:

Eklemeli yarı neredeyse her zaman zararsızdır; kaldıran ve değiştiren yarı ise asla. Her yeniden adlandırma, her tip değişikliği, her kaldırma; eklemeli bir adım, taşınma ve geç bir temizlikten oluşan bir zincire dönüşür.

Güvenli yollardan ikisi açıklamayı hak ediyor, çünkü çoğu zaman şaşırtırlar. Pek çok veritabanında bir indeks, tabloyu yazma erişimine kilitlemeden eşzamanlı olarak oluşturulabilir — kilitleyen yoldan daha yavaş, ama kesintisiz. Ve bir constraint iki aşamada getirilebilir: önce mevcut veriler hemen kontrol edilmeden yalnızca yeni satırlar için geçerli olur, ardından ayrı ve kilitlemeyen bir adımda doğrulanır. Her iki durumda da kilitleyen bir işlemi görünmez bir işleme bölersiniz — kesin yöntem veritabanına göre değişir, örüntü değişmez.

Öneri: Şemada yalnızca çalışan ve bir sonraki kod sürümüne uyan durumlara izin verin ve geri kalan her şeyi bölün. Bedeli, her değişiklikte önceden düşünmektir — saf bir yaklaşımda tek adım olacak yerde iki üç adım planlarsınız. Kısa süre durdurulabilen dahili bir araçta farklı karar veririz; orada tek adımlı değişikliğin basitliği, bir dakikalık kesintiden kaçınmaktan daha ağır basar.

Deploy sırası

Uyumluluk kendiliğinden oluşmaz; şema ve kod devreye almalarının iç içe geçtiği sıradan doğar. Değişmez kural basittir: Şema, ona ihtiyaç duyan koddan önce genişletilir ve onu artık kullanmayan koddan sonra temizlenir. Arada adımlar sabit bir sırayla ilerler.

Ayrıntılı olarak: Önce şema genişletilir (Adım 1). Ardından hem eskiye hem yeniye aynı anda yazan ve mevcutsa yeniden okuyan kod devreye alınır (Adım 2). Eşzamanlı olarak backfill mevcut verileri doldurur (Adım 3). Ancak bundan sonra yalnızca yeniyi okuyan kod devreye alınır (Adım 4). Ve en sonunda, çalışan hiçbir örnek eskiye artık dokunmadığında, eski kaldırılır (Adım 5). Hiçbir adım bir başkasının tamamen devreye alınmış olmasını önkoşul olarak gerektirmez — her biri kendi başına eksiksiz ve uyumludur.

Şema: Önce genişlet, sonra taşın, en son kaldır — arada her durum her iki sürümle de uyumludur.

Bir şema değişikliği ile onun kırıcı kullanımı asla aynı devreye almaya konmaz. Her uygulama devreye alması kademelidir ve her an çalışan her örnek kendisine uyan bir şema bulur.

Öneri: Şemayı ve kodu ayrı ayrı ve bu sırayla devreye alın — kullanımdan önce Expand, değiştirmeden sonra Contract. Bedeli, tek bir sürüm onayı yerine birden fazla koordineli adımdan oluşan daha uzun bir devreye alma döngüsüdür. Değiştirme içermeyen, salt eklemeli bir değişiklikte — yeni bir işlev için yeni bir tablo — farklı karar veririz; orada tek adım yeterlidir, çünkü mevcut hiçbir şey dönüştürülmez.

Feature flag'ler ve migrasyonlar

Kodun devreye alınması ile yeni davranışın etkinleştirilmesi iki farklı şeydir — ve bir feature flag bunları birbirinden ayırır. Şema ve backfill çoktan hazır olabilir, yeni davranış ise bir flag'in arkasında hâlâ kapalıdır. Backfill kontrol edilip tutarlılık doğrulandığında flag okuma işlemlerini yeni sütuna geçirir. Bir şey ters giderse geri çevirirsiniz — yeni bir devreye alma olmadan, saniyeler içinde.

Böylece riskli bir kesim günü, geri alınabilir ve gözlemlenebilir bir anahtara dönüşür. Asıl kazanç budur: Bir migrasyonun en tehlikeli saniyesi — okumanın geçişi — devreye almadan ayrılır ve her an geri alınabilir hâle gelir. Bir flag ayrıca geçişi ya hep ya hiç biçiminde değil, önce trafiğin küçük bir kısmı için yapmaya izin verir; gözlemlersiniz ve hiçbir sapma yoksa genişletirsiniz. Böylece son ve en tehlikeli saniye bile karanlığa bir sıçrama olmaktan çıkar, kademeli ve gözlemlenebilir hâle gelir.

Öneri: Okumanın geçişini bir feature flag ile devreye almadan ayırın. Bedeli ek durumdur: Bir flag, test edilmesi ve — önemli — migrasyondan sonra yeniden kaldırılması gereken bir kod dallanmasıdır; unutulmuş bir flag kalıcı borçtur. Geri alınması hızlı bir yeniden deploy ile bir flag'in bakımından daha ucuz olan küçük, düşük riskli bir geçişte farklı karar veririz.

Veri migrasyonları ve şema migrasyonları

İki şey çoğu zaman aynı kefeye konur, ama tamamen farklı davranır. Bir şema migrasyonu yapıyı değiştirir — genellikle kısadır, ama kilitleyebilir. Bir veri migrasyonu satırları taşır veya dönüştürür — devasa ve uzun olabilir ve asla tek bir kilitleyen adımda çalışmamalıdır.

Belirleyici hata, büyük bir veri migrasyonunu deploy adımına koymaktır: Devreye almayı engeller ve muhtemelen tabloyu kilitler. Doğrusu, onu kontrollü bir arka plan işi olarak yürütmektir — batch'ler hâlinde, mükerrer işlemleri önleyen (idempotent) ve devam ettirilebilir, veritabanını aşırı yüklemesin diye kısıtlanmış (throttled) ve ilerlemesi görünür biçimde.

Batch boyutu burada temel ayar düğmesidir: Küçük batch'ler her transaction'ı kısa ve kilitleri düşük tutar, ama daha fazla tur gerektirir; büyük batch'ler daha hızlıdır, ama uzun transaction'lar ve veritabanı üzerinde baskı riski taşır. Batch'ler arasında iş kısa bir süre bekler, yükü gözlemler ve yanıt süreleri veya replikasyon gecikmesi artarsa kendini yavaşlatır. Her batch'ten sonraki bir kontrol noktası onu devam ettirilebilir kılar: Yarıda kesilirse baştan değil, son noktadan başlar — ve mükerrer işlemleri önleyen (idempotent) olduğu için iki kez işlenmiş bir batch bile zarar vermez.

Öneri: Veri migrasyonlarını eşzamanlı, batch'lenmiş, mükerrer işlemleri önleyen (idempotent) ve kısıtlanmış olarak — deploy'dan ayrı — çalıştırın. Bedeli, tek bir betikten daha fazla mekanizmadır: İlerleme, yeniden başlatma ve kısıtlama inşa edilmelidir. Kısa, kritik olmayan bir adımda yeniden yazılabilen küçük veri miktarlarında farklı karar veririz; orada tek seferlik çalıştırma, devam ettirilebilir bir işten daha basittir.

Geri alma stratejisi

Kesintisiz migrasyonun en önemli kavrayışı aynı zamanda en rahatlatıcı olanıdır: Veritabanını değil, kodu geri alırsınız. Her şema durumu geriye dönük uyumlu olduğu için uygulamayı geri almak her zaman güvenlidir — ek sütun kullanılmadan orada durur ve kimseyi rahatsız etmez. Bunun için veritabanına dokunmak gerekmez.

Tek istisna Contract adımıdır. Kaldırılmış bir sütun geri gelmez. Bu yüzden Contract son adımdır ve ancak gerçek trafik üzerinden güven oluştuğunda ve eskiye artık kimsenin ihtiyacı kalmadığında yürütülür. O zamana kadar eski sütunu ve verilerini saklarsınız.

Bunun migrasyon araçları açısından pratik bir sonucu vardır. Birçoğu, bir değişikliği otomatik olarak geri alan bir “down” migrasyonuna izin verir. Eklemeli adımlar için bu zararsızdır; Contract adımı için ise onu hiç yazmamak daha iyidir. Silinmiş bir sütunu verileriyle birlikte geri getirmesi beklenen otomatik bir geri alma, verileri geri getiremez — yalnızca içeriği olmayan aldatıcı bir yapı üretir ve sahte bir güvenlik hissi verir. Contract'tan sonraki bir hatadan dürüst dönüş yolu her zaman ileriye doğrudur: eksik olanı yeniden inşa etmek, zamanı geri çevirmek değil.

Öneri: Her migrasyonu, geri almanın yalnızca kodu geri alarak mümkün olacağı şekilde tasarlayın ve yıkıcı olanı en sona erteleyin. Bedeli, eski yapının bir süre birlikte yaşaması ve Contract adımını sonradan gerçekten yürütmek için disiplinli olmanız gerekmesidir. Yıkıcı kısmı olmayan eklemeli bir değişiklikte farklı karar veririz; orada kesin hiçbir şey yoktur ve özen yalnızca kilit davranışına yönelir.

Migrasyon sırasında gözlemlenebilirlik

Kesintisiz bir migrasyon, ne olduğunu görmenize dayanır — umut bir strateji değildir. Dört şey, ilk olaydan sonra değil, ilk dakikadan itibaren gözlem altında olmalıdır.

Birincisi kilitler: Bir migrasyon bir kilidi bekliyorsa veya bir kilit tutuyorsa istekler birikir — bu hemen görünür olmalıdır. İkincisi replikasyon gecikmesi: Ağır bir backfill replikaların geride kalmasına yol açabilir ve okumalar eskimiş verileri görür. Üçüncüsü, bir gerilemeyi hemen bir adıma bağlayabilmek için her adım sırasında ve sonrasında hata oranı ve yanıt süreleri. Dördüncüsü çift yazmanın tutarlılığı: Okuma geçirilmeden önce eski ile yeni karşılaştırılır ve ancak örtüştüklerinde geçiş yapılır. Bu karşılaştırma bir kez değil, Migrate aşaması boyunca sürekli olarak — örneklemelerle veya her iki sütunun bir sağlama toplamıyla — sapma kalıcı olarak sıfır olana kadar yapılır. Kalan bir sapma neredeyse her zaman henüz çift yazmayan unutulmuş bir yazma yoludur ve tam da bunu, okuma geçirilmeden önce bulmak istersiniz.

Öneri: Kilitleri, replikasyon gecikmesini, hata oranını ve çift yazma tutarlılığını her adım boyunca izleyin. Bedeli, sorunsuz bir günde görünür hiçbir şey üretmeyen enstrümantasyon ve dikkattir. Backfill içermeyen küçük, eklemeli bir değişiklikte farklı karar veririz; orada normal işletim izlemesi yeterlidir, çünkü ne kilit ne gecikme ne de çift yazma söz konusudur.

Sık yapılan hatalar

Hep aynı örüntüler sakin bir migrasyonu bir kesintiye dönüştürür:

• Kırıcı değişikliği tek adımda yapmak — Expand/Contract olmadan yeniden adlandırma, kaldırma, tip değişikliği.
• Şema ve kod değişikliğini aynı devreye almada yapmak; böylece eski sürüm yeni şemada kırılır.
• Deploy'un ortasında büyük bir tabloda uzun süre kilitleyen bir işlem.
• Kilitleyen ve kesildiğinde baştan başlayan tek bir devasa transaction içinde backfill.
• Ne mükerrer işlemleri önleyen (idempotent) ne de devam ettirilebilir olan bir veri migrasyonu.
• Eski sürüm hâlâ çalışırken eski sütunu çok erken kaldırmak.
• Verileri geri getirilemez biçimde kaybeden, veritabanının yıkıcı bir geri alınması.
• Kilitlerin ve replikasyon gecikmesinin gözlemlenmemesi — migrasyon kör çalışır.
• Hiç gelmeyen Contract adımı: Flag ve geçiş sütunu sonsuza kadar kalır, ara durum kalıcı duruma dönüşür.

Karar kontrol listesi

Her şema değişikliğinden önceki sorular. Bunlar hüküm değil, teşhis sorularıdır.

• Her şema durumu çalışan ve bir sonraki kod sürümüne uyuyor mu? Aksi takdirde kademeli devreye alma kırılır.
• Son Contract dışında her adım tek tek devreye alınabilir ve geri alınabilir mi? Geri alınamayan bir ara adım, gizli bir bakım penceresidir.
• Bir işlem büyük bir tabloda uzun süreli bir kilit alıyor mu? O zaman eşzamanlı çalıştırın veya bölün.
• Veri migrasyonu batch'lenmiş, mükerrer işlemleri önleyen (idempotent), devam ettirilebilir, kısıtlanmış — ve deploy dışında mı? Büyük backfill'ler devreye alma adımına ait değildir.
• Veritabanına dokunmadan yalnızca kodu geri alarak geri dönebiliyor muyuz? Geriye dönük uyumluluğun mihenk taşı budur.
• Yıkıcı Contract adımı güven oluşana kadar ertelendi mi? Kaldırmak kesindir.
• Kilitleri, replikasyon gecikmesini, hata oranını ve çift yazma tutarlılığını gözlemliyor muyuz? Kör migrasyon yapmak umut etmek demektir.
• Geçiş sütununu ve flag'i kaldırmak için bir sorumlu ve bir tarih var mı? Aksi takdirde ara durum kalıcı olur.

Sıkça Sorulan Sorular

Buna her değişiklik için ihtiyacımız var mı? Hayır. Eklemeli, nullable bir sütun veya yeni bir tablo tek bir güvenli adımdır. Tam Expand/Contract akışı yalnızca kırıcı değişiklikler için geçerlidir — yeniden adlandırma, kaldırma, tip değişikliği. Efor alışkanlığa göre değil, değişikliğin türüne göre belirlenir.

Kısa bir bakım penceresi daha basit değil mi? Bazen evet. Küçük sistemler, küçük veri miktarları ve tolere edilebilir kesinti için pencerede yapılan tek seferlik değişiklik, çok aşamalı akıştan daha ucuzdur. Kesintisiz migrasyon, kesinti pahalı olduğunda veya veri hacmi bir işlemi “kısa” denemeyecek kadar uzattığında karşılığını verir.

Eski sütunu ne kadar süre saklarız? Onu artık hiçbir şey okumayana veya yazmayana ve gerçek trafik üzerinden güven oluşana kadar. O zaman — ve ancak o zaman — Contract adımı gelir. Eski sütun sizin dönüş biletinizdir; ona hâlâ ihtiyaç duyabilecekken onu atmazsınız.

Bu şemasız veritabanları için de geçerli mi? Evet. “Şemasız” yalnızca şemanın veritabanında değil, örtük olarak kodda durduğu anlamına gelir. Verilerin biçimi yine de değişir, eski ve yeni sürüm aynı dokümanları okur ve Expand/Contract aynen geçerlidir — eklemeli olarak genişletmek, taşınmak, eski alanı en son kaldırmak.

Veri migrasyonunu kim çalıştırır? Deploy değil, kontrollü bir arka plan işi. Eşzamanlı, batch'ler hâlinde, kısıtlanmış ve devam ettirilebilir olarak, ilerlemesi görünür biçimde çalışır. Böylece ne devreye almayı ne de veritabanını engeller ve her an duraklatılıp yeniden başlatılabilir.

Backfill günler sürerse ne olur? Bu sorun değil. Sistemi rahatsız etmeden online ve kısıtlanmış olarak çalışır; okumanın geçişi, o bitip kontrol edilene kadar bekler. Uzun bir backfill, eşzamanlı ve devam ettirilebilir olduğu sürece sorun değildir — yalnızca kilitleyen bir backfill sorun olurdu.

İleri okuma

• Big bang olmadan legacy modernizasyonu — aynı Expand/Contract fikrinin bütün sistemlere uygulanması.
• Müşterileri kırmadan API sürümleme — arayüzde eklemeli, geriye dönük uyumlu değişiklik.
• Testler gerçekte ne zaman karşılığını verir — çift yazmanın tutarlılık kontrolünün neden migrasyonun en önemli testi olduğu.
• Idempotency ve PostgreSQL: JSONB ve tablolar — veri katmanındaki ilgili yapı taşları.

Temeli Batunet Engineering Method'tur: küçük, geri alınabilir adımlarla inşa etmek, hata durumu için tasarlamak, ilk günden itibaren gözlemlenebilirlik.

Başarılı bir veritabanı migrasyonunu kimse fark etmez. Bakım penceresi yok, gece yarısı endişesi yok, her şeyin tehlikede olduğu bir an yok — yalnızca ortaya çıkan, dolan ve bir noktada kaybolan bir sütun; sistem ise bu süre boyunca çalışmaya devam eder.