Azure SQL Yönetilen Örneği ile iş sürekliliğine genel bakış

  • Makale

Şunlar için geçerlidir: Azure SQL Yönetilen Örneği

Bu makalede Azure SQL Yönetilen Örneği iş sürekliliği ve olağanüstü durum kurtarma özelliklerine genel bir bakış sağlanmaktadır ve veri kaybına neden olabilecek ya da örneğinizle uygulamanızın kullanılamaz duruma gelmesine neden olabilecek kesintiye neden olan olaylardan kurtarmaya yönelik seçenekler ve öneriler açıklanmaktadır. Bir kullanıcı veya uygulama hatası veri bütünlüğünü etkilediyse, Azure kullanılabilirlik alanında veya bölgesinde kesinti olduğunda veya uygulamanız bakım gerektirdiğinde ne yapacağınızı öğrenin.

Genel bakış

Azure SQL Yönetilen Örneği iş sürekliliği kullanılabilirlik, yüksek kullanılabilirlik ve olağanüstü durum kurtarma sağlayarak işletmenizin kesintiler karşısında çalışmaya devam edebilmesini sağlayan mekanizmalar, ilkeler ve yordamları ifade eder.

Çoğu durumda, SQL Yönetilen Örneği bulut ortamında gerçekleşebilecek kesintiye neden olan olayları işler ve uygulamalarınızı ve iş süreçlerinizi çalışır durumda tutar. Ancak, azaltmanın biraz zaman alabileceği bazı kesintiye neden olan olaylar vardır, örneğin:

  • Kullanıcı tablodaki bir satırı yanlışlıkla siler veya güncelleştirir.
  • Kötü amaçlı saldırgan verileri başarıyla siler veya veritabanını bırakır.
  • Yıkıcı doğal afet olayı bir veri merkezini veya kullanılabilirlik bölgesini veya bölgesini ele geçirir.
  • Yapılandırma değişikliği, yazılım hatası veya donanım bileşeni hatasının neden olduğu nadir veri merkezi, kullanılabilirlik alanı veya bölge genelinde kesinti.

Kullanılabilirlik

Azure SQL Yönetilen Örneği, bunu yazılım veya donanım hatalarına karşı koruyan temel dayanıklılık ve güvenilirlik vaatleriyle birlikte gelir. Veritabanı yedeklemeleri, verilerinizi bozulmaya veya yanlışlıkla silinmeye karşı korumak için otomatikleştirilir. Hizmet olarak Platform (PaaS) olarak Azure SQL Yönetilen Örneği hizmeti, %99,99 oranında sektör lideri kullanılabilirlik SLA'sı ile kullanıma açık bir özellik olarak kullanılabilirlik sağlar.

Yüksek Kullanılabilirlik

Azure bulut ortamında yüksek kullanılabilirlik elde etmek için alanlar arası yedekliliği etkinleştirin; böylece örnek, bölgesel hatalara dayanıklılık sağlamak için kullanılabilirlik alanlarını kullanır. Birçok Azure bölgesi, bağımsız güç, soğutma ve ağ altyapısına sahip bir bölgedeki veri merkezlerinin ayrılmış grupları olan kullanılabilirlik alanları sağlar. Kullanılabilirlik alanları, bir bölgede kesinti yaşanması durumunda kalan bölgelerde bölgesel hizmetler, kapasite ve yüksek kullanılabilirlik sağlamak üzere tasarlanmıştır. Alanlar arası yedekliliği etkinleştirerek, örnek bölgesel donanım ve yazılım hatalarına dayanıklıdır ve kurtarma uygulamalar için saydamdır. Yüksek kullanılabilirlik etkinleştirildiğinde, Azure SQL Yönetilen Örneği hizmeti %99,99 daha yüksek kullanılabilirlik SLA'sı sağlayabilir.

Olağanüstü durum kurtarma

