Aracılığıyla paylaş

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

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

Bu makalede, yerel yedeklilik aracılığıyla kullanılabilirlik ve bölgesel yedeklilik aracılığıyla yüksek kullanılabilirlik sağlayan, Azure SQL Veritabanı ve Fabric'teki SQL veritabanı mimarisi açıklanmaktadır.

Overview

Azure SQL Veritabanı ve Fabric'teki SQL veritabanı, Windows işletim sistemindeki SQL Server Veritabanı Motoru'nun tüm geçerli düzeltme ekleriyle birlikte en son kararlı sürümünde ç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ı'ndaki bir veritabanı veya elastik havuz güncellendiğinde veya yük devredildiğinde, uygulamanızda yeniden deneme mantığını uyguladığınızda kapalı kalma süresi etkilenmez. 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ın aşağıdaki gibi kesintileri ele almasını sağlar:

  • Müşteri tarafından başlatılan ve kısa bir kapalı kalma süresiyle sonuçlanan yönetim işlemleri
  • Hizmet bakım işlemleri
  • Konuyla 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 üzerinde en az etkiye sahip olmasını 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 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 . Yerel depolama modeli, her zaman kullanılabilir bir çoğunlukta veritabanı motoru düğümünün bulunması 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:

Hizmet katmanı Yüksek kullanılabilirlik modeli Yerel olarak yedekli kullanılabilirlik Bölge yedekli erişilebilirlik
Genel Amaçlı (vCore) Uzak depolama alanı Yes Yes
İş Açısından Kritik (vCore - sanal çekirdek) Yerel depolama Yes Yes
Hiper Ölçek (sanal çekirdek) Hyperscale Yes Yes
Temel (DTU) Uzak depolama alanı Yes No
Standart (DTU) Uzak depolama alanı Yes No
Üst Düzey (DTU) Yerel depolama Yes Yes

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ına genel bakış ve sanal çekirdek tabanlı satın alma modelinin Genel Amaçlı hizmet katmanı, hem sunucusuz hem de sağlanan işlem için uzak depolama kullanılabilirlik modelini kullanır. Aşağıdaki diyagramda, ayrılmış işlem ve depolama katmanlarına sahip düğümler gösterilmektedir.

İşlem ve depolama ayrımını gösteren diyagram.

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

  • Durumsuz bir işlem katmanı olan veritabanı motoru işlemini çalıştırır ve yalnızca ekli SSD'deki tempdb ve model veritabanları gibi geçici ve önbelleğe alınmış verileri içerir, aynı zamanda bellekte plan önbelleği, arabellek havuzu ve sütun deposu havuzunu barındırır. 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.

  • Azure Blob Depolama'da depolanan veritabanı dosyaları (.mdf ve .ldf) ile durum bilgisine sahip bir veri katmanı. Azure Blob Depolama yerleşik veri kullanılabilirliği ve yedeklilik özelliklerine sahiptir. Veritabanı motoru işlemi çökse bile, günlük dosyasındaki veya veri dosyasındaki 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.

Veritabanı altyapısı düğümleri kümesinin diyagramı.

Altta yatan veritabanı dosyaları (.mdf/.ldf), iş yükünüz için çok düşük gecikme süreli GÇ sağlamak amacıyla bağlı 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 her zaman tam olarak eşitlenmiş bir çoğaltma ile yedekleme yapılmasını garanti eder. Yük devretme işlemi, Azure Service Fabric tarafından başlatılır. İkincil bir çoğaltma yeni birincil çoğaltma olduğunda, kümenin yeter sayıyı korumak için yeterli sayıda çoğaltmaya sahip olmasını sağlamak amacıyla başka bir ikincil çoğaltma oluşturulur. Yük devretme tamamlandıktan sonra Azure SQL bağlantıları otomatik olarak yeni ana çoğaltmaya veya okunabilir yardımcı ç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çekleme adı verilir. Birincil replika üzerindeki analitik iş yükleri gibi salt okunur işlemleri taşımak için ek ücret ödemeden %100 ek işlem kapasitesi sağlar.

Hiper ölçekli hizmet katmanı

Hiper Ölçek hizmet katmanı mimarisi, ayrıntılı bir diyagramı olan Dağıtılmış işlevler mimarisinde açıklanmıştır.

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

  • Durum bilgisiz bir hesaplama katmanı olan, veritabanı altyapısını çalıştıran, yalnızca geçici ve önbelleğe alınmış veriler içeren bir yapı olup, ekli SSD'de RBPEX önbelleği, tempdb ve model veritabanları gibi öğeleri bulundurur; bellekte ise plan önbelleği, arabellek havuzu ve sütun deposu havuzunu barındırır. Bu durum bilgisi olmayan katman, birincil işlem çoğaltmasını ve isteğe bağlı olarak yük devretme hedefleri olarak işlev görebilecek 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.

  • İşlem günlüğü depolama katmanı; 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 bulunan bir yapı içerir. 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.

