Dynamis

Database migration (database migration)

Database migration: planlı tek kesinti

Database migration'da asıl risk süre değil, doğrulanmamış veridir.

Önce veriyi kopyalarız, sonra değişiklikleri CDC ile sürekli aktarırız. Kaynak veritabanı üretimde açık kalır; cutover anında yalnızca son değişiklikler aktarılır. Cutover öncesinde satır sayısını, checksum'ı ve kritik tablolarda alan bazlı karşılaştırmayı yapar, sonucu yazılı raporlarız. Geri dönüş kriterini yazmadan cutover tarihi vermeyiz.

Görüşme PlanlaHemen Ara
  • KesintiYazma bir kez durur
  • Altyapı SLA%99,99
  • Ortalama yanıt süresi<30 dk
  • Müşteri3.000+
15.000+Yönettiğimiz sanal sunucu
%99,99Altyapı SLA, yazılı garanti
<30 dkOrtalama yanıt süresi
7/24Türkçe mühendis, çağrı merkezi yok

Bizi genelde şu altı durumda arıyorlar

  • 01

    Şirket içi SQL Server'ı buluta taşıyacak ekipler

    Donanım ömrünü doldurdu, disk doluyor, yeni sunucu bütçesi çıkmıyor. Aynı veritabanı motorunda kalıp yalnızca altyapıyı değiştirmek istiyorsunuz.

  • 02

    Desteği bitmiş sürümde kalan DBA'ler

    Desteği biten SQL Server sürümü kullanıyorsunuz. Güvenlik yaması artık gelmiyor; bu da denetimde bulgu olarak karşınıza çıkıyor.

  • 03

    Lisans faturasından kurtulmak isteyenler

    Core başına lisans faturası, üzerinde çalıştığı sunucunun maliyetini aşıyor. PostgreSQL'e geçişin ve SPLA üzerinden devam etmenin maliyetini yan yana görmek istiyorsunuz.

  • 04

    Uygulamanız 7/24 çalışıyor, bakım penceresi yok

    E-ticaret, saha operasyonu, ödeme akışı. Sistemi hafta sonu kapatma seçeneğiniz yok; kesintiyi saat değil dakika olarak konuşuyorsunuz.

  • 05

    Migration'ı kendi başlarına deneyip yarıda bırakan ekipler

    Bir kez denediniz, sayılar tutmadı, geri döndünüz. Bu sefer önce prova ortamı, sonra yazılı rollback kriteri istiyorsunuz.

  • 06

    Tek instance'ı bölmeyi planlayan ekipler

    Monolitin altındaki tek instance'ı bölmek, raporlama yükünü ayırmak ya da başka bir veritabanı motoruna geçmek gündeminizde.

Önce envanteri çıkaralım, sonra takvimi

Instance listenizi ve en ağır sorgularınızı gönderin. Bir saatlik görüşmede neyin taşınabileceğini, yazmaların ne kadar süre duracağını ve riskli kalemleri yazılı olarak çıkaralım. +90 312 911 31 27

Görüşme PlanlaHemen Ara

Kapsam: teslim ettiklerimiz

4 kategori · 18 kalem

  • Instance, veritabanı ve şemaların boyutlarıyla birlikte tam envanteri
  • Uygulama bağımlılıkları: connection string, linked server, agent job, SSIS paketi
  • Veritabanı motorunda kullandığınız özellikler: partitioning, FILESTREAM, CLR, Service Broker, trigger
  • Lisans durumu: sürüm, core sayısı, Software Assurance ve SPLA seçenekleri
  • Kaynak kullanım profili: IOPS, gecikme, yoğun saatler ve en ağır 20 sorgu

  • Hedef veritabanı kararı: aynı motorda yükseltme mi, PostgreSQL'e geçiş mi
  • Ölçülen IOPS ve gecikmeye göre compute ve depolama boyutlandırma (right-size)
  • Şema dönüşümü ve uyumsuzluk raporu: tip eşleme ve T-SQL fark listesi
  • Yedekleme, saklama süresi ve felaket kurtarma tasarımı; hedef mimaride RTO 15 dakika ile 4 saat, RPO 1-15 dakika

  • Kaynak sistem üretimde çalışırken ilk yükleme (initial load) ve sıkıştırılmış aktarım
  • CDC ile sürekli replikasyon ve lag takibi
  • Satır sayısı, checksum ve kritik tablolarda alan bazlı karşılaştırma
  • Salt okunur prova ortamı: okuma yolu uygulama testleri ve sorgu planı karşılaştırması
  • Yazılı geri dönüş (rollback) planı ve planı devreye alan eşik değerleri

  • Dakika dakika yazılmış cutover runbook'u ve yazmayı durdurduğumuz planlı pencere
  • Cutover anında doğrulama: replikasyon lag'inin sıfıra inmesi ve son delta kontrolü
  • İki haftalık hypercare: 7/24 Türkçe mühendis, ortalama ilk yanıt 30 dakikanın altında
  • İndeks ve istatistik ayarı; devir dokümanı ile operasyon runbook'unun teslimi

