Yedeklilik aracılığıyla kullanılabilirlik - Azure SQL Veritabanı

Şunlar için geçerlidir: Azure SQL Veritabanı

Bu makalede, yerel yedeklilik aracılığıyla kullanılabilirlik ve alanlar arası yedeklilik aracılığıyla yüksek kullanılabilirlik elde eden Azure SQL Veritabanı mimarisi açıklanmaktadır.

Genel bakış

SQL Veritabanı, windows işletim sistemindeki SQL Server Veritabanı Altyapısı'nın en son kararlı sürümünde ve tüm geçerli düzeltme ekleriyle çalışır. SQL Veritabanı düzeltme eki uygulama, yedeklemeler, Windows ve SQL altyapısı yükseltmeleri gibi kritik hizmet görevlerini ve temel alınan donanım, yazılım veya ağ hataları gibi planlanmamış olayları otomatik olarak işler. SQL Veritabanı'daki bir veritabanı veya elastik havuza düzeltme eki uygulandığında veya yük devredildiğinde, uygulamanızda yeniden deneme mantığı kullandığınızda kapalı kalma süresi etkili olmaz. SQL Veritabanı, verilerinizin her zaman kullanılabilir olmasını sağlayarak en kritik durumlarda bile hızla kurtarılabilir. Kullanıcıların çoğu yükseltmelerin sürekli olarak gerçekleştirildiğini fark etmez.

varsayılan olarak, Azure SQL Veritabanı yerel yedeklilik aracılığıyla kullanılabilirlik elde eder ve veritabanınızı şu süre boyunca kullanılabilir hale getirir:

• Kısa bir kapalı kalma süresiyle sonuçlanan müşteri tarafından başlatılan yönetim işlemleri
• Hizmet bakım işlemleri
• Ile ilgili sorunlar:
  • hizmetinizi destekleyen makinelerin çalıştığı raf
  • SQL veritabanı altyapısını barındıran fiziksel makine
• SQL veritabanı altyapısıyla ilgili diğer sorunlar
• Diğer olası planlanmamış yerel kesintiler

Varsayılan kullanılabilirlik çözümü, işlenen verilerin hatalar nedeniyle hiçbir zaman kaybolmamasını, bakım işlemlerinin iş yükünüzü etkilememesini ve veritabanının yazılım mimarinizde tek bir hata noktası olmamasını sağlamak için tasarlanmıştır.

Ancak, bir bölgenin tamamında kesinti olması durumunda verileriniz üzerindeki etkiyi en aza indirmek için, alanlar arası yedekliliği etkinleştirerek yüksek kullanılabilirlik elde edebilirsiniz. Alanlar arası yedeklilik olmadan, yük devretmeler aynı veri merkezinde yerel olarak gerçekleşir ve bu da kesinti çözülene kadar veritabanınızın kullanılamaz duruma gelmesine neden olabilir. Kurtarmanın tek yolu, etkin coğrafi çoğaltma, yük devretme grupları veya coğrafi olarak yedekli yedeklemenin coğrafi olarak geri yüklenmesi gibi bir olağanüstü durum kurtarma çözümünden geçer. Daha fazla bilgi edinmek için iş sürekliliğine genel bakışı gözden geçirin.

Üç kullanılabilirlik mimari modeli vardır:

• İşlem ve depolama ayrımını temel alan uzak depolama modeli . Uzak depolama katmanının kullanılabilirliğine ve güvenilirliğine dayanır. Bu mimari bakım etkinlikleri sırasında bir düzeyde performans düşüşünü kaldırabilecek, bütçe odaklı iş uygulamalarını hedefler.
• Veritabanı altyapısı işlemleri kümesini temel alan yerel depolama modeli . Her zaman kullanılabilir veritabanı altyapısı düğümlerinin bir çekirdeği olması gerçeğine dayanır. Bu mimari yüksek GÇ performansına, yüksek işlem hızına sahip görev açısından kritik uygulamaları hedefler ve bakım etkinlikleri sırasında iş yükünüz üzerinde minimum performans etkisi sağlar.
• İşlem düğümleri, sayfa sunucuları, günlük hizmeti ve kalıcı depolama gibi yüksek oranda kullanılabilir bileşenlerden oluşan dağıtılmış bir sistem kullanan hiper ölçek modeli . Hiper Ölçek veritabanını destekleyen her bileşen kendi yedekliliğini ve hatalara karşı dayanıklılığını sağlar. İşlem düğümleri, sayfa sunucuları ve günlük hizmeti, her bileşenin sistem durumunu denetleyen ve kullanılabilir iyi durumdaki düğümlere gerektiğinde yük devretme gerçekleştiren Azure Service Fabric üzerinde çalışır. Kalıcı depolama, yerel yüksek kullanılabilirlik ve yedeklilik özellikleriyle Azure Depolama'yı kullanır. Daha fazla bilgi edinmek için bkz . Hiper Ölçek mimarisi.