Bölgeler arasında daha yüksek kullanılabilirlik ve yedeklilik elde etmek için olağanüstü durum kurtarma özelliklerini etkinleştirerek örneği olağanüstü bir bölgesel hatadan hızla kurtarabilirsiniz. Azure SQL Yönetilen Örneği ile olağanüstü durum kurtarma seçenekleri şunlardır:

  • Yük devretme grupları , birincil ve ikincil örnek arasında sürekli eşitlemeyi etkinleştirir. Yük devretme grupları değişmeden kalan okuma-yazma ve salt okunur dinleyici uç noktaları sağlar, bu nedenle yük devretme sonrasında uygulama bağlantı dizesi güncelleştirilmesi gerekmez.
  • Coğrafi geri yükleme , herhangi bir Azure bölgesindeki mevcut örneklerde yeni bir veritabanı oluşturarak birincil bölgedeki veritabanınıza erişemiyorsanız coğrafi olarak çoğaltılan yedeklemelerden geri yükleyerek bölgesel bir kesintiden kurtarmanıza olanak tanır.

İş sürekliliği sağlayan özellikler

Örneğin, dört büyük olası kesinti senaryosu vardır. Aşağıdaki tabloda, olası iş kesintisi senaryolarını azaltmak için kullanabileceğiniz SQL Yönetilen Örneği iş sürekliliği özellikleri listelenmiştir:

İş kesintisi senaryosu İş sürekliliği özelliği
Veritabanı düğümünü etkileyen yerel donanım veya yazılım hataları. Yerel donanım ve yazılım hatalarını azaltmak için SQL Yönetilen Örneği, %99,99'a kadar kullanılabilirlik SLA'sı ile bu hatalardan otomatik kurtarmayı garanti eden bir kullanılabilirlik mimarisi içerir.
Veri bozulması veya silme işlemi genellikle bir uygulama hatası veya insan hatası nedeniyle oluşur. Bu tür hatalar uygulamaya özgü olup genellikle hizmet tarafından algılanamaz. İşletmenizi veri kaybına karşı korumak için SQL Yönetilen Örneği otomatik olarak haftalık tam veritabanı yedeklemeleri, 12 veya 24 saatte bir değişiklik veritabanı yedeklemeleri ve 5-10 dakikada bir işlem günlüğü yedeklemeleri oluşturur. Varsayılan olarak, yedeklemeler yedi gün boyunca coğrafi olarak yedekli depolamada depolanır ve 35 güne kadar belirli bir noktaya geri yükleme için yapılandırılabilir yedekleme saklama süresini destekler. Silinen veritabanını, örnek silinmediyse veya uzun süreli saklamayı yapılandırdıysanız silindiği noktaya geri yükleyebilirsiniz.
Doğal afet olayı, yapılandırma değişikliği, yazılım hatası veya donanım bileşeni hatasından kaynaklanan nadir veri merkezi veya kullanılabilirlik alanı kesintisi. Veri merkezi veya kullanılabilirlik alanı düzeyi kesintisini azaltmak için, SQL Yönetilen Örneği'nin Azure Kullanılabilirlik Alanları kullanması ve bir Azure bölgesi içindeki birden çok fiziksel bölgede yedeklilik sağlaması için alanlar arası yedekliliği etkinleştirin. Bölge yedekliliğini etkinleştirmek, yönetilen örneğin %99,99'a kadar yüksek kullanılabilirlik SLA'sı ile bölgesel hatalara dayanıklı olmasını sağlar.
Büyük olasılıkla yıkıcı bir doğal afet olayından kaynaklanan, tüm kullanılabilirlik alanlarını ve onu oluşturan veri merkezlerini etkileyen nadir bölge kesintisi. Bölge genelindeki bir kesintiyi azaltmak için aşağıdaki seçeneklerden birini kullanarak olağanüstü durum kurtarmayı etkinleştirin:
- Yük devretme için kullanılan ikincil bir bölgedeki çoğaltmalara yük devretme gruplarıyla sürekli veri eşitleme.
- Coğrafi geri yükleme kullanmak için yedekleme depolama yedekliliğini coğrafi olarak yedekli yedekleme depolamaya ayarlama.

RTO ve RPO

İş sürekliliği planınızı geliştirirken, uygulama kesintiye neden olan olaydan sonra tam olarak kurtarılmadan önce kabul edilebilir en uzun süreyi anlayın. Bir uygulamanın tam olarak kurtarılması için gereken süre, Kurtarma Süresi Hedefi (RTO) olarak bilinir. Ayrıca, planlanmamış kesintiye neden olan bir olaydan kurtarılırken uygulamanın kaybetmeye dayanabileceği en son veri güncelleştirmelerinin (zaman aralığı) en uzun süresini de anlayın. Olası veri kaybı Kurtarma Noktası Hedefi (RPO) olarak bilinir.