Dört adımda ilerliyoruz

  1. 01

    Envanter ve risk tespiti

    Kapsama göre

    Önce envanteri çıkarırız: instance'lar, bağımlılıklar ve veritabanı motoru özellikleri. Taşınamayacak ya da yeniden yazılması gereken nesneleri bu adımda tek tek adlarıyla listeleriz. Sürpriz sonraya kalmaz.

  2. 02

    Hedef tasarımı ve pilot geri yükleme

    Veri boyutuna göre

    Hedef motora, sürüme ve kaynak boyutuna karar veririz. Gerçek yedekten pilot geri yükleme yaparız; şema uyumsuzluklarını raporlar, en ağır 20 sorgunun planını prova ortamında karşılaştırırız.

  3. 03

    CDC replikasyonu ve doğrulama

    Veri boyutuna göre

    Satır sayısı, checksum ve alan bazlı karşılaştırma kontrollerini tekrarlarız; fark sıfırlanmadan cutover'ı başlatmayız.

  4. 04

    Cutover ve hypercare

    1 gece + izleme

    Planladığımız bakım penceresinde yazma trafiğini durdururuz, kalan deltayı aktarırız, uygulamayı yeni veritabanına bağlarız. Kaynak veritabanını kapatmayız. Sonraki iki hafta performansı ve hataları biz takip ederiz.

İki yol yan yana: kendi ekibiniz ve Dynamis

Çoğu şirketin gerçek alternatifi rakip teklif değil, kendi ekibiyle hafta sonuna sıkıştırdığı dump/restore planıdır. İkisini yan yana koyalım.

  • Kesinti süresi

    Kesinti, dump, aktarım ve restore ne kadar sürerse o kadar uzar. Küçük veritabanları hafta sonuna sığar; terabayt ölçeğindekiler pazartesi sabahına yetişmeyebilir.

    Yazmayı tek seferde, önceden planladığımız pencerede durdururuz. Veriyi cutover'dan önce CDC ile senkron tutar, cutover'da yalnızca son delta'yı kapatırız.

  • Doğrulama

    Uygulama açılıyorsa taşındı sayılır. Eksik satırı haftalar sonra raporda fark edersiniz.

    Satır sayısı, checksum ve kritik tablolarda alan bazlı karşılaştırma. Sonucu yazılı raporlarız.

  • Geri dönüş

    Yeni veritabanına cutover'dan sonra yazılan kayıtlar kaynakta yok; geri dönüş hem veri kaybı hem ikinci bir kesinti demektir.

    Kaynak veritabanı cutover'dan sonra da ayakta kalır. Geri dönüş eşiklerini önceden yazılı olarak belirleriz.

  • Performans

    Yeni ortamda sorgu planları değişir, sorun ilk yoğun iş gününde çıkar.

    Prova ortamında en ağır 20 sorgunun planını karşılaştırıp indeks ve istatistikleri önceden ayarlarız.

  • Cutover sonrası sorumluluk

    Cutover gecesinde görev alan ekip ertesi gün kendi işine döner. Gece 03:00'te arayabileceğiniz kimse kalmaz.

    %99,99 altyapı SLA'i, 7/24 Türkçe mühendis, <30 dk ortalama yanıt ve iki hafta hypercare.