Bölgeler arası yedeklilik aracılığıyla yüksek kullanılabilirlik

Alanlar arası yedekli dağıtımlar için Azure SQL Veritabanı, belirli bir bölgedeki Azure kullanılabilirlik alanlarının sayısını (genellikle iki veya daha fazla üç) kullanır. İşlem ve depolama bileşenleri, Azure SQL tarafından en iyi dayanıklılık için seçilen iki veya üç bölgeye, bağımsız güç, soğutma ve ağ ile ayrı fiziksel konumlarda yer alır. Azure SQL, bölgesel kullanılabilirlik ve hizmet iyileştirmesine göre bölge sayısını otomatik olarak seçer. Dağıtımınız, dayanıklılığı sağlamak için gerekli olandan daha az bölge kullanmaz.

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ı, bölge yedekliliğini farklı şekillerde uygularken, Azure bölgesindeki tek bir kullanılabilirlik alanı kullanılamaz hale gelirse, tüm uygulamalar yük devretme sırasında taahhüt edilen verilerin kaybının sıfır olduğu bir Kurtarma Noktası Hedefi (RPO) sağlar.

Azure SQL, dağıtımınız için bölge yerleşimini otomatik olarak iyileştirir. İki veya üç bölge kullanan tüm kullanılabilirlik alanı yapılandırmaları aynı yüksek kullanılabilirlik SLA'sını ve dayanıklılık garantilerini sağlar.

Genel Amaçlı hizmet katmanı

Genel Amaçlı hizmet katmanı için, sanal çekirdek satın alma modelindeki veritabanları için hem sunucusuz hem de ayrılmış işlemde alan yedekliliğine sahip yapılandırma sunulmaktadır. 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ı birincil bölgedeki birden çok Azure kullanılabilirlik alanına zaman uyumlu olarak kopyalanır. Bu, Azure SQL tarafından en iyi dayanıklılık için seçilen iki veya üç bölgededir.
  • sqlservr.exe işlemini çalıştıran ve yalnızca bağlı SSD'deki tempdb ve model veritabanları gibi geçici ve önbelleğe alınmış verileri içeren, bellekte önbellek planını, arabellek havuzunu ve columnstore havuzunu tutan durumsuz bir işlem katmanı. Azure Service Fabric tarafından çalıştırılan bu durum bilgisi olmayan düğüm, sqlservr.exe'i başlatır, düğümün sistem durumunu denetler ve gerekirse başka bir düğüme yük devretmesini gerçekleştirir. Bölge yedekli sunucusuz ve sağlanan Genel Amaçlı veritabanları için, yedek kapasiteye sahip düğümler failover (yük devretme) durumunda diğer Erişilebilirlik Bölgelerinde kolayca kullanılabilir.

Genel Amaçlı hizmet katmanı için yüksek kullanılabilirlik mimarisinin alanlar arası yedekli sürümü, iki bölgeli veya üç bölgeli bir bölgede aşağıdaki diyagramlar tarafından gösterilmiştir:

İki bölgeli bölge Üç bölgeli bölge
İki bölgeli bir bölgede Genel Amaçlı alanlar arası yedekli yapılandırma diyagramı. Üç bölgeli bir bölgede Genel Amaçlı bölge yedekliliği yapılandırma diyagramı.

  • İşlem iki kullanılabilirlik alanında sağlandığında:

    • Yedekleme ve depolama hala bölgedeki üç kullanılabilirlik alanında eşitlenir.
    • Alanlar arası yedekli depolama her zaman olduğu gibi üç kullanılabilirlik alanında eşitlenir.

  • İşlem üç kullanılabilirlik alanında sağlandığında:

    • Yedekleme ve depolama, bölgedeki üç kullanılabilirlik alanında eşitlenir.

  • Kullanılabilirlik alanı olan tüm Azure bölgeleri, alanlar arası yedekli Genel veritabanlarını destekler.

  • Alanlar arası yedekli kullanılabilirlik için, varsayılandan farklı bir bakım penceresi şu anda belirli bölgelerde kullanılabilir durumdadır. Daha fazla bilgi için bkz. Azure SQL Veritabanı için bölgeye göre bakım penceresi kullanılabilirliği.

  • 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 aktif hale getirildiğinde, kopyalar aynı bölgedeki farklı kullanılabilirlik alanlarında 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.

İş Açısından Kritik hizmet katmanı için yüksek kullanılabilirlik mimarisinin alanlar arası yedekli sürümü, iki bölgeli veya üç bölgeli bir bölgede aşağıdaki diyagramlar tarafından gösterilmiştir:

İki bölgeli bölge Üç bölgeli bölge
İki bölgeli bir bölgedeki İş Açısından Kritik hizmet katmanı için Alanlar arası yedekli yapılandırma diyagramı. Üç bölgeli bir bölgede İş Açısından Kritik hizmet katmanı için Alanlar arası yedekli yapılandırma diyagramı.

  • İşlem iki kullanılabilirlik alanında sağlandığında:

    • İş Açısından Kritik depolama için, veriler ve günlük dosyaları için yerel olarak yedekli kullanılabilirlik depolama alanı iki kullanılabilirlik alanında eşitlenir.
    • Diğer katmanlar için yedekleme ve depolama, bölgedeki üç kullanılabilirlik alanında eşitlenir.
    • Alanlar arası yedekli depolama her zaman olduğu gibi üç kullanılabilirlik alanında eşitlenir.

  • İşlem üç kullanılabilirlik alanında sağlandığında:

    • İş Açısından Kritik depolama için, veriler ve günlük dosyaları için yerel olarak yedekli kullanılabilirlik depolama alanı üç kullanılabilirlik alanında eşitlenir.
    • Diğer katmanlar için yedekleme ve depolama, bölgedeki üç kullanılabilirlik alanında eşitlenir.

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

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.

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. Azure SQL Veritabanı'nda Hiper Ölçek elastik havuzlara genel bakış.

Aşağıdaki diyagramlar, iki bölgeli veya üç bölgeli bir bölgede alanlar arası yedekli Hiper Ölçek veritabanları için temel mimariyi gösterir:

İki bölgeli bölge Üç bölgeli bölge
İki bölgeli yedekli Hiper Ölçek veritabanlarının temel mimarisini gösteren diyagram. Üç bölgeli yedekli Hiper Ölçek veritabanlarının temel mimarisini gösteren diyagram.

  • İşlem iki kullanılabilirlik alanında sağlandığında:

    • Yedekleme ve depolama, bölgedeki üç kullanılabilirlik alanında eşitlenir.
    • Alanlar arası yedekli depolama her zaman olduğu gibi üç kullanılabilirlik alanında eşitlenir.

  • İşlem üç kullanılabilirlik alanında sağlandığında:

    • Yedekleme ve depolama, bölgedeki üç kullanılabilirlik alanında eşitlenir.

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

  • Kullanılabilirlik alanına sahip tüm Azure bölgeleri, alanlar arası yedekli Hiper Ölçek veritabanını destekler.

  • 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 bir Hyperscale veritabanının bölge yedekli yapılandırmasını güncelleştirmek için Veritabanı kopyasını, belirli bir noktaya geri yüklemeyi veya bir coğrafi çoğaltma oluşturmayı kullanın. 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 şu anda belirli bölgelerde kullanılabilir durumdadır. Daha fazla bilgi için bkz. Azure SQL Veritabanı için bölgeye göre bakım penceresi kullanılabilirliği.

  • Ş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`

  • Hyperscale için bölge yedekli yapılandırmayı etkinleştirmek için en az bir yüksek kullanılabilirlik işlem çoğaltması ve bölge yedekli veya coğrafi bölge yedekli yedekleme depolama alanı kullanılması gerekir.

Veritabanı bölgesi yedekli kullanılabilirliği

Azure SQL Veritabanı'nda, 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ını bölge yedekli yapmak, zaman uyumsuz bir işlemdir ve arka planda tamamlanması biraz zaman alacaktı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. Azure SQL Veritabanınızı alanlar arası yedeklilik kullanacak şekilde geçirmek için Azure SQL Veritabanı'nı kullanılabilirlik alanı desteğine geçirme bölümünde yer alan adımları izleyin.

Veritabanının ZoneRedundantmaster özelliğini denetlemek için Azure PowerShell'i, Azure CLI'yı veya Azure SQL Veritabanı kullanılabilirlik alanı durumunu doğrulama altındaki REST API adımlarını kullanın.

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 Yüksek kullanılabilirlik ve olağanüstü durum kurtarma denetim listesi - Azure SQL Veritabanı'nı gözden geçirin.

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

Dağıtım türü PowerShell REST API Azure CLI Portal (Önizleme)
Database Invoke-AzSqlDatabaseFailover Veritabanı yedekleme az rest , Azure CLI'dan REST API çağrısı çağırmak için kullanılabilir Ayarlar > Bakımı > Yeniden Başlat
Elastik havuz Invoke-AzSqlElasticPoolFailover Elastik havuz yük devretme az rest , Azure CLI'dan REST API çağrısı çağırmak için kullanılabilir Ayarlar > Bakımı > Yeniden Başlat

Important

Yük Devretme komutu, Hyperscale veritabanlarının okunabilir ikincil çoğaltmaları için mevcut değildir.

Conclusion

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.

Sonraki adım

Azure SQL Veritabanı kullanılabilirlik alanı desteğine geçirme

İlgili içerik

  • Last updated on