Soru SQL Server felaket kurtarma için SAN Çoğaltma / Anlık Görüntüleri Kullanma?


Tek bir veritabanı sunucusunda SQL Server 2008 kullanan bir web uygulamasına sahibiz. Tüm depolama yereldir. Geçtiğimiz yıl için, yapılandırmamızla birlikte çalışmak üzere herhangi bir SQL Server Çoğaltma formu almaya çalışıyorduk, ancak olmayacak. Bunun nedeni, sürekli olarak güncellenmekte olan 2000'den fazla veritabanımızın (her birimiz için bir tane) var olmasıdır, bu nedenle testlerimiz tüm çoğaltma biçimlerinin çok kaynak yoğun olduğunu göstermektedir.

Bu soruyu her sorduğumda, insanlar çok fazla veritabanımız olduğu gerçeğine odaklanıyor. Bu, değişemeyen bir şeydir (düzenleyici ve diğer nedenlerle), bu yüzden verileri nasıl kopyalayabileceğimize odaklanmak isterim.

Bir seçeneğin tüm verileri bir SAN'ye taşımak ve SAN'ın verileri kopyalamasını (ya da sık sık anlık görüntü almasını) söylememiz söylendi. Ancak, bizim veritabanı sunucumuz başarısız olursa, bu durumda bozuk bir veritabanı riski var mı? İyi bir DR çözümü sağlamak için başka bir SAN'a çoğaltılmış olan SAN'tan yararlanmak mümkün mü (bizim durumumuzda, yaklaşık 30 dakikalık veri kaybettik, ancak tüm bir günün değerini kaybedemeyiz ... yani yapabiliriz) Bir önceki gecenin yedeğine gitme).


7
2017-08-15 18:36


Menşei


Brent Ozar'ın sitesinde bu konuda iyi şeyler var: brentozar.com/archive/2011/12/... - squillman


Cevaplar:


Diğer cevaplarda da belirtildiği gibi:

  • Eski stil veritabanı yansıtma ve yeni stil AlwaysOn iş parçacığı gerektirir ve 2000 veritabanları ile kesinlikle iş parçacığı biter. Pratik sınırın 200 veritabanının çok altında olduğunu hatırlıyorum. (Bu bir yerde bir beyaz kağıt var, ama şu anda bunu aramak için çok tembelim ve bu cevap zaten çok uzun.) Tabii ki, bu örnekte 200 veri tabanı. Teorik olarak, 20 örnek başlatabilir ve her örnekte 100 veritabanı çalıştırabilirsiniz. Tüm bunları yönetmek bir güçlük olurdu ve tüm bu örnekler arasındaki hafızayı yönetmenin baş ağrısının olacağını sanıyorum.

  • SQL Server çoğaltması (dosyalar yerine çoğaltma tabloları (veya alt kümeler)) gerçekten DR için tasarlanmamıştır. Birkaç veritabanında bile, kurulması ve yönetilmesi zor. Veri modelinizi çalışmaya başlamak için değiştirmeniz gerekebilir. Bu, uygulamanızda değişiklikler anlamına gelebilir. Aynı çoğaltma yapılandırmasını, 2000 (muhtemelen aynı veya hemen hemen aynı) veritabanlarınızın her birine uygulamak için otomatik bir yönteme gerek duyarsınız. Çoğaltmayı yapılandırmak için kullanmanız gereken saklı yordamlar dağınıktır. GUI aracılığıyla çoğaltma için yapılandırılmış 2000 veritabanlarını yönetmek bir kabus olurdu. Yük devretme / yüklediğinizde, her şeyin yeniden çalışmasını sağlamak için değişiklikler yapmanız gerekebilir. Yük devretme süresi, herhangi bir hassas değişiklik yapmak istediğinizde ya da önleyebileceğiniz bir iş değildir. Her şeyi geri almak ve ASAP'ı çalıştırmak istiyorsun. Sadece bir sürü problem gibi görünüyor.

  • SAN depolama birimleri arasında çoğaltma, özellikle EMC gibi bir kıyafetden bahsediyorsanız, pahalı olabilir. Bir satıcıyla başladığınızda, yükseltmeler, bakım, ek alan vb. İçin onlarla oldukça evlisiniz.

Öneri # 1:Steeleye'ın DataKeeper'ı gibi bir şeye baktın mı? Sunucularınızda Windows Yük Devretme Kümelemesi'nden yararlanan, yazılım tabanlı bir çoğaltma ürünüdür. Asla kullanmadım ve birkaç köpek ve pony şovuyla oturmaktan başka şirkete hiç bir bağlantım yok. Durumunuz için ideal görünüyor.