Üç kullanılabilirlik modeli içinde SQL Veritabanı yerel yedeklilik ve bölgesel yedeklilik seçeneklerini destekler. Yerel yedeklilik bir veri merkezinde dayanıklılık sağlarken, bölgesel yedeklilik ise bir bölgedeki kullanılabilirlik alanının kesintilerine karşı koruma sağlayarak dayanıklılığı artırır.

Aşağıdaki tabloda hizmet katmanlarına göre kullanılabilirlik seçenekleri gösterilmektedir:

Farklı hizmet katmanları için belirli SLA'lar hakkında daha fazla bilgi için Azure SQL Veritabanı için SLA'yı gözden geçirin.

Yerel yedeklilik aracılığıyla kullanılabilirlik

Yerel olarak yedekli kullanılabilirlik, veritabanınızı yerel olarak yedekli depolamaya (LRS) depolamayı temel alır. Bu depolama, verilerinizi birincil bölgedeki tek bir veri merkezinde üç kez kopyalar ve küçük ölçekli ağ veya güç kesintisi gibi yerel bir hata durumunda verilerinizi korur. LRS, en düşük maliyetli yedeklilik seçeneğidir ve diğer seçeneklere kıyasla en az dayanıklılık sunar. Bir bölgede yangın veya sel gibi büyük ölçekli bir olağanüstü durum oluşursa, LRS kullanan bir depolama hesabının tüm çoğaltmaları kaybolabilir veya kurtarılamaz. Bu nedenle, yerel olarak yedekli kullanılabilirlik seçeneğini kullanırken verilerinizi daha fazla korumak için veritabanı yedeklemeleriniz için daha dayanıklı bir depolama seçeneği kullanmayı göz önünde bulundurun. Bu, hem veri dosyaları hem de yedeklemeler için aynı depolamanın kullanıldığı Hiper Ölçek veritabanları için geçerli değildir.

Yerel olarak yedekli kullanılabilirlik, tüm hizmet katmanlarındaki tüm veritabanlarında ve veri kaybı miktarının sıfır olduğunu gösteren Kurtarma Noktası Hedefi'nde (RPO) kullanılabilir.

Temel, Standart ve Genel Amaçlı hizmet katmanları

DTU tabanlı satın alma modelinin Temel ve Standart hizmet katmanları ve sanal çekirdek tabanlı satın alma modelinin Genel Amaçlı hizmet katmanı, sunucusuz ve sağlanan işlem için uzak depolama kullanılabilirlik modelini kullanır. Aşağıdaki şekil, ayrılmış işlem ve depolama katmanlarıyla dört farklı düğümü gösterir.

Uzak depolama kullanılabilirlik modeli iki katman içerir:

• Veritabanı altyapısı işlemini çalıştıran ve yalnızca ekli SSD'deki ve model veritabanları gibi tempdb geçici ve önbelleğe alınmış verileri içeren ve bellekte önbellek, arabellek havuzu ve columnstore havuzu planlayan durum bilgisi olmayan bir işlem katmanı. Bu durum bilgisi olmayan düğüm, veritabanı altyapısını başlatan, düğümün sistem durumunu denetleen ve gerekirse başka bir düğüme yük devretme gerçekleştiren Azure Service Fabric tarafından çalıştırılır.
• veritabanı dosyalarının (.mdf ve .ldf) Azure Blob Depolama depolandığı durum bilgisi olan bir veri katmanı. Azure Blob Depolama yerleşik veri kullanılabilirliği ve yedeklilik özelliklerine sahiptir. Veritabanı altyapısı işlemi kilitlense bile günlük dosyasındaki veya veri dosyasındaki sayfadaki her kaydın korunacağını garanti eder.

