01Sorun ve çözüm
Veritabanı migrasyonu projelerimizde işe kaynak veritabanının envanteriyle başlarız: nesne sayısı, motorun özel özelliklerine bağımlılık, veri hacmi ve günlük değişim miktarı. Şema ve kod dönüşümünü ayrı bir iş kalemi olarak ele alır, verinin aktarımını değişiklik yakalama yöntemiyle kesinti penceresinin dışına taşırız. Geçişten önce her tablo için satır sayısı ve sağlama toplamıyla iki tarafın aynı olduğunu kanıtlarız.
02Kimler için
Veritabanı migrasyonu hizmetine ihtiyaç duyan kuruluşlar
Geçişin nedeni farklı olsa da ortak risk, iş sürekliliğinin bozulmasıdır.
- Lisans maliyeti nedeniyle Oracle veya SQL Server'dan PostgreSQL'e geçmeye karar vermiş şirketler
- Desteği sona ermiş eski bir sürümde kalmış ve büyük sürüm yükseltmesini kesinti korkusuyla erteleyen ekipler
- Kendi sunucusundaki veritabanını Amazon RDS, Azure SQL Database ya da Cloud SQL gibi yönetilen servislere taşımak isteyen işletmeler
- Bir uygulamayı yeniden yazarken eski sistemin verisini yeni şemaya dönüştürerek aktarması gereken yazılım ekipleri
- Birden fazla küçük veritabanını tek bir sunucuda ya da kümede birleştirmek isteyen BT birimleri
03İhtiyaçlar
Motor değişikliğinde gözden kaçan farklar
Aşağıdaki farkların her biri, test edilmeden geçildiğinde canlıda hata olarak ortaya çıkar.
- 01
Veri tipi eşlemeleri
Bir motordaki tarih-saat, ondalık sayı ya da büyük metin tipi diğerinde aynı hassasiyetle karşılanmayabilir. Kuruş farkları ve saat dilimi kaymaları bu eşlemede doğar.
- 02
Saklı yordam ve tetikleyiciler
PL/SQL veya T-SQL ile yazılmış iş mantığı otomatik dönüştürme araçlarıyla ancak kısmen çevrilir. Kalan kısım elle yeniden yazılır ve aynı girdilerle iki tarafta çalıştırılarak sonuçlar karşılaştırılır.
- 03
Harmanlama ve Türkçe sıralama
Büyük-küçük harf duyarlılığı, Türkçe karakterlerin sıralanması ve noktalı-noktasız i dönüşümü motorlar arasında farklı davranır. Arama ve benzersizlik kısıtları bu yüzden ayrıca test edilir.
- 04
Uygulama tarafındaki sorgular
Uygulama kodunda doğrudan yazılmış SQL, motora özgü fonksiyonlar ve sayfalama söz dizimi içerebilir. Bu sorgular taranır ve yeni motora uygun hâle getirilir.
04Özellikler
Veritabanı migrasyonu projesinin aşamaları
Her aşamanın sonunda bir kabul adımı vardır; bir sonraki aşamaya ancak o zaman geçilir.
- 01
Envanter ve uyumluluk analizi
Tablolar, görünümler, yordamlar, işler ve bağlı uygulamalar listelenir; her nesne için otomatik dönüşebilir, elle uyarlanacak ya da yeniden tasarlanacak sınıflandırması yapılır.
- 02
Şema ve kod dönüşümü
Hedef şema oluşturulur, dönüştürülen kod sürüm kontrolüne alınır ve test ortamında uygulamayla birlikte çalıştırılır.
- 03
İlk yükleme ve sürekli eşitleme
Mevcut veri toplu olarak aktarılır, ardından kaynakta olan değişiklikler değişiklik yakalama ile hedefe akmaya devam eder. Böylece iki taraf geçiş gününe kadar eşit tutulur.
- 04
Doğrulama ve prova
Satır sayıları, sağlama toplamları ve kritik raporların çıktıları karşılaştırılır. Geçiş, canlıya benzer bir ortamda en az bir kez baştan sona prova edilir.
- 05
Geçiş ve geri dönüş yolu
Yazma işlemleri kısa süre durdurulur, son değişiklikler aktarılır ve uygulama yeni veritabanına yönlendirilir. Gerekirse ters yönde eşitleme bir süre açık tutularak eski sisteme dönüş imkânı korunur.
05Entegrasyonlar
Taşıma için kullanılan araçlar ve hedefler
Araç seçimi kaynak ile hedef motora ve izin verilen kesinti süresine göre yapılır.
- 01
Değişiklik yakalama araçları
AWS Database Migration Service, Azure Database Migration Service ya da açık kaynak Debezium gibi araçlar sürekli eşitleme için kullanılır.
- 02
Şema dönüştürme araçları
AWS Schema Conversion Tool, ora2pg ya da pgloader gibi araçlar dönüşümün otomatikleşebilen kısmını üstlenir; kalan kısım elle tamamlanır.
- 03
Motorun yerel replikasyonu
Aynı motorun sürüm yükseltmesinde mantıksal replikasyon veya motorun kendi kopyalama özellikleri, ek araç gerektirmeden kesintiyi kısaltır.
- 04
Bağlı uygulamalar ve raporlar
ERP, rapor araçları, entegrasyon servisleri ve zamanlanmış işlerin bağlantı bilgileri envantere alınır; geçiş gününde hepsi planlı sırayla yeni adrese yönlendirilir.
06Süreç
Veritabanı migrasyonu hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Veri kaybı ve uzun kesinti riskini nasıl yönetiyoruz
Geçişin en hassas anı, yazmaların durdurulduğu ve son eşitlemenin beklendiği dakikalardır. Bu pencereyi kısaltmak için ilk yükleme ve eşitleme günler öncesinden başlatılır, geçiş adımları bir senaryo belgesine dökülür ve her adımın sorumlusu ile süresi önceden ölçülür. Senaryoda, hangi koşulda geri dönüleceği de açıkça yazılıdır.
Devamını okuDaha az göster
Taşıma süresince veri şifreli kanallardan aktarılır, kaynak ve hedef veritabanlarına yalnızca bu iş için açılmış, süreli hesaplarla bağlanılır. Geçişten sonra eski sunucu hemen kapatılmaz; yeni sistem kararlı çalıştığı doğrulandığında, eski disklerdeki ve yedeklerdeki kişisel veriler onayınızla güvenli biçimde silinir.
08Çalışma modelleri
Bu hizmette çalışma modelleri
09Sık sorulan sorular
Veritabanı migrasyonu hakkında sık sorulan sorular
Veritabanı migrasyonu fiyatları nasıl belirlenir?
Veri hacmi tek başına belirleyici değildir. Saklı yordam ve tetikleyici sayısı, motor değişikliği olup olmadığı, bağlı uygulama sayısı ve kabul edilebilir kesinti süresi maliyeti asıl etkileyen etkenlerdir. Envanter analizinden sonra sabit kapsamlı teklif veriyoruz.
Taşıma sırasında uygulamamız ne kadar kapalı kalır?
Değişiklik yakalama ile yapılan taşımalarda kesinti genellikle son eşitleme ve bağlantı değişikliği kadardır. Motorun ya da uygulamanın bunu desteklemediği durumlarda, iş takviminize göre planlanmış bir bakım penceresi belirlenir.
Oracle'dan PostgreSQL'e geçişte uygulama kodumuzu değiştirmemiz gerekir mi?
Çoğu zaman kısmen gerekir. Motorun özel fonksiyonlarını kullanan sorgular, sayfalama ve sıralama ifadeleri uyarlanmalıdır. ORM kullanan uygulamalarda değişiklik daha sınırlı kalır.
Verinin eksiksiz taşındığından nasıl emin oluyorsunuz?
Her tablo için satır sayısını ve seçilen sütunlar üzerinden sağlama toplamını iki tarafta karşılaştırırız. Ayrıca ay sonu toplamları gibi iş açısından kritik raporları iki sistemde çalıştırıp sonuçları yan yana koyarız.
Bir sorun çıkarsa eski veritabanına dönebilir miyiz?
Evet. Geçiş planında geri dönüş koşulları ve adımları önceden yazılır. Gerekli görülürse geçişten sonra da yeni sistemden eskisine ters yönlü eşitleme bir süre çalışır, böylece dönüş veri kaybı olmadan yapılabilir.
Veritabanı migrasyonu firması olarak taşıma sonrası destek veriyor musunuz?
Geçişin hemen ardından performans ayarı ve küçük uyarlamalar için bir izleme dönemi planlanır; bu dönemin kapsamı teklifte yazılı olarak belirtilir. Sonrası için ayrı bir bakım ve destek anlaşması yapılabilir.
10İlgili hizmetler