Blue-green, stateless uygulamalar için harika çalışır. İki ortam tek bir veritabanını paylaşır — ve bizim şema değişikliklerimiz rollback'i tam da ihtiyaç duyduğumuz anda imkânsız kıldı.

Durum:

  • Yeni sürümü green'e deploy et
  • Yeni sürüm açılışta DB migrasyonunu çalıştırır
  • Trafiği green'e geçir
  • Bir saat sonra bug keşfedildi
  • Blue'ya rollback yapmak istiyoruz...
  • Ama blue yeni şemayı okuyamıyor

Yıkıcı migrasyon:

-- The migration that shipped with the green release
ALTER TABLE users DROP COLUMN legacy_id;
ALTER TABLE users RENAME COLUMN user_id TO id;

Eski kod legacy_id ve user_id bekliyor. İkisi de gitti. Blue-green'i en başta meşrulaştıran “anında rollback” artık bir yedeği geri yüklemeyi ya da olayın ortasında elle ters migrasyon yazmayı gerektiriyor — DDL yazmak için olabilecek en kötü an.

Çözüm — üç release'e yayılmış expand/contract:

Release N (expand). Eskilere dokunmadan yeni kolonu ekleyin. Kod her iki kolona yazar ama hâlâ eski kolondan okur:

ALTER TABLE users ADD COLUMN id BIGINT;
-- backfill in batches to avoid long locks
UPDATE users SET id = user_id WHERE id IS NULL AND user_id < 100000;
-- ...repeat per batch, then:
CREATE UNIQUE INDEX CONCURRENTLY users_id_key ON users (id);

Bu noktada rollback? Önemsiz — eski kod yeni kolonu hiç görmez.

Release N+1 (okumaları taşı). Kod artık id'den okur, hâlâ iki kolona da yazar. Devam etmeden önce iki kolonu karşılaştıran bir eşlik (parity) kontrolü çalıştırın. Rollback? O da sorunsuz — önceki release hâlâ iki kolona yazdığından hiçbir kolon bayatlamaz.

Release N+2 (contract). Ancak N+1 kararlı çalıştıktan ve sorgu logları eski kolonlara hiçbir şeyin başvurmadığını doğruladıktan sonra onları silin:

ALTER TABLE users DROP COLUMN legacy_id;
ALTER TABLE users DROP COLUMN user_id;

Yıkıcı adım yine gerçekleşiyor — ama riskli kod değişikliğinden iki release sonra, uygulamanın rollback'i artık o kolonların varlığına bağlı olmadığında.

Temel ilke:

  • Her şema değişikliği, çalışan release ile geriye dönük uyumlu olmalı
  • N-1 sürümü N şemasıyla çalışmalı — rollback sözleşmesi budur
  • Bir şeyi kullanmayı bırakan release'te asla silme ya da yeniden adlandırma yapmayın

Config de blue ile green arasında aynı paylaşılan-durum sorununu yaşar — ona da çarptık: blue-green config kayması.

Ders: Veritabanı blue-green'in en zor parçasıdır, çünkü ne blue'dur ne green — paylaşılandır. Migrasyonlarını açıkça planlayın; uygulama açılışına sonradan iliştirilmiş bir ayrıntı olarak değil, deployment otomasyonunun bir parçası olarak.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #Deployment #BlueGreen #Veritabanı #Migrasyon