Veritabanı altyapısı veya işletim sistemi yükseltildiğinde veya bir hata algılandığında, Azure Service Fabric durum bilgisi olmayan veritabanı altyapısı işlemini yeterli boş kapasiteye sahip başka bir durum bilgisi olmayan işlem düğümüne taşır. Azure Blob depolamadaki veriler taşıma işleminden etkilenmez ve veri/günlük dosyaları yeni başlatılan veritabanı altyapısı işlemine eklenir. Bu işlem yüksek kullanılabilirliği garanti eder, ancak yeni veritabanı altyapısı işlemi soğuk önbellekle başladığından geçiş sırasında ağır bir iş yükü biraz performans düşüşü yaşayabilir.

Premium ve İş Açısından Kritik hizmet katmanı

DTU tabanlı satın alma modelinin Premium hizmet katmanı ve sanal çekirdek tabanlı satın alma modelinin İş Açısından Kritik hizmet katmanı, işlem kaynaklarını (veritabanı altyapısı işlemi) ve depolamayı (yerel olarak bağlı SSD) tek bir düğümde tümleştiren yerel depolama kullanılabilirlik modelini kullanır. Hem işlem hem de depolama alanı ek düğümlere çoğaltılarak yüksek kullanılabilirlik elde edilir.

Temel alınan veritabanı dosyaları (.mdf/.ldf), iş yükünüz için çok düşük gecikme süresine sahip GÇ sağlamak için ekli SSD depolama alanına yerleştirilir. Yüksek kullanılabilirlik, SQL Server AlwaysOn kullanılabilirlik gruplarına benzer bir teknoloji kullanılarak uygulanır. Küme, okuma-yazma müşteri iş yükleri için erişilebilen tek bir birincil çoğaltma ve veri kopyalarını içeren en fazla üç ikincil çoğaltma (işlem ve depolama) içerir. Birincil çoğaltma, değişiklikleri ikincil çoğaltmalara sırayla sürekli gönderir ve her işlemi işlemeden önce verilerin yeterli sayıda ikincil çoğaltmada kalıcı olmasını sağlar. Bu işlem, birincil çoğaltmanın veya okunabilir bir ikincil çoğaltmanın herhangi bir nedenle kilitlenmesi durumunda yük devretme için her zaman tam olarak eşitlenmiş bir çoğaltma olmasını garanti eder. Yük devretme, Azure Service Fabric tarafından başlatılır. İkincil çoğaltma yeni birincil çoğaltmaya dönüştüğünde, kümenin çekirdeği korumak için yeterli sayıda çoğaltmaya sahip olduğundan emin olmak için başka bir ikincil çoğaltma oluşturulur. Yük devretme tamamlandıktan sonra Azure SQL bağlantıları otomatik olarak yeni birincil çoğaltmaya veya okunabilir ikincil çoğaltmaya yönlendirilir.

Ek bir avantaj olarak, yerel depolama kullanılabilirlik modeli salt okunur Azure SQL bağlantılarını ikincil çoğaltmalardan birine yeniden yönlendirme özelliğini içerir. Bu özelliğe Okuma Ölçeği Genişletme adı verilir. Birincil çoğaltmadan analitik iş yükleri gibi salt okunur yük dışı işlemlere ek ücret ödemeden %100 ek işlem kapasitesi sağlar.

Hiper ölçekli hizmet katmanı

Hiper Ölçek hizmet katmanı mimarisi Dağıtılmış işlevler mimarisi bölümünde açıklanmıştır.

Hiper Ölçek'teki kullanılabilirlik modeli dört katman içerir:

• Veritabanı altyapısını çalıştıran ve ekli SSD'de RBPEX önbelleği tempdb ve veritabanları gibi yalnızca geçici ve model önbelleğe alınmış veriler içeren ve bellekte önbellek, arabellek havuzu ve sütun deposu havuzunu planlayan durum bilgisi olmayan bir işlem katmanı. Bu durum bilgisi olmayan katman, birincil işlem çoğaltmasını ve isteğe bağlı olarak yük devretme hedefleri olarak görev yapabilecek bir dizi ikincil işlem çoğaltmasını içerir.
• Sayfa sunucuları tarafından oluşturulan durum bilgisi olmayan bir depolama katmanı. Bu katman, işlem çoğaltmalarında çalışan veritabanı altyapısı işlemleri için dağıtılmış depolama altyapısıdır. Her sayfa sunucusu yalnızca bağlı SSD'deki RBPEX önbelleğini ve bellekte önbelleğe alınmış veri sayfalarını kapsayan geçici ve önbelleğe alınmış veriler içerir. Her sayfa sunucusu, yük dengeleme, yedeklilik ve yüksek kullanılabilirlik sağlamak için etkin-etkin yapılandırmasında eşleştirilmiş bir sayfa sunucusuna sahiptir.
• Günlük hizmeti işlemini, işlem günlüğü giriş bölgesini ve işlem günlüğü uzun vadeli depolama alanını çalıştıran işlem düğümü tarafından oluşturulan durum bilgisi olan işlem günlüğü depolama katmanı. Giriş bölgesi ve uzun vadeli depolama, işlem günlüğü için kullanılabilirlik ve yedeklilik sağlayarak işlenen işlemler için veri dayanıklılığı sağlayan Azure Depolama'yı kullanır.
• Azure Depolama'da depolanan ve sayfa sunucuları tarafından güncelleştirilen veritabanı dosyalarının (.mdf/.ndf) yer aldığı durum bilgisi olan bir veri depolama katmanı. Bu katman, Azure Depolama'nın veri kullanılabilirliği ve yedeklilik özelliklerini kullanır. Hiper Ölçek mimarisinin diğer katmanlarındaki işlemler kilitlense veya işlem düğümleri başarısız olsa bile veri dosyasındaki her sayfanın korunacağını garanti eder.

Tüm Hiper Ölçek katmanlarındaki işlem düğümleri, her düğümün durumunu denetleyen ve kullanılabilir iyi durumdaki düğümlere gerektiğinde yük devretme gerçekleştiren Azure Service Fabric üzerinde çalışır.

Hiper Ölçek'te yüksek kullanılabilirlik hakkında daha fazla bilgi için bkz . Hiper Ölçek'te Veritabanı Yüksek Kullanılabilirliği.

Alanlar arası yedeklilik aracılığıyla yüksek kullanılabilirlik

Alanlar arası yedekli kullanılabilirlik, verilerinizin birincil bölgedeki üç Azure kullanılabilirlik alanına yayılmasını sağlar. Her kullanılabilirlik alanı bağımsız enerji, soğutma ve ağ altyapısına sahip olan ayrı bir fiziksel konumu ifade eder.

Alanlar arası yedekli kullanılabilirlik sanal çekirdek tabanlı satın alma modelinin İş Açısından Kritik, Genel Amaçlı ve Hiper Ölçek hizmet katmanlarındaki veritabanları ve DTU tabanlı satın alma modelinin yalnızca Premium hizmet katmanı için kullanılabilir. Temel ve Standart hizmet katmanları bölge yedekliliğini desteklemez.

Her hizmet katmanı alanlar arası yedekliliği farklı bir şekilde uygularken, tüm uygulamalar yük devretme sırasında işlenen veri kaybı sıfır olan bir Kurtarma Noktası Hedefi (RPO) sağlar.

Genel Amaçlı hizmet katmanı

Genel Amaçlı hizmet katmanı için alanlar arası yedekli yapılandırma, sanal çekirdek satın alma modelindeki veritabanları için sunucusuz ve sağlanan işlem için sunulur. Bu yapılandırma, veritabanlarını bir Azure bölgesindeki birden çok fiziksel konuma çoğaltmak için Azure Kullanılabilirlik Alanları kullanır. Alanlar arası yedekliliği seçerek, yeni ve mevcut sunucusuz ve sağlanan genel amaçlı tek veritabanlarınızı ve elastik havuzlarınızı, uygulama mantığında herhangi bir değişiklik yapmadan, yıkıcı veri merkezi kesintileri de dahil olmak üzere çok daha büyük bir hata kümesine dayanıklı hale getirebilirsiniz.

Genel Amaçlı katmanı için alanlar arası yedekli yapılandırma iki katmana sahiptir:

• ZRS'de (alanlar arası yedekli depolama) depolanan veritabanı dosyalarını (.mdf/.ldf) içeren durum bilgisi olan bir veri katmanı. ZRS kullanılarak veriler ve günlük dosyaları fiziksel olarak yalıtılmış üç Azure kullanılabilirlik alanına zaman uyumlu olarak kopyalanır.
• sqlservr.exe işlemini çalıştıran ve yalnızca bağlı SSD'deki ve model veritabanları gibi tempdb geçici ve önbelleğe alınmış verileri içeren ve bellekte önbellek, arabellek havuzu ve columnstore havuzu planlayan durum bilgisi olmayan bir işlem katmanı. Bu durum bilgisi olmayan düğüm, sqlservr.exe başlatan, düğümün sistem durumunu denetleyerek ve gerekirse başka bir düğüme yük devretme gerçekleştiren Azure Service Fabric tarafından çalıştırılır. Alanlar arası yedekli sunucusuz ve sağlanan Genel Amaçlı veritabanları için yedek kapasiteye sahip düğümler yük devretme için diğer Kullanılabilirlik Alanları kullanılabilir.

Genel Amaçlı hizmet katmanı için yüksek kullanılabilirlik mimarisinin alanlar arası yedekli sürümü aşağıdaki diyagramda gösterilmiştir:

Genel Amaçlı veritabanlarınızı alanlar arası yedeklilikle yapılandırırken aşağıdakileri göz önünde bulundurun:

• Genel Amaçlı katman için alanlar arası yedekli yapılandırma aşağıdaki bölgelerde Genel Olarak Kullanılabilir:
  • (Afrika) Güney Afrika Kuzey
  • (Asya Pasifik) Avustralya Doğu
  • (Asya Pasifik) Doğu Asya
  • (Asya Pasifik) Doğu Japonya
  • (Asya Pasifik) Kore Orta
  • (Asya Pasifik) Güneydoğu Asya
  • (Asya Pasifik) Orta Hindistan
  • (Asya Pasifik) Çin Kuzey 3
  • (Asya Pasifik) Kuzey BAE
  • (Avrupa) Orta Fransa
  • (Avrupa) Orta Batı Almanya
  • (Avrupa) kuzey İtalya
  • (Avrupa) Kuzey Avrupa
  • (Avrupa) Doğu Norveç
  • (Avrupa) Orta Polonya
  • (Avrupa) Batı Avrupa
  • (Avrupa) UK Güney
  • (Avrupa) Kuzey İsviçre
  • (Avrupa) İsveç Orta
  • (Orta Doğu) Orta İsrail
  • (Orta Doğu) Orta Katar
  • (Kuzey Amerika) Orta Kanada
  • (Kuzey Amerika) Doğu ABD
  • (Kuzey Amerika) Doğu ABD 2
  • (Kuzey Amerika) Orta Güney ABD
  • (Kuzey Amerika) Batı ABD 2
  • (Kuzey Amerika) Batı ABD 3
  • (Güney Amerika) Güney Brezilya
• Alanlar arası yedekli kullanılabilirlik için, varsayılandan farklı bir bakım penceresi seçmek şu anda belirli bölgelerde kullanılabilir.
• Alanlar arası yedekli yapılandırma yalnızca standart seri (5. Nesil) donanım seçildiğinde SQL Veritabanı kullanılabilir.
• DTU satın alma modelinde Temel ve Standart hizmet katmanlarında alanlar arası yedeklilik kullanılamaz.

Premium ve İş Açısından Kritik hizmet katmanları

Premium veya İş Açısından Kritik hizmet katmanı için Bölge Yedekliliği etkinleştirildiğinde, çoğaltmalar aynı bölgedeki farklı kullanılabilirlik alanlarına yerleştirilir. Tek bir hata noktasını ortadan kaldırmak için denetim halkası da birden çok bölgede üç ağ geçidi halkası (GW) olarak çoğaltılır. Belirli bir ağ geçidi halkasına yönlendirme, Azure Traffic Manager tarafından denetlenilir. Premium veya İş Açısından Kritik hizmet katmanlarında alanlar arası yedekli yapılandırma, farklı kullanılabilirlik alanlarına yerleştirmek için mevcut çoğaltmalarını kullandığından, bunu ek ücret ödemeden etkinleştirebilirsiniz. Alanlar arası yedekli bir yapılandırma seçerek Premium veya İş Açısından Kritik veritabanlarınızı ve elastik havuzlarınızı, uygulama mantığında herhangi bir değişiklik yapmadan yıkıcı veri merkezi kesintileri de dahil olmak üzere çok daha büyük bir hata kümesine dayanıklı hale getirebilirsiniz. Ayrıca mevcut Premium veya İş Açısından Kritik veritabanlarını veya elastik havuzları alanlar arası yedekli yapılandırmaya dönüştürebilirsiniz.

