Ağ üzerinde düşük duruş süresi olan büyük bir SQL Server veritabanını geçirmenin en iyi yolu

Problem tanımı

Veritabanımızın başka bir veri merkezine aktarılması gerekiyor. Microsoft SQL Server 2012 Enterprise'da (64-bit) çalışır ve yaklaşık 2TB ve 1TB olmak üzere iki veritabanı içerir.

Bunun için hiçbir kesinti veya hiç kesinti olmazsa ideal olur.

İş yoğunluğu

Bu veritabanları bir .NET web sitesi için kullanılır ve sürekli güncellenmektedir.

Hafta sonu boyunca mevcut olmamak olsa da kabul edilebilir. Halen kullanılmakta olan DB, yenisine geçene kadar kullanımda olan tek kişi kalacaktır.

Bu anahtar, yalnızca DB'nin güncellenmediğinden emin olarak yeni DB sunucusuna işaret edecek şekilde DNS girişlerini değiştirerek ideal olarak yapılabilir.

Ayrıca, bu işlem tarafından geçen zaman, bir sunucudan diğerine geçişin (kapalı kalma süresi) düşük tutulduğu sürece önemli değildir.

Yaklaşılan yaklaşımlar

• Yedekleme ve geri yükleme

  Bu geçmişte yapıldı, ancak dahili bir ağ üzerinden yapılmasına rağmen, Internet'ten çok daha verimli bir şekilde yüksek bir kesinti

• Günlük nakliye

  Anladığım kadarıyla, bu yaklaşım bir ana / köle yapılandırarak ve ana DB'nin tam bir kopyasını yalnızca okunan kölesine aktararak arıza süresini en aza indirir. Yukarıda bahsedildiği gibi, köleye erişim gerekli olmayacaktır ve yalnızca veri tabanı bozulmadan ana DB'nin bir kopyasına sahip olmak için bir yola ihtiyacımız var.

  Ayrıca kaynak kullanımı açısından oldukça verimli görünüyor ve ana performansın çoğunu etkilemeyecek gibi görünüyor.

  Bu yaklaşım konusunda yanılmış olabilirim, bu yüzden beni düzeltmekten çekinmeyin.

• Veri tabanı yansıtma

  Bu yaklaşımın farkında değilim, ancak geçerli bir seçenek gibi görünüyor. Gerçek zamanlı senkronizasyona gerek yoktur ve master'ın performansı oldukça önemlidir, bu nedenle eğer bu yaklaşımın seçilmesi gerekiyorsa, asenkronize olması gereken yoldur.

• Diğer seçenekler?

  Bu sunucu doğrudan çıplak metal donanım üzerinde çalışıyor, bu nedenle düşük seviye çözümler ne yazık ki seçenek değil. Belki bunu yapmanın daha iyi bir yolu vardır?

Kısıtlamalar

Açıklandığı gibi, bu veritabanları bakımı zor olan noktalara göre oldukça büyük ama bu başka bir sorun.

SQL Server sürümleri aynı olacaktır (Microsoft SQL Server 2012 Enterprise 64-bit).

Büyük olasılıkla İnternet üzerinden iki veri merkezi arasında ağ üzerinden aktarılması gerekecektir. İlk senkronizasyon için bir siteden diğerine disklerin gönderilmesi maalesef bir seçenek değildir. Aktarma için bir tür güvenlik güvencesi olması ideal olacaktır, ancak bu durumu en iyi şekilde yapacağız.

Bu, bu görev için ihtiyaçlarımıza oldukça iyi bir genel bakış sağlamalı ve umarım bazılarınız daha önce bu durumla yüzleşmeliydi.

Düz yedekleme ve geri yükleme açıktır. Ben de herhangi bir şekilde çoğaltmayı düşünmezdim.

Veritabanını yansıtma kurulumu oldukça basittir ancak iki sunucu arasında gerçek zamanlı bağlantı, ortakların ve uç noktaların kurulması vb. Gerektirir. aynı WSFC’nin üyeleri olarak, yani her ikisinin de aynı alanda olması gerektiği anlamına gelir. Bu, bir veri merkezi hareketi için tipik bir kurulum değildir (veya geçici olarak çalışmak için bile yapılabilir).

