Aracılığıyla paylaş

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

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

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ı bir doğal afet, bir veri merkezini veya kullanılabilirlik bölgesini ya da bütün bölgeyi devre dışı bırakır.
  • 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ılabilirliği en üst düzeye çıkarmak ve daha yüksek iş sürekliliği elde etmek için açıklayıcı öneriler için bkz:

Yüksek 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. Azure SQL Yönetilen Örneği hizmeti, Platform olarak hizmet (PaaS) şeklinde %99,99 oranında sektör lideri erişilebilirlik SLA'sı ile hazır bir özellik olarak erişilebilirlik sağlar.

Azure bulut ortamında yüksek kullanılabilirlik elde etmek için alanlar arası yedekliliği etkinleştirin. Alanlar arası yedeklilik sayesinde ö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 kesintisiz senkronizasyona imkan tanır. Yük devretme grupları, okuma-yazma ve salt okunur dinleyici uç noktalarını değişmeden sağlar, bu nedenle yük devretme sonrasında uygulama bağlantı dizelerinin güncellenmesi 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.

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. Olağanüstü durum kurtarmayla ilgili iş gereksinimlerini ölçmenin iki yaygın yolu şunlardır:

  • Kurtarma Süresi Hedefi (RTO):Planlanmamış kesintiye neden olan bir olaydan sonra uygulamanın tam olarak kurtarılması için gereken süre.
  • Kurtarma Noktası Hedefi (RPO):Planlanmamış kesintiye neden olan bir olaydan tolere edilebilecek veri kaybı süresi.

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 ilkesi ile yük devretme gruplarını kullanma)		 Genellikle 60 saniyeden kısa 0'a eşit veya 0'dan büyük
(Kesintiye neden olan olaydan önce yansıtılmamış veri değişikliklerine bağlıdır)
Felaket Sonrası Kurtarma
(Coğrafi geri yükleme kullanarak)		 12 saat 1 saat

İş 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:
- Sürekli veri eşitleme, yük devretme için kullanılan ikincil bir bölgedeki çoğaltmalara yük devretme gruplaşmalarıyla gerçekleştirilir.
- Coğrafi geri yükleme kullanmak için yedekleme depolama yedekliliğini coğrafi yedekli depolama olarak ayarlama.

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 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 yedekli bir yedekleme kullanır ve bir kesinti nedeniyle veritabanı veya veri merkezine erişilemese bile, veritabanını kullanılabilir en son ana kadar kurtarmak için kullanılabilir. Mevcut yedekleme, eşleştirilen bölgede bulunabilir.
  • Son olarak, örneğiniz için bir yük devretme grubu oluştururken coğrafi-yedek kullanarak, müşteri (önerilen) veya Microsoft tarafından yönetilen yük devretme seçeneklerinden biri sayesinde, bir kesinti sonrası hızla toparlanabilirsiniz. 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. Kesinti ölçeğine göre yük devretmenin gerekçeli olmasını sağlamak için bu gereklidir. Ayrıca yük devretme, eşleştirilmiş bölgeler arasındaki asenkron çoğaltmanın doğası gereği son zamanlarda 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 için kritiktir.
  • 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ğaltmanın ek maliyeti, olası mali yükümlülük ve ilgili iş kaybından daha düşüktür.

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. Bir yük devretme işlemi başlatıldığında, ikincil örnek yeni birincil hale gelir, yeni işlemleri kaydetmeye ve sorgulara yanıt vermeye hazır olur ve henüz çoğaltılmamış veriler için minimum veri kaybı yaşanır.

Not

Veri merkezi yeniden çevrimiçi olduğunda, eski birincil otomatik olarak yeni birincile bağlanır ve ikincil örnek haline gelir. 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 veri kaybı, son günlük yedeklemesinin alındığı ve çoğaltıldığı zamana bağlı olarak bir saate kadar olabilir. 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 ve kurtarma işlemi sonrası görevleri yerine getirme

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 replikalar

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. Hibrit 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ü altındaki SQL Server lisanslama koşullarını çevrimiçi olarak inceleyin.

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

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

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

Sonraki adım

Yüksek kullanılabilirlik ve felaket kurtarma kontrol listesi

İlgili içerik

  • Last updated on