Yüksek kullanılabilirlik mimarisinin alanlar arası yedekli sürümü aşağıdaki diyagramda gösterilmiştir:

Premium veya İş Açısından Kritik veritabanlarınızı alanlar arası yedeklilikle yapılandırırken aşağıdakileri göz önünde bulundurun:

• Alanlar arası yedekli veritabanlarını destekleyen bölgeler hakkında güncel bilgiler için bkz . Bölgeye göre hizmetler desteği.
• Alanlar arası yedekli kullanılabilirlik için, varsayılandan farklı bir bakım penceresi seçmek şu anda belirli bölgelerde kullanılabilir.

Hiper ölçekli hizmet katmanı

Hiper Ölçek hizmet katmanındaki veritabanları için alanlar arası yedekliliği yapılandırmak mümkündür. Daha fazla bilgi edinmek için Alanlar arası yedekli Hiper Ölçek veritabanı oluşturma'yı gözden geçirin.

Bu yapılandırmanın etkinleştirilmesi, tüm Hiper Ölçek katmanları için Kullanılabilirlik Alanları genelinde çoğaltma yoluyla bölge düzeyinde dayanıklılık sağlar. Alanlar arası yedeklilik'i seçerek Hiper Ölçek veritabanlarınızı, uygulama mantığında herhangi bir değişiklik yapmadan yıkıcı veri merkezi kesintileri de dahil olmak üzere çok daha büyük bir hata kümesine dayanıklı hale getirebilirsiniz. Kullanılabilirlik Alanları olan tüm Azure bölgeleri alanlar arası yedekli Hiper Ölçek veritabanını destekler. Hiper Ölçek PRMS ve MOPRMS donanımı için alanlar arası yedeklilik desteği burada listelenen bölgelerde kullanılabilir.

Alanlar arası yedekli kullanılabilirlik hem Hiper Ölçek tek başına veritabanlarında hem de Hiper Ölçek elastik havuzlarında desteklenir. Daha fazla bilgi için bkz . Hiper Ölçek elastik havuzları.

Aşağıdaki diyagramda alanlar arası yedekli Hiper Ölçek veritabanları için temel alınan mimari gösterilmektedir:

Aşağıdaki sınırlamaları göz önünde bulundurun:

• Alanlar arası yedekli yapılandırma yalnızca veritabanı oluşturma sırasında belirtilebilir. Kaynak sağlandıktan sonra bu ayar değiştirilemez. Mevcut hiper ölçek veritabanının alanlar arası yedekli yapılandırmasını güncelleştirmek için Veritabanı kopyasını, belirli bir noktaya geri yüklemeyi kullanın veya coğrafi çoğaltma oluşturun. Bu güncelleştirme seçeneklerinden birini kullanırken, hedef veritabanı kaynaktan farklı bir bölgedeyse veya hedeften veritabanı yedekleme depolama yedekliliği kaynak veritabanından farklıysa, kopyalama işlemi veri işleminin boyutu olur.

• Alanlar arası yedekli kullanılabilirlik için, varsayılandan farklı bir bakım penceresi seçmek şu anda belirli bölgelerde kullanılabilir.