Benim oyum kütük nakliyesi için olurdu. Bununla ilgili güzel bir şey, şu anda aldığınız yedekleri ve günlük yedeklemelerini kullanabilmenizdir (doğru mu?) Ve iki veritabanı arasında gerçek zamanlı bir bağlantı kurmanız gerekmez - her biri hakkında bilgi sahibi olmaları gerekmez. diğeri, yansıtma, ortaklar, güvenlik vb. için uç noktaları ayarlamanıza gerek yoktur. Dosyaları eski sunucudan yeni sunucuda geri yüklenebilecekleri bir yere getirmenin bir yolunu bulmanız yeterlidir. Önceden tam bir yedekleme yapabilir, yeni sunucuya devredebilir, geri yükleyebilir, sonra bu noktadan itibaren kesme aşamasına kadar artımlı günlük yedeklemeleri uygulayabilir (muhtemelen farklılık gösterir ve). Bu süreç aslında oldukça basittir ve herhangi bir zorluk yaşarsanız, çevrimiçi günlük sevkıyatı hakkında birçok öğretici eğitim vardır.

Web uygulaması veritabanıyla birlikte hareket ediyorsa, DNS'nin yayılması biraz zaman alabileceğinden, eski uygulamanın bağlantı dizelerinde, yazılabilir olduklarında yeni veritabanı sunucusunun IP'sini göstermelerini sağlamak için bir geçiş yapmak isteyebilirsiniz. , çünkü - anahtardan sonra bile ve TTL ayarlarınız sıkı olsa bile - istemciler eski web sunucularına ulaşmaya devam edebilir. Hepsi, sağlayıcılarının TTL’lerinize ne kadar saygı gösterdiğine bağlıdır.

Son zamanlarda yansıtma kullanarak 6 veritabanında 15 tb geçirdim. Çok basit ve birkaç saniyede yerine çalışma süresi ile mükemmel çalıştı.

Düzenlemeler:

İki yeni sanallaştırılmış SQL Sunucum vardı. Veritabanları, henüz geliştirdikleri 3 sunucudan geliyordu ve üzerinde barındırılan daha küçük veri tabanları üzerindeki performansı etkiliyordu.

İşlem çok basitti.

1. Tam yedeklemenin tamamlanmasını bekleyin.
2. Yeni sunuculara kurtarma yapmadan geri yükleme
3. Bu geri yükleme işlemleri tamamlandığında yedekleri duraklatın
4. Orijinal olmayanlardan en son günlük yedeklemesine kadar bir ek geri yükleme yapın, kurtarmaya gerek kalmadan
5. Altıda bir yansıtmaya başla
6. Yedeklemeleri sürdür

Ağ üzerindeki yükü azaltma konusunda başarısız olana kadar onları eşzamansız modda bırakmayı tercih ettim. bunu doğru bul. Manuel yük devretmeden önce senkronize moda geçmeleri gerekir.

Bir sonraki bakım penceresi boyunca her veritabanı üzerinde manuel olarak başarısız oldum ve bazı duman testlerinden sonra, yansıtmayı kapattım ve sonunda eski veri dosyalarını kaynak sunuculardan kaldırdım. Bu süreçte ilginç olan şey, yansıtılmış bir veritabanında başarısız olmanın eski primerin iyileşme durumunda kalmasıdır, bu yüzden onları rahat bırakmadığınız sürece, onları tekrar çevrimiçi hale getirmeniz ve ayırmanız veya tercih ettiğiniz kaldırma yöntemi ne olursa olsun . Ayrıca, bunların hiçbirine şahitlik yapmadım çünkü otomatik yerine çalışma istemiyordum. Bu kontrollü bir olaydı.

Daha fazla bilgi isterseniz lütfen bana bildirin. Sunucu ve ağ özelliklerini dışarıda bıraktım ancak istersen sağlayabilirim.

Teşekkürler