Aşağıdaki tabloda, her bir iş sürekliliği seçeneğinin RPO ve RTO'sunu karşılaştırır:

İş sürekliliği seçeneği RTO (kapalı kalma süresi) RPO (veri kaybı)
Yüksek Kullanılabilirlik
(Alanlar arası yedeklilik kullanma)		 Genellikle 30 saniyeden kısa 0
Olağanüstü Durum Kurtarma
(Müşteri tarafından yönetilen yük devretme ilkesiyle yük devretme gruplarını kullanma)		 Genellikle 60 saniyeden kısa 0'a eşit veya 0'dan
büyük (Çoğaltılmış olmayan kesintiye neden olan olaydan önceki veri değişikliklerine bağlıdır)
Olağanüstü Durum Kurtarma
(Coğrafi geri yükleme kullanma)		 12 saat 1 saat

İş sürekliliği denetim listeleri

Kullanılabilirliği en üst düzeye çıkarmak ve daha yüksek iş sürekliliği elde etmek için aşağıdakilere bakın:

Aynı Azure bölgesindeki bir veritabanını kurtarma

Veritabanını geçmişteki bir noktaya geri yüklemek için otomatik veritabanı yedeklemelerini kullanabilirsiniz. Bu şekilde, insan hatalarından kaynaklanan veri bozulmalarını kurtarabilirsiniz. Belirli bir noktaya geri yükleme (PITR), aynı örneğe veya bozuk olaydan önceki verilerin durumunu temsil eden farklı bir örneğe yeni bir veritabanı oluşturmanıza olanak tanır. Geri yükleme işlemi, hedef örneğin geçerli iş yüküne de bağlı olan bir veri işlemi boyutudur. Çok büyük veya çok etkin bir veritabanını kurtarmak daha uzun sürebilir. Kurtarma süresi hakkında daha fazla bilgi için bkz . veritabanı kurtarma süresi.

Belirli bir noktaya geri yükleme (PITR) için desteklenen en uzun yedekleme saklama süresi uygulamanız için yeterli değilse, veritabanları için uzun süreli saklama (LTR) ilkesi yapılandırarak bunu genişletebilirsiniz. Daha fazla bilgi için bkz . Uzun süreli yedekleme saklama.

Veritabanını var olan bir örneğe kurtarma

Nadir olsa da Azure veri merkezinde kesinti olabilir. Kesinti yaşandığında yalnızca birkaç dakika sürebilecek veya saatler alacak bir hizmet kesintisi söz konusu olabilir.

  • Bir seçenek, veri merkezi kesintisi sona erdiğinde örneğinizin yeniden çevrimiçi olmasını beklemektir. Bu, veritabanlarının çevrimdışı olmasını göze alabilen uygulamalar için çalışır. Örnek olarak üzerinde sürekli çalışma yapmadığınız bir geliştirme projesi veya ücretsiz deneme sürümü verilebilir. Bir veri merkezinde kesinti olduğunda, kesintinin ne kadar sürebileceğini bilemezsiniz, bu nedenle bu seçenek yalnızca veritabanınıza bir süre ihtiyacınız yoksa çalışır.
  • Coğrafi olarak yedekli (GRS) veya coğrafi alanlar arası yedekli (GZRS) depolama kullanıyorsanız, bir diğer seçenek de coğrafi olarak yedekli veritabanı yedeklemeleri (coğrafi geri yükleme) kullanarak veritabanını herhangi bir Azure bölgesindeki SQL yönetilen örneğine geri yüklemektir. Coğrafi geri yükleme kaynağı olarak coğrafi olarak yedekli bir yedekleme kullanır ve bir kesinti nedeniyle veritabanı veya veri merkezine erişilemez olsa bile veritabanını kullanılabilir son noktaya kurtarmak için kullanılabilir. Kullanılabilir yedekleme eşleştirilmiş bölgede bulunabilir.
  • Son olarak, örneğiniz için bir yük devretme grubu kullanarak müşteri (önerilen) veya Microsoft tarafından yönetilen yük devretme kullanarak coğrafi olarak ikincil bir grup yapılandırdıysanız, kesintiden hızla kurtulabilirsiniz. Yük devretmenin kendisi yalnızca birkaç saniye sürerken, hizmetin yapılandırıldıysa Microsoft tarafından yönetilen coğrafi yük devretmeyi etkinleştirmesi en az 1 saat sürer. Bu, yük devretmenin kesintinin ölçeğine göre gerekçelendirildiğinden emin olmak için gereklidir. Ayrıca yük devretme, eşleştirilmiş bölgeler arasındaki zaman uyumsuz çoğaltmanın doğası gereği yakın zamanda değiştirilen verilerin kaybolmasına neden olabilir.