• Şu anda Azure portalını kullanarak veritabanını Hiper Ölçek'e geçirirken bölge yedekliliğini belirtme seçeneği yoktur. Ancak, mevcut bir veritabanı başka bir Azure SQL Veritabanı hizmet katmanından Hiper Ölçek'e geçirildiğinde Azure PowerShell, Azure CLI veya REST API kullanılarak alanlar arası yedeklilik belirtilebilir. Aşağıda Azure CLI ile ilgili bir örnek verilmişti:

  az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`
  

• Hiper Ölçek için alanlar arası yedekli yapılandırmayı etkinleştirmek için en az 1 yüksek kullanılabilirlik işlem çoğaltması ve alanlar arası yedekli veya coğrafi alanlar arası yedekli yedekleme depolama alanı kullanılması gerekir.

Veritabanı bölgesi yedekli kullanılabilirliği

Azure SQL Veritabanı bir sunucu, veritabanları koleksiyonu için merkezi bir yönetim noktası işlevi gören mantıksal bir yapıdır. Sunucu düzeyinde oturum açma bilgilerini, kimlik doğrulama yöntemini, güvenlik duvarı kurallarını, denetim kurallarını, tehdit algılama ilkelerini ve yük devretme gruplarını yönetebilirsiniz. Oturum açma bilgileri ve güvenlik duvarı kuralları gibi bu özelliklerden bazılarıyla ilgili veriler veritabanında master depolanır. Benzer şekilde, sys.resource_stats gibi bazı DMV'lerin verileri de veritabanında depolanırmaster.

Mantıksal sunucuda alanlar arası yedekli yapılandırmaya sahip bir veritabanı oluşturulduğunda, master sunucuyla ilişkili veritabanı da otomatik olarak alanlar arası yedekli hale gelir. Bu, bölgesel bir kesintide, oturum açma bilgileri ve güvenlik duvarı kuralları gibi veritabanına bağımlı master özellikler hala kullanılabilir olduğundan veritabanını kullanan uygulamaların etkilenmemesini sağlar. master Veritabanı alanlar arası yedekli yapmak zaman uyumsuz bir işlemdir ve arka planda tamamlanması biraz zaman alır.

Bir sunucudaki veritabanlarından hiçbiri alanlar arası yedekli olmadığında veya boş bir sunucu oluşturduğunuzda, master sunucuyla ilişkili veritabanı alanlar arası yedekli olmaz.

Veritabanının özelliğini denetlemek ZoneRedundant için Azure PowerShell'i, Azure CLI'yi veya REST API'yi master kullanabilirsiniz:

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

az sql db show --resource-group "myResourceGroup" --server "myServerName" --name master

Uygulama hata dayanıklılığını test edin

Yüksek kullanılabilirlik, veritabanı uygulamanız için saydam bir şekilde çalışan SQL Veritabanı platformunun temel bir parçasıdır. Ancak, planlanmış veya planlanmamış olaylar sırasında başlatılan otomatik yük devretme işlemlerinin uygulamayı üretime dağıtmadan önce nasıl etki edeceğini test etmek isteyebileceğinizi biliyoruz. Veritabanını veya elastik havuzu yeniden başlatmak için özel bir API çağırarak yük devretmeyi el ile tetikleyebilirsiniz. Alanlar arası yedekli sunucusuz veya sağlanan Genel Amaçlı veritabanı veya elastik havuz söz konusu olduğunda, API çağrısı istemci bağlantılarının eski birincilin Kullanılabilirlik Alanı'ndan farklı bir Kullanılabilirlik Alanı'nda yeni birincile yeniden yönlendirilmesine neden olur. Bu nedenle, yük devretmenin mevcut veritabanı oturumlarını nasıl etkilediğini test etmeye ek olarak, ağ gecikme süresindeki değişiklikler nedeniyle uçtan uca performansı değiştirip değiştirmediğini de doğrulayabilirsiniz. Yeniden başlatma işlemi müdahaleci olduğundan ve bunların çok büyük bir kısmı platformu strese atabileceğinden, her veritabanı veya elastik havuz için her 15 dakikada bir yalnızca bir yük devretme çağrısına izin verilir.

Azure SQL Veritabanı yüksek kullanılabilirlik ve olağanüstü durum kurtarma hakkında daha fazla bilgi için HA/DR Denetim Listesi'ni gözden geçirin.

PowerShell, REST API veya Azure CLI kullanılarak yük devretme başlatılabilir:

Sonuç

Azure SQL Veritabanı, Azure platformuyla tümleşik yerleşik bir yüksek kullanılabilirlik çözümüne sahiptir. Hata algılama ve kurtarma için Service Fabric'e, veri koruması için Azure Blob depolamaya ve hataya daha yüksek dayanıklılık için Kullanılabilirlik Alanları bağlıdır. Ayrıca SQL Veritabanı veri eşitleme ve yük devretme için SQL Server'dan Always On kullanılabilirlik grubu teknolojisini kullanır. Bu teknolojilerin birleşimi, uygulamaların karma depolama modelinin avantajlarını tam olarak gerçekleştirmesini sağlar ve en zorlu SLA'ları destekler.

İlgili içerik

Daha fazla bilgi edinmek için şunları gözden geçirin:

• Azure Kullanılabilirlik Alanları
• Service Fabric
• Azure Traffic Manager
• Azure SQL Veritabanı ile iş sürekliliğine genel bakış