Cutover'dan önce okuyun

Öğrenme Merkezi

Öğrenme Merkezi'nde database migration konusunda henüz yazımız yok. Olmayan bir sayfaya bağlantı vermeyiz. Bu başlıkları yazım sırasına aldık; yayımlandıkça burada görünecekler. Sorunuzu şimdi bir mühendise sormak isterseniz +90 312 911 31 27'yi arayın.

  • SQL Server'dan PostgreSQL'e geçiş: hangi nesneler yeniden yazılır
  • Planlı tek kesintiyle database cutover nasıl yapılır
  • CDC ile veri doğrulama: satır sayısı, checksum ve alan karşılaştırması
  • Database migration öncesi envanter kontrol listesi

Sık sorulanlar

Kalanını 30 dakikalık ücretsiz görüşmede konuşalım.

Yalnızca planladığımız tek yazma penceresi kadar. Veri öncesinde CDC ile aktığı için cutover anında yalnızca son delta kapanır; pencerenin uzunluğu toplam veritabanı boyutuna değil, o andaki yazma trafiğine bağlıdır. Süreyi pilot geri yükleme ve prova ortamı ölçümlerine dayanarak hesaplar, tarihten önce yazılı olarak bildiririz.

Üç önlemle: kaynak veritabanı cutover'dan sonra da açık kalır, replikasyon lag'ini önceden sıfırlarız, rollback eşiklerini o geceden önce yazarız. Doğrulama şu: satır sayısı, checksum ve kritik tablolarda alan bazlı karşılaştırma. Fark varsa cutover başlamaz.

Lisans maliyeti tek başına yeterli gerekçe değil. Stored procedure yoğunluğunuz, CLR ve Service Broker kullanımınız, raporlama araçlarınızın bağımlılıkları geçişin gerçek maliyetini belirler. Envanter adımında yeniden yazılacak nesneleri sayarız; aynı motorda kalmak daha ucuza geliyorsa bunu söyleriz.

Kesinti süresi veri boyutuna bağlı değil; takvim bağlı. CDC çalışırken kaynak sistem üretimde kalır, cutover anında yalnızca son deltayı aktarırız. Takvimi envanter ve pilot geri dönüş testinden sonra yazılı veririz; süreyi veri boyutu ve yeniden yazılacak nesne sayısı belirler.

Evet. Kaynak veritabanını cutover'dan sonra kapatmıyor, hypercare boyunca ayakta tutuyoruz. Hangi metrik hangi eşiği aştığında geri döneceğimiz runbook'ta yazılı; kararı gece tartışmayız. Geri dönüşte cutover'dan sonra yeni veritabanına yazılan kayıtların taşınması gerekir; bu yüzden eşikleri ilk saatlerde izler, kararı geciktirmeyiz.

Software Assurance'ınız varsa mevcut lisansınızı çoğu senaryoda taşıyabilirsiniz. Yoksa SPLA üzerinden aylık kullanım modeli devreye girer. Dynamis Teknoloji yetkili Microsoft SPLA partneridir; envanter adımında iki seçeneğin aylık maliyetini yan yana koyarız.

Geçiş tarihini konuşmadan önce envanteri çıkaralım

Instance listenizi gönderin; taşınabilirlik değerlendirmesini, tahmini kesinti süresini ve riskli kalemleri yazılı olarak gönderelim. Beytepe Mah., Çankaya/Ankara · +90 312 911 31 27

Görüşme PlanlaHemen Ara

Diğer Hizmetlerimiz

İhtiyacınıza uygun diğer çözümleri keşfedin.

Bulut Altyapısı & BT Desteği

Bulutta sunucu, üstüne tam yönetim.

Detay

DevOps Hizmetleri

CI/CD, Kubernetes ve otomasyon: kodu hızla canlıya alın.

Detay

Microsoft SPLA Lisanslama

Windows, SQL, Office: kullandığınız kadar aylık ödeyin.

Detay

Hibrit Bulut

Şirket içi sunucular ve bulut, tek yönetimde.

Detay

Sunucu Yönetim Platformu

Tüm sunucularınız tek panelde, tek bakışta.

Detay