İş sürekliliği planınızı geliştirirken, uygulamanın kesintiden sonra tamamen kurtarılmasına kadar kabul edilebilen maksimum süreyi anlamanız gerekir. Uygulamanın tam olarak kurtarılması için gereken süre, Kurtarma Süresi Hedefi (RTO) olarak bilinir. Ayrıca, planlanmamış kesintiye neden olan bir olaydan kurtarılırken uygulamanın kaybetmeyi tolere edebildiği en son veri güncelleştirmelerinin (zaman aralığı) maksimum süresini de anlamanız gerekir. Olası veri kaybı Kurtarma Noktası Hedefi (RPO) olarak bilinir.

Farklı kurtarma yöntemleri farklı RPO ve RTO düzeyleri sunar. Belirli bir kurtarma yöntemi seçebilir veya tam uygulama kurtarması elde etmek için yöntemlerin bir bileşimini kullanabilirsiniz.

Uygulamanız şu ölçütlerden herhangi birini karşılıyorsa yük devretme gruplarını kullanın:

  • Görev açısından kritikse.
  • 12 saat veya daha fazla kapalı kalma süresine izin vermeyen bir hizmet düzeyi sözleşmesi (SLA) vardır.
  • Kapalı kalma süresi mali sorumlulukla sonuçlanabilir.
  • Yüksek veri değişikliği oranına sahiptir ve 1 saatlik veri kaybı kabul edilemez.
  • Etkin coğrafi çoğaltma ek maliyeti, olası mali yükümlülükten veya ilgili iş kaybından daha düşükse.

Uygulama gereksinimlerinize bağlı olarak veritabanı yedeklemeleri ve yük devretme gruplarının bir birleşimini kullanmayı seçebilirsiniz.

Aşağıdaki bölümlerde, veritabanı yedeklemelerini veya yük devretme gruplarını kullanarak kurtarma adımlarına genel bir bakış sağlanır.

Kesinti için hazırlanma

Kullandığınız iş sürekliliği özelliğinden bağımsız olarak aşağıdaki adımları uygulamanız gerekir:

  • Ağ IP güvenlik duvarı kuralları, oturum açma bilgileri ve veritabanı düzeyi izinleri dahil olmak üzere hedef örneği tanımlayın ve master hazırlayın.
  • İstemcilerin ve istemci uygulamalarının yeni örneğe nasıl yönlendirileceğini belirleme
  • Denetim ayarları ve uyarılar gibi diğer bağımlılık belgelerini oluşturmak

Düzgün bir şekilde hazırlanmazsanız, yük devretme veya veritabanı kurtarma işleminden sonra uygulamalarınızı çevrimiçi duruma getirmek ek zaman alır ve büyük olasılıkla stres anında sorun giderme gerektirir. Bu, kötü bir birleşimdir.

Coğrafi olarak çoğaltılmış ikincil örneğe yük devretme

Kurtarma mekanizmanız olarak yük devretme gruplarını kullanıyorsanız, otomatik bir yük devretme ilkesi yapılandırabilirsiniz. Yük devretme işlemi başlatıldıktan sonra, ikincil örneğin yeni birincil, yeni işlemleri kaydetmeye ve sorgulara yanıt vermeye hazır olmasına neden olur ve henüz çoğaltılmayan veriler için en az veri kaybı olur.

Not

Veri merkezi yeniden çevrimiçi olduğunda, eski birincil otomatik olarak yeni birincile yeniden bağlanarak ikincil örnek olur. Birincil dosyayı özgün bölgeye geri taşımanız gerekiyorsa, planlı bir yük devretmeyi el ile başlatabilirsiniz (yeniden çalışma).