Öneri # 2: Eğer ben olsaydım ve kesinlikle hiçbir bütçem olsaydı, evde yetiştirilen günlük nakliye sistemine bakardım. Yerleşik günlük sevkiyatın 2000 veri tabanını çok iyi ele alacağından şüphe duyuyorum. Bir günlük nakliye sistemi yazmak o kadar da zor değildir ve ortamınıza özgü tüm sorunları ele alabilir. (Örneğin, dosyaları sftp aracılığıyla DR sitenize göndermeniz gerekebilir.)

Temel olarak, sisteme üç bölüm vardır. Her bölümün düzenli bir program üzerinde çalışması gerekir:

  • Bir bölüm, işlem günlüğü yedeklerini alır ve her bir veritabanı için tlog yedek dosyalarını farklı bir klasöre (dosya sistemi ölçeklendirmesi için) ekler. Bakım sihirbazını bunun için kullanmam, çok fazla kazandığını gördüm ve veritabanlarını atlamaya başladım ve genelde yanlış davranıyordum. 30 dakikalık bir garanti vermek isterseniz, belki bu her 15 dakikada bir çalışır.

  • Bir bölüm, yedekleme dosyalarını hazırlama alanından DR sitenize kopyalar. Bu, DR'nize VPN'niz varsa, bir robocopy CMD dosyası kadar basit bir şey olabilir. Eğer bir şeye ihtiyaç duyarsanız, bir paket veya bir powershell betiği yazabilirsiniz (sftp veya ssh / scp veya dahili bir sıkıştırmanız yoksa zip / unzip). Bu, herşeyi aldığından emin olmak için daha hızlı, belki her 5 dakikada bir koşabilir. Bir şey bir yerden kopyalandığında, "güvenli" dir.

  • Bir bölüm, DR sitesinde bulduğu tlog yedeklemelerini ikincil sunucunuza geri yükler. Geri yüklenen tlog'ları tanımladığınızdan emin olun ve bunları bir programda silmeniz ya da silmeniz ya da sonunda alanınız tükenecektir. Bu sık sık çalıştırılmaya ihtiyaç duymaz, ancak bir sorun olduğunda DR ikincil "canlı" olarak bildirilmeden önce mevcut tüm yedeklemelerin çalıştırıldığından emin olmanız gerekir.

Her üç adımı denetleyen tablolar istersiniz, neler olduğunu gösteren bazı raporlar / komut dosyaları (birincil veya ikincil sitenizde çalışan belirli bir veritabanı var mı? İkincil üzerinde herhangi bir veritabanı yok, iki saat içinde bir geri yükleme geri yükleme görüldü değil mi?) ) ve bir uyarı şeması.

Bunun da ötesinde, yük devretmek ve her şeyi yük devretmek için belirli bir veritabanını seçebilmek istiyorum. Yük devretme için bir db seçebilmek kolay test etmenizi sağlar (bir müşteri veritabanını değil, bir test veritabanını yüklersiniz) ve sorun gidermeye başlarsanız size temel bir yük dengeleme düzeni verebilir. Ayrıca, birincil ve ikincil arasında "yeniden senkronize etme" (otomatik olarak tam yedeklemeyi al ve ikincile uygula, akan bilgi akışını başlat, vb.) İçin otomatik bir yol da isteyeceksin. Bu özellikler bir sürüm 2.0 için daha iyi olabilir.

(Herkes MS'in desteklediği en eski gönderi gönderiminin SQL 7.0'da indirebileceğiniz ve çalıştırabileceğiniz birkaç betik aracılığıyla gerçekleştirildiğini unutmuştu. GUI oldu, UI bazı SQL raporları ve birkaç saklı yordamdı.)

Biraz tsql kodu yazmanın dışında, buradaki zorluklar:

  • Tam kurtarma modeline (basit kurtarma modelinde çalışmakta olduğunuzu kastediyor) ve kayıt yedeklemelerinde, günlük veritabanı yedeklemelerinde, artmış veritabanı boyutlarında olabilecek artışlarda.

  • Depolama sisteminizin sık tako yedeklemelerinin yüklenmesine ve bunları bir DR sitesine zamanında kopyalanabildiğinden emin olun. IOW, 2000 veritabanına sahipseniz ve veriyi son saate kadar güvence altına almak istiyorsanız, bu 2000 veritabanının her birinin bir işlem günlüğü yedeğini almanız ve ağa bağlı depolamaya (birincil sunucunuzda olmayan bir yere) erişmeniz gerekir. ).

  • Her şeyin genel olarak devam ettiğinden emin olmak.

Tüm bu çalışmayı tamamladıktan sonra, yük devretme işlemini otomatikleştirmeye, belirli bir müşterinin veritabanının canlı sürümünün bulunduğu web sitelerini nasıl söyleyeceğime bakmaya başlıyorum. Kümelenmiş sistemleri çalıştırmıyorsanız, Tüm oturum açma / şifreleri, işleri, bağlantılı sunucuları, vb.


6
2017-08-16 14:12





Evet, veritabanının bozulma şansı var, kutu güç kaybettiyse aynıdır ("çökme tutarlılığı" nız var).

NASIL veritabanı motorları çok fazla önlem alır. Veritabanınızdaki verileri her değiştirdiğinizde "Bir değişiklik yapacağım" yazıyor, sonra değişiklik yapıyor, "Değişimi yaptım" diyor. Ayrıntı düzeyi, nasıl kurulacağına bağlıdır, ancak günlükleri (ne yapmak istediği) tekrarlayarak neredeyse tutarlı bir duruma geri dönebilirsiniz.

Bu, veri kaybetmeyeceğiniz anlamına gelmez, sadece doğru olanın ne olduğu anlamına gelir.

Muhtemelen bu durumda ne istiyorsunuz (10 dakika ya da her neyse geri dönerseniz binlerce dolar kaybetmeyeceğinizi varsayarak) ASYNCHRONOUS çoğaltma (uzak depolama tarafından kabul edilmek için veritabanına yazma işlemlerini beklemek istemezsiniz) ). En yaygın depolama sistemlerinde "her X dakikada bir anlık görüntü" diyebilirsiniz ve siz de ayarlanacaksınız.

Son olarak, bu% 100 değil - hala geleneksel yedeklemeler yapmanız gerekiyor. Ama oldukça güvenilir. Bu kurulum çok yaygın ve sanal makinelerin yanı sıra veritabanları ile iyi çalışıyor.

Daha fazla bilgi için niyet günlükleri, oynatma, günlük nakliye, yüksek su işareti ve tutarlılık kontrol noktaları göz atın.


3
2017-08-15 18:45





Bu kesinlikle yapılabilir, bunu yapmanın ücretsiz bir yolunun farkında değilim ama kullanıyoruz BU, temelde MSSQL kutusunun dosyalarını gizlemesine izin verir, sonra 3Par dizisinin bir araya gelmesi gerektiğini söyler - bu da içsel olarak tutarlı ve daha sonra devam eder. Ardından dizi çırpışını alır ve istediğiniz kadar çok alana sahip olmanızı sağlar - gerçekçi olarak sadece 24 saat ya da öylesine söylemek istersiniz, böylece onları sadece bu temelde bırakırsınız. Özgür olmaktan çok uzak olduğumdan, her seferinde% 100 çalışıyor ve özellikle bu türden bir şey için tasarlandı. NetApp'ın benzer / özdeş bir şey yaptığına eminim - Sadece bu ürünü üzgün değilim.


2
2017-08-15 19:08



Bildiğim NetApp eşdeğeri (ve muhtemelen bilmediğim başkaları var) SnapMirror. - Andrew


Evet, yolsuzluk ihtimali var. Kısa sürüm: Bir kilitlenmeden sonra, SQL veri bütünlüğünüzü doğrulamak için işlem günlüklerini tekrarlar. Günlük dosyaları bozuksa, veritabanlarınız şüpheli olarak işaretlenir. (Fazlası var İşte.)

Çoğaltma için gelince: günlük gönderi, muhtemelen en iyi bahistir gibi geliyor. 30 dakika kaybederseniz, muhtemelen (veritabanlarının büyüklüğüne ve ne kadar meşgul olduklarına bağlı olarak) otuz dakikalık pencereniz için her 10 dakikada bir 1/3 gemi olabilirsiniz. (Diğer bir deyişle, çökme durumunda, veritabanlarının 1 / 3'ü 10 dakika, başka bir üçüncü 20, ve başka bir üçüncü 30 olur.)


1
2017-08-15 20:38





Benzer bir uygulama üzerinde çalıştım. Çok müşterili bir uygulama değil, çok müşteriymişiz. Emdi.

Veritabanlarını birden çok SQL sunucusuna bölmeyi deneyebilirsiniz, böylece çalışan iş parçacığı kalmazsınız veya yansıtma / çoğaltma / günlük gönderiminde diğer darboğazlardan birine girebilirsiniz.

SQL 2012'de AlwaysOn'a baktım ve 2008'de çalışan iş parçacığı için yansıtılan aynı gereksinimlerden etkilenmiş gibi görünüyor, dolayısıyla yükseltme size yardımcı olmayacaktır.

Sorguladığınız gibi depolama katmanı çoğaltmayı deneyebilirsiniz. Bende çok fazla tecrübem yok.


1
2017-08-15 21:42