Coğrafi geri yükleme gerçekleştirme

Coğrafi olarak yedekli depolama (örneğinizi oluştururken varsayılan depolama seçeneği) ile otomatik yedeklemeler kullanıyorsanız coğrafi geri yükleme kullanarak veritabanını kurtarabilirsiniz. Kurtarma genellikle 12 saat içinde gerçekleşir ve son günlük yedeklemesinin alındığı ve çoğaltıldığı zaman tarafından belirlenen bir saate kadar veri kaybı olur. Kurtarma işlemi tamamlanana kadar veritabanı işlem kaydedemez ve sorgulara yanıt veremez. Coğrafi geri yüklemenin veritabanını yalnızca kullanılabilir son noktaya geri yükleyişine dikkat edin.

Not

Uygulamanızı kurtarılan veritabanına geçirmeden önce veri merkezi yeniden çevrimiçi olursa kurtarma işlemini iptal edebilirsiniz.

Yük devretme/kurtarma sonrası görevleri gerçekleştirme

Bu iki kurtarma sisteminden herhangi biriyle gerçekleştirilen kurtarma işleminden sonra kullanıcılarınızın ve uygulamalarınızın çalışmaya devam etmesi için aşağıdaki ek görevleri gerçekleştirmeniz gerekir:

  • İstemcilerin ve istemci uygulamalarının yeni örneğe ve geri yüklenen veritabanına nasıl yönlendirileceğini belirleyin.
  • Kullanıcıların bağlanması için uygun ağ IP güvenlik duvarı kurallarının geçerli olduğundan emin olun.
  • Uygun oturum açma bilgilerinin ve master veritabanı düzeyinde izinlerin bulunduğuna (veya kapsanan kullanıcıları kullandığınızdan) emin olun.
  • Denetimi uygun şekilde yapılandırın.
  • Uyarıları uygun şekilde yapılandırın.

Not

Bir yük devretme grubu kullanıyorsanız ve okuma-yazma dinleyicisini kullanarak örneğe bağlanıyorsanız, yük devretmeden sonra yeniden yönlendirme otomatik olarak ve şeffaf bir şekilde uygulamaya gerçekleşir.

Lisanssız DR çoğaltmaları

Yalnızca olağanüstü durum kurtarma (DR) için ikincil bir Azure SQL Yönetilen Örneği yapılandırarak lisanslama maliyetlerinden tasarruf edebilirsiniz. Bu avantaj, iki SQL yönetilen örneği arasında bir yük devretme grubu kullanıyorsanız veya SQL Server ile Azure SQL Yönetilen Örneği arasında karma bir bağlantı yapılandırdıysanız kullanılabilir. İkincil örneğin üzerinde okuma veya yazma iş yükü olmadığı ve yalnızca pasif bir DR beklemesi olduğu sürece, ikincil örnek tarafından kullanılan sanal çekirdek lisanslama maliyetleri için ücret alınmaz.

Yalnızca olağanüstü durum kurtarma için ikincil bir örnek belirlediğinizde ve örnekte hiçbir okuma veya yazma iş yükü çalışmadığında, Microsoft size yük devretme hakları avantajı kapsamında ek ücret ödemeden birincil örneğe lisanslanan sanal çekirdek sayısını sağlar. İkincil örneğin kullandığı işlem ve depolama için hala faturalandırılırsınız. Karma yük devretme hakları avantajının kesin hüküm ve koşulları için "SQL Server – Yük Devretme Hakları" bölümündeki ÇEVRIMIÇI SQL Server lisanslama koşullarına bakın.

Avantajın adı senaryonuza bağlıdır:

Aşağıdaki diyagramda her senaryonun avantajı gösterilmektedir:

Azure SQL Yönetilen Örneği yük devretme haklarını karşılaştıran diyagram.

Sonraki adımlar

İş sürekliliği özellikleri hakkında daha fazla bilgi edinmek için bkz . Otomatik yedeklemeler ve yük devretme grupları. Olağanüstü durum kurtarma için bkz. veritabanını kurtarma ve Azure SQL Yönetilen Örneği için bölge yedekliliğini etkinleştirme.