Aracılığıyla paylaş

MySQL için Azure Veritabanı güvenilirliği

MySQL için Azure Veritabanı, veritabanı yönetimi işlevleri ve yapılandırma ayarları üzerinde ayrıntılı denetim ve esneklik sağlamak üzere tasarlanmış tam olarak yönetilen bir veritabanı hizmetidir. Hizmet, gereksinimlerinize göre yüksek kullanılabilirlik ve olağanüstü durum kurtarma özellikleri sağlar.

Azure kullandığınızda, güvenilirlik paylaşılan bir sorumluluktur. Microsoft dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sağlar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede, MySQL için Azure Veritabanı geçici hatalar, kullanılabilirlik alanı kesintileri, bölge kesintileri ve hizmet bakımı gibi çeşitli olası kesintilere ve sorunlara karşı nasıl dayanıklı hale getirilmeye başlandığı açıklanmaktadır. Ayrıca, diğer sorun türlerinden kurtarmak için yedeklemeleri nasıl kullanabileceğinizi açıklar ve MySQL için Azure Veritabanı hizmet düzeyi sözleşmesi (SLA) hakkındaki bazı önemli bilgileri vurgular.

Üretim dağıtımı önerileri

Çözümünüzün güvenilirlik gereksinimlerini desteklemek üzere MySQL için Azure Veritabanı'in nasıl dağıtılacağını ve güvenilirliğin mimarinizin diğer yönlerini nasıl etkilediğini öğrenmek için, Azure Well-Architected Framework'teki MySQL için Azure Veritabanı için mimari en iyi uygulamalarına bakın.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

MySQL için Azure Veritabanı ile çalışırken, veritabanı sunucunuzu desteklemek için gereken işlem ve depolama kaynaklarını temsil eden bir server dağıtırsınız. Sunucuya bir veya daha fazla veritabanı dağıtırsınız.

Sunucuları birden çok işlem katmanında dağıtabilirsiniz: Ani yük artışlarını yöneten Burstable, Genel Amaçlı ve Bellek Optimize Edilmiş; her biri farklı iş yükleri için optimize edilmiştir.

Genel hizmet mimarisi ve dağıtım modelleri hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı nedir?.

Fiziksel mimari

  • İşlem ve depolama ayırma: MySQL için Azure Veritabanı yüksek kullanılabilirliği desteklemek için bir işlem ve depolama ayırma mimarisi kullanır. Veritabanı altyapısı bir sanal makinede çalışır. Veri dosyaları, depolama donanımı hatalarına karşı koruma sağlamak amacıyla verilerin üç kopyasını eşzamanlı olarak tutan Azure Depolama'da depolanır. Sunucunun yüksek kullanılabilirlik yapılandırmasına bağlı olarak, veri dosyaları alanlar arası yedekli depolamada (ZRS) veya yerel olarak yedekli depolamada (LRS) depolanabilir.

  • Yüksek kullanılabilirlik: İsteğe bağlı olarak sunucunuzda yüksek kullanılabilirlik yapılandırmasını etkinleştirebilirsiniz. Yüksek kullanılabilirlik yapılandırmasını etkinleştirdiğinizde, hizmet, sıcak yedek bir sunucu sağlar ve korur. Birincil sunucudaki veri değişiklikleri, birincil sunucu hatası sırasında sıfır veri kaybı sağlamak için bekleme çoğaltma sunucusuna zaman uyumlu olarak çoğaltılır.

    Mimari, işlem katmanını depolama katmanından ayırarak hizmetin farklı hata türlerini uygun şekilde işlemesini sağlar. Daha yüksek dayanıklılık için sunucuları kullanılabilirlik alanlarına yayabilirsiniz.

    Bekleme durumundaki çoğaltma sunucusu, sanal çekirdekler, depolama ve ağ ayarları dahil olmak üzere birincil sunucuyla aynı VM yapılandırmasında dağıtılır.

    Yük devretme gerçekleştirerek sunucular arasında geçiş yapabilirsiniz. İki tür yük devretme vardır: birincil sunucu başarısız olduğunda kullanılan plansız yük devretmeler ve bir yük devretme sırasında uygulama kapalı kalma süresini en aza indirmeniz gereken diğer senaryolarda kullanılan planlı yük devretmeler.

    Daha fazla bilgi için bkz. MySQL için Azure Veritabanı'da kullanılabilirlik.

  • Backups: MySQL için Azure Veritabanı otomatik olarak sunucu yedeklemeleri oluşturur. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Uygulamalarınız bakım, ölçeklendirme işlemleri veya ağ kesintileri sırasında oluşabilecek geçici bağlantı hatalarını işlemelidir. Şu önerileri izleyin:

  • Uygulamanız geçici hatalarla karşılaştığında üstel geri alma kullanarak işlemi yeniden deneyin. Yeniden denemeler arasındaki gecikmeyi artırın ve deneme sayısını sınırlayın. Yeniden deneme sayısı üst sınırından sonra işlem yine başarısız olursa, bunu bir hata olarak kabul edin.
  • Mümkün olduğunda, yeniden denemeleri otomatik olarak işleyen istemci kitaplıklarını kullanın.
  • Yazma işlemleri sırasında meydana gelen geçici hatalar daha dikkatli bir şekilde ele alınmalıdır. Yazma işlemlerinizin idemponent olmasını göz önünde bulundurun, böylece birden çok kez güvenli bir şekilde yürütülebilirler.

Kullanılabilirlik alanı hatalarına dayanıklılık

Availability bölgeleri Azure bölgesindeki fiziksel olarak ayrı veri merkezleri gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

Yüksek kullanılabilirlik yapılandırmasına rağmen kullanılabilirlik alanı desteği türünüzü seçebilirsiniz. Yüksek kullanılabilirliği etkinleştirmek, birincil sunucunuzla birlikte yedek bir çoğaltma sunucusu dağıtır. Bu yüksek kullanılabilirlik modeli, işlenen verilerin hatalar sırasında hiçbir zaman kaybolmamasını sağlamaya yardımcı olur. Hangi yüksek kullanılabilirlik dağıtım modelini seçerseniz seçin, veriler hem birincil hem de yedek kopya sunucularına eşzamanlı olarak taahhüt edilir. Birincil sunucuda bir kesinti oluşursa, sunucu otomatik olarak yedek sunucuya yük devreder.

Veriler Azure Dosyalar premium depolamada depolanır. Sunucunuzun yüksek kullanılabilirlik yapılandırmasına bağlı olarak, ya alanlar arası yedekli depolama ya da kullanılabilirlik alanları içinde veya arasında üç veri kopyası depolayan yerel olarak yedekli depolama (LRS) kullanır.

MySQL için Azure Veritabanı, yüksek kullanılabilirlik kullandığınızda iki kullanılabilirlik alanı yapılandırma türünü destekler:

  • Alanlar arası yedekli yüksek kullanılabilirlik: Bölge yedekliliği, birincil sunucuyu tek bir kullanılabilirlik alanına ve bekleme çoğaltma sunucusunu farklı bir kullanılabilirlik alanına dağıtarak en yüksek düzeyde bölge dayanıklılığı sağlar. Hazır bekleyen çoğaltma sunucusu, birincil sunucuya benzer işlem, depolama ve ağ yapılandırması kullanır. Alanlar arası yedekli yapılandırma, birincil ve hazır bekleyen sunucular arasında yığının tamamının fiziksel yalıtımını sağlar.

    Birincil ve hazır bekleyen sunucular için kullanılabilirlik alanlarını seçersiniz.

    Üretim sunucuları için alanlar arası yedekli dağıtımlar öneririz.

    Hizmet, verileri bekleme sunucusuna zaman uyumlu olarak çoğalttığı için yazma işlemlerinde işlem tamamlama gecikmesinde küçük bir artış yaşanabilir. Ortalama olarak, uygulama yazma ve işleme işlemleri için yüzde 5-10 oranında artan gecikme süresi bekleyebilirsiniz, ancak etki iş yüküne, seçili SKU'ya ve bölgeye göre değişir.

  • Yerel yedekli yüksek kullanılabilirlik: Birincil ve hazır bekleyen sunucular aynı kullanılabilirlik bölgesini kullanır. Birincil sunucuda bir kesinti oluşursa ancak bölge hala iyi durumdaysa, sunucu otomatik olarak hazır bekleyen sunucuya yük devredilir.

    Yerel yedekli dağıtım, tek bir kullanılabilirlik alanında yüksek kullanılabilirlik sağlar. Sizi düğüm seviyesindeki hatalara karşı korur ve planlı veya plansız çalışma kesintisi durumlarında uygulamanın kesinti süresini azaltmaya yardımcı olur. Ancak, bu bölgedeki bir kesintiye karşı korunmaz. Kullanılabilirlik alanları olan bölgelerde, bu tür yapılandırmalar bazen bölgesel veya tek bölgeli olarak da adlandırılır.

    Yerel olarak yedekli yüksek kullanılabilirlik yalnızca belirli senaryolarda önerilir:

    • Olağan dışı gecikme süresine duyarlı uygulamalarınız olduğunda, birincil ve ikincil çoğaltmanız arasındaki gecikme süresini en aza indirme gereksinimini doğrulamış ve diğer mimari yaklaşımları kullanarak bölge dayanıklılığını kendiniz planlamış olursunuz.
    • Kullanılabilirlik alanlarını desteklemeyen bir bölgeye dağıttığınızda, bölge etkili bir şekilde tek bir bölge olarak çalışır ve yerel olarak yedekli yüksek kullanılabilirlik tek yüksek kullanılabilirlik seçeneği olur.

    Sunucular aynı bölgede olduğundan, bu bölge içinde dağıttığınız uygulamalara yazma gecikmesini azaltabilir.

Sunucunuzu yüksek kullanılabilirlik olmadan yapılandırdığınızda tek bir sunucuda çalışır. Bu sunucu veya bölgesi kapanırsa, sunucunuz kullanılamaz.

Gereksinimler

  • Region support: MySQL için Azure Veritabanı'nin kullanılabilirlik alanı yapılandırmaları için desteği Azure bölgeler arasında farklılık gösterir. Bölgelerin tam listesi ve kullanılabilirlik alanı desteği türleri ve bu bölgeyle ilgili belirli noktalar için bkz. Azure bölgeleri.

  • Hizmet katmanı: Yüksek kullanılabilirlik için Genel Amaçlı veya Bellek için İyileştirilmiş katmanlar gerekir. Burstable katmanı yüksek kullanılabilirliği (bölge yedekliliği veya yerel yedeklilik) desteklemez.

Maliyet

Yüksek kullanılabilirliği etkinleştirdiğinizde, hazır bekleyen sunucu oluşturulur ve birincil sunucuyla aynı hızda faturalandırılır. Kullanılabilirlik alanı yapılandırması maliyeti etkilemez. Kullanılabilirlik alanları içinde veya arasında veri çoğaltma için ücret alınmaz. Yedekleme depolama biriminize bağlı olarak, yedekleme depolama alanı için de faturalandırılabilirsiniz. Ayrıntılı fiyatlandırma bilgileri için bkz. MySQL için Azure Veritabanı pricing.

Değerlendirmeler

  • Birincil anahtarlar: Bu yaklaşım çoğaltma ve yük devretme süresini azalttığı için tüm tablolarda birincil anahtarları kullanmanızı öneririz.
  • Sınırlamalar ve bilinen sorunlar:Sınırlamalar ve bilinen sorunlar listesini gözden geçirin.

Kullanılabilirlik alanı desteğini yapılandırma

Bir sunucu için kullanılabilirlik alanı desteğini yapılandırmak için yüksek kullanılabilirlik ayarlarını yapılandırabilirsiniz.

Uyarı

Hangi kullanılabilirlik alanlarını kullanacağınızı seçtiğinizde, aslında mantıksal kullanılabilirlik alanını seçersiniz. Farklı bir Azure aboneliğinde başka iş yükü bileşenleri dağıtırsanız, aynı fiziksel kullanılabilirlik alanına erişmek için farklı bir mantıksal kullanılabilirlik alanı numarası kullanabilirler. Daha fazla bilgi için bkz. Fiziksel ve mantıksal kullanılabilirlik alanları.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde sunucular yüksek kullanılabilirlik ve kullanılabilirlik alanı desteğiyle yapılandırıldığında ve tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Bölgeler arası işlem: MySQL istemci uygulamaları, veritabanı sunucusunun tam etki alanı adını (FQDN) kullanarak birincil sunucuya bağlanır. Yük devretmeler de dahil olmak üzere IP adresi değişebileceğinden birincil sunucunun IP adresini kullanmaktan kaçının.

    MySQL için Azure Veritabanı, tüm veritabanı bağlantılarının ve sorgularının birincil kullanılabilirlik alanındaki birincil sunucu tarafından işlendiği etkin/pasif bir yapılandırma kullanır. Hazır bekleme durumundaki çoğaltma sunucusu, normal işlemler sırasında istemci trafiğine hizmet vermez.

  • Bölgeler arası veri replikasyonu: Yazma işlemleri birincil sunucuda taahhüt edilir ve ZRS kullanılarak bekleme sunucusunun günlüklerine eş zamanlı olarak kaydedilir. Birincil sunucu, bekleme sunucusunun günlükleri uygulamasını beklemez, ancak günlükler ZRS'de olduğu için bir çoğaltma veya bölge hatası oluşsa bile kullanılabilir durumdadır.

    Çoğaltmanın etkileri, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlı olarak farklıdır:

    • Alanlar arası yedekli: Sunucular ayrı bölgelerde olduğundan, bu yaklaşım bölge hatası sırasında sıfır veri kaybı sağlar. Bu durum, bölge hataları için sıfır kurtarma noktası hedefine (RPO) ulaşmak olarak da bilinir.

      Ancak bölgeler arası çoğaltma, az miktarda ek gecikme süresine neden olabilir. Ortalama olarak, uygulama yazma ve işleme işlemleri için yüzde 5-10 oranında artan gecikme süresi bekleyebilirsiniz, ancak etki iş yüküne, seçili SKU'ya ve bölgeye göre değişir.

    • Yerel yedekli: Bölgeler arasında hiçbir trafik çoğaltılmaz.

    Uyarı

    Sistem, tablonun yanlışlıkla silinmesi veya hatalı veri güncellemeleri gibi istenmeyen kullanıcı hataları da dahil olmak üzere tüm değişiklikleri yedek kopya sunucuya gerçek zamanlı olarak çoğaltır. Anlık çoğaltma nedeniyle, kurtarma için yedekleme çoğaltmasını kullanamazsınız. Kullanıcı hatalarından kurtarmak için bir yedeklemeden belirli bir noktaya geri yükleme yapmanız gerekir. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Bölge hatası sırasındaki davranış

Bu bölümde, sunucular yüksek kullanılabilirlik ve kullanılabilirlik alanı desteğiyle yapılandırıldığında ve kullanılabilirlik alanı kesintisi olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Algılama ve yanıt: Azure hem birincil hem de bekleme sunucularının durumunu düzenli aralıklarla denetler. Birden çok ping işleminden sonra, eğer sağlık izleme birincil sunucuya ulaşılamadığını tespit ederse, hizmet bekleme sunucusuna otomatik yük devretme başlatır. Sistem durumu izleme algoritması, hatalı pozitif durumları önlemek için birden çok veri noktası kullanır.

    Bölge hatası durumunda, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlı olarak davranış farklıdır:

    • Zone-redundant: MySQL için Azure Veritabanı birden çok sunucu uç noktasını sürekli izleyerek kullanılabilirlik alanı hatalarını otomatik olarak algılar. Daha fazla bilgi için bkz. HA özellikli sunucularda otomatik yük devretme algılama nasıl çalışır?

      Olası yüksek kullanılabilirlik durum türlerini görüntülemek için bkz. Yüksek kullanılabilirliği izleme. Bir bölge arızalandığında, Azure herhangi bir işlem yapmanıza gerek kalmadan bekleme sunucusuna plansız bir yük devretme başlatır.

    • Yerel olarak yedekli: Yerel olarak yedekli bir sunucuyu barındıran kullanılabilirlik alanı kullanılamaz duruma gelirse hem birincil hem de hazır bekleyen sunucular kullanılamaz. Bu senaryoda, hizmet otomatik yük devretme sağlamaz. Bölge kesintisini algılamaktan ve alanlar arası yedekli yedeklemeleri başka bir kullanılabilirlik alanındaki veya bölgedeki ayrı bir sunucuya geri yükleme gibi kurtarma eylemleri gerçekleştirmek sizin sorumluluğundadır.

  • Notification: Microsoft, bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Ancak, tek bir kaynağın durumunu izlemek için Azure Kaynak Durumu kullanabilir ve sorunları size bildirmek için Kaynak Durumu uyarıları ayarlayabilirsiniz. Ayrıca Azure Hizmet Durumu kullanarak tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlayabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

    MySQL için Azure Veritabanı, planlanmamış bir yük devretme gerçekleştiğinde Azure Kaynak Durumu etkinliği oluşturacaktır.

  • Etkin istekler: Kullanılabilirlik alanı kullanılamaz duruma geldiğinde, etkilenen bölgedeki sunuculara yönelik devam eden istekler sonlandırılabilir. Uygulamaların bu istekleri yeniden denemesi gerekir. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

  • Beklenen veri kaybı: Veri kaybı miktarı, sunucunuzun kullanılabilirlik alanı yapılandırmasına bağlıdır.

    • Bölge yedekli: Farklı bölgelerdeki birincil ve bekleme sunucuları arasında eşzamanlı çoğaltma nedeniyle bölge yük devretmesi sırasında sıfır veri kaybı beklenir.

    • Yerel olarak yedekli: Etkilenen bölgedeki sunuculardaki veriler, bölge kurtarana kadar kullanılamaz.

  • Beklenen kapalı kalma süresi: Kapalı kalma süresi, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

    • Bölge yedekliliği: Yük devretme genellikle 60-120 saniye içinde tamamlanır. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

    • Yerel olarak yedekli: Etkilenen bir bölgedeki sunucular kullanılabilirlik alanı kurtarılana kadar kullanılamaz.

  • Dağıt -ılması: Trafiği yeniden yönlendirme davranışı, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

    • Alanlar arası yedekli: Yük devretmeden sonra, eski yedek sunucu yeni ana sunucu olur ve yeni bağlantıları kabul eder. Azure, kurtarıldıktan sonra özgün birincil bölgede otomatik olarak bir hazır bekleyen sunucu oluşturur. Detaylar için Planlanmamış yük devretme kısmına bakınız.

    • Yerel olarak yedekli: Bir bölge kullanılamıyorsa, sunucunuz kullanılamaz. Başka bir kullanılabilirlik alanında veya bölgede önceden oluşturduğunuz ayrı bir sunucunuz varsa, trafiği bu sunucuya yönlendirmek sizin sorumluluğundadır.

Bölge kurtarma

Bölge kurtarma davranışı, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

  • Zone-redundant: Kullanılabilirlik alanı kurtarıldığında, MySQL için Azure Veritabanı kurtarılan bölgedeki bekleme sunucusunu otomatik olarak yeniden oluşturur ve geçerli birincil sunucuyla eşitler. Kurtarılan bölge, bekleme konumu olarak görev görür. Hizmet, gereksiz kesintileri önlemek için birincil rolü otomatik olarak özgün bölgeye geri taşımaz. Planlı bir yük devretmeyi manuel olarak başlatabilirsiniz eğer birincil bölgeyi özgün bölgeye döndürmek istiyorsanız.

  • Yerel olarak yedekli: Bölge iyi durumda olduktan sonra, bölgedeki sunucular yeniden kullanılabilir duruma gelir. İş yüklerinizin gerektirdiği tüm bölge kurtarma yordamlarından ve veri eşitlemeden siz sorumlusunuz.

Bölge hataları için test

Bölge hataları için test seçenekleri, örneğinizin kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

Bölge genelindeki hatalara dayanıklılık

MySQL için Azure Veritabanı, daha hızlı kurtarma için veritabanınızın eşzamanlı bir kopyasını farklı bir bölgede tutmanıza olanak tanıyan bölgesel okuma replikalarını destekler.

Bölgeler arası kurtarma sağlamak için desteklenen bölgelerde coğrafi olarak yedekli yedeklemeler de kullanabilirsiniz. Ancak yedeklemeler genellikle replikasyona göre daha fazla kapalı kalma süresine ve veri kaybına neden olur. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Bölgeler arası okuma replikaları

Veritabanlarınızı bölge düzeyindeki hatalardan korumak için okuma amaçlı çoğaltmalar dağıtabilirsiniz. Her okuma replikası ayrı bir MySQL için Azure Veritabanı sunucusudur. Azure'un ikinci bir bölgesine okuma replikası yerleştirdiğinizde, veritabanı sunucunuz bölge genelindeki bir soruna karşı direnç kazandırabilir. İsteğe bağlı olarak farklı Azure bölgelerinde olabilecek on adede kadar okuma amaçlı çoğaltma dağıtabilirsiniz. MySQL'in fiziksel çoğaltma teknolojisi, okuma amaçlı çoğaltmaları birincil bölgedeki kaynak sunucudan zaman uyumsuz olarak güncelleştirir ve kaynağı öteleyebilir. Bölgeler arası okuma amaçlı çoğaltmalar, genel olarak dağıtılmış uygulamaların gecikme süresini azaltmak veya kaynak sunucudan okuma trafiğini boşaltmak için isteğe bağlı olarak salt okunur iş yüklerine hizmet verebilir. Okuma amaçlı çoğaltma özellikleri ve dikkat edilmesi gerekenler hakkında daha fazla bilgi için Okuma amaçlı çoğaltmalar bölümüne bakın.

Birincil bölgeniz hata verirse, ikincil çoğaltmanızın birincil sunucu olması için manuel geçiş yapabilirsiniz. Bunu, okuma çoğaltmasını bir okuma-yazma sunucusuna dönüştüren çoğaltma işlemini durdurarak yaparsınız. Asenkron replikasyon nedeniyle failover veri kaybına neden olabilir. Ardından uygulamanızın yeni birincil sunucuya bağlanması gerekir ve bu uygulamanın yeniden yapılandırılması sizin sorumluluğunuzdadır.

Uyarı

Bu bölüm, okuma amaçlı çoğaltmaların bölgesel çapta meydana gelen başarısızlıklara karşı nasıl dayanıklılık sağlayabileceğine dair bazı önemli bilgileri özetlemektedir. Ayrıca, performansı geliştirmek ve yüksek ölçekli coğrafi olarak dağıtılmış kullanıcı tabanlarını desteklemek için okuma amaçlı çoğaltmaları da kullanabilirsiniz. Daha fazla bilgi için bkz Okuma çoğaltmaları.

Gereksinimler

  • Region support: MySQL için Azure Veritabanı destekleyen herhangi bir bölgede bölgeler arası okuma çoğaltmaları oluşturabilirsiniz. Eşleştirilmiş Azure bölgeyle sınırlı değilsiniz.

  • İşlem katmanları: Genel Amaçlı ve Bellek için İyileştirilmiş işlem katmanları okuma amaçlı çoğaltmaları destekler. Esnek katman, okuma replikalarını desteklemez.

Değerlendirmeler

  • Yapılandırma farklılıkları: Bir çoğaltma oluşturduğunuzda, işlem oluşturma, sanal çekirdekler ve depolama gibi çeşitli ayarları kaynak sunucudan devralır. Bu değerleri, oluşturduktan sonra okuma replikasında özelleştirebilirsiniz. Ancak, replikaların kaynaktaki değişikliklere ayak uydurabilmesini sağlamak için eşit veya daha büyük değerler kullanmak en iyisidir.

  • Çoğaltma gecikmesini izleme: Zaman uyumsuz çoğaltma işlemi bir çoğaltma gecikmesi gerektirir ve bu da çeşitli faktörlere bağlı olarak değişebilir. Çoğaltma gecikmesi çok yüksek olduğunda sunucunuzda sorunlarla karşılaşabilirsiniz. Sorunları yükseltmeden önce azaltabilmeniz için çoğaltma gecikmesini izlemek önemlidir. Daha fazla bilgi için bkz. Çoğaltmayı izleme.

  • Yüksek kullanılabilirlik: Okuma amaçlı çoğaltmalarda yüksek kullanılabilirlik etkinleştirilemez ve birincil sunucu olmak üzere yük devri yapıldıklarında da yüksek kullanılabilirlik sağlanamaz. Bir çoğaltmaya yük devredildikten sonra yüksek kullanılabilirliği yapılandırmak sizin sorumluluğundadır.

Maliyet

Okuma amaçlı çoğaltmalar işlem ve depolama maliyetlerinin yanı sıra çoğaltma için bölgeler arası veri aktarımı ücretlerine neden olur. Ayrıntılı fiyatlandırma bilgileri için bkz. MySQL için Azure Veritabanı pricing ve Bandwidth pricing.

Çok bölgeli desteği yapılandırma

Tüm bölgeler iyi durumda olduğunda davranış

Bu bölümde, sunucunuz başka bir bölgede okuma amaçlı çoğaltmayla yapılandırıldığında ve tüm bölgeler çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır:

  • Bölgeler arasında trafik yönlendirme: Normal işlemlerde uygulamanızın okuma-yazma trafiğini birincil bölgedeki kaynak sunucuya yönlendirmesi gerekir. İsteğe bağlı olarak okuma isteklerini okuma çoğaltmasına yönlendirebilirsiniz.

  • Bölgeler arasında veri çoğaltma: Bölgeler arası okuma çoğaltmaları, kaynak sunucu performansı üzerindeki etkiyi en aza indirmek için zaman uyumsuz çoğaltma kullanır. Çoğaltma gecikmesi miktarı, yazma yükü ve kaynak sunucu ile çoğaltmalar arasındaki gecikme süresi dahil olmak üzere bir dizi faktöre bağlıdır. Çoğaltma gecikmesi genellikle en az birkaç dakikadır, ancak çok daha uzun olabilir. Daha fazla bilgi için bkz. Monitor çoğaltma ve ayrıntılı yönergeler için bkz. Azure portalında Monitor çoğaltma.

Bölge hatası sırasındaki davranış

Sunucunuz başka bir bölgede okuma replikası ile yapılandırıldığında ve birincil bölgede bir kesinti meydana geldiğinde neler bekleyebileceğiniz bu bölümde açıklanmaktadır.

  • Algılama ve yanıt: Birincil bölgedeki bir kesintiyi algılamaktan ve yük devretmeyi manuel olarak tetiklemekten sorumlusunuz. Bu eylem, kopyalanmamış verilerin kaybolmasına neden olabilir.

    Önemli

    Yük devretmeyi tetikleme sorumluluğunuz vardır. Azure, bir bölge hatası meydana gelse bile okuma replikalarına otomatik olarak yük devretme yapmaz.

    Yük devretme işlemi için şunları yapmanız gerekir:

    1. Çoğaltmayı durdurun. Bu geri alınamaz bir işlemdir ve sunucu yeniden bir çoğaltma yapılamaz. İşlem veri kaybına neden olur. Bu eylemin etkileri hakkında daha fazla ayrıntı için bkz. Çoğaltmayı durdurma.
    2. Uygulamanızı yeni birincil uygulamayı kullanacak şekilde yeniden yapılandırın.

    Daha fazla bilgi için bkz. Yük Devretme.

  • Notification: Microsoft bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Ancak, Azure Hizmet Durumu kullanarak tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlayabilir ve sorunları size bildirmek için Service Health uyarıları ayarlayabilirsiniz.

  • Etkin istekler: Kaynak sunucu kullanılamıyorsa, kaynak bölgeye yönelik tüm etkin bağlantılar bırakılır. Yük devretme işlemi tamamlandıktan sonra uygulamaların yeni birincil sunucuyla bağlantı oluşturmayı yeniden denemesi gerekir.

  • Beklenen veri kaybı: Bölge kesintisi sırasında çoğaltmayı durduran bir yük devretme gerçekleştirmeniz gerekir. Bu işlem, kurtarılmamış verilerin kalıcı olarak kaybolmasına neden olur.

    Veri kaybı miktarı, kesinti sırasındaki çoğaltma gecikmesine bağlıdır. Çoğaltma gecikmesi genellikle en az birkaç dakikadır, ancak çok daha uzun olabilir. Daha fazla bilgi için bkz. Çoğaltmayı izleme.

  • Beklenen kapalı kalma süresi: Çoğaltmanın durdurulması genellikle tetiklenmesinden sonra 2 dakika içinde tamamlanır. Uygulamalarınızı yeni birincil sunucuya bağlanacak şekilde yeniden yapılandırmak sizin sorumluluğunuzdadır ve yeniden yapılandırmayı gerçekleştirmeniz için gereken süre de genel kapalı kalma sürenize katkıda bulunur.

  • Trafik yeniden yönlendirme: Uygulamalarınızı yeni birincil sunucuya bağlanacak şekilde yeniden yapılandırmak sizin sorumluluğunuzdadır.

    Uyarı

    Birincil sunucu olmak için okuma amaçlı bir çoğaltmaya yük devretdikten sonra sunucuda yüksek kullanılabilirlik etkinleştirilmez. Yüksek kullanılabilirliği el ile etkinleştirmeniz veya otomasyonunuza dahil etmeniz gerekir.

Bölge geri kazanımı

Bölge kurtarıldığında, birincil bölgedeki işlemleri yeniden başlatmak için gereken tüm geri dönme faaliyetleri sizin sorumluluğunuzdadır. Microsoft birincil sunucuyu otomatik olarak taşımaz. Birincil bölgede yeni bir okuma amaçlı çoğaltma oluşturabilir, ardından bir yük devretme işlemi daha gerçekleştirerek birincil bölgedeki işlemleri geri yükleyebilirsiniz. Uygulamanızın kapalı kalma süresini veya veri kaybını tolere edip edemeyeceğine bağlı olarak aşağıdaki yaklaşımlardan birini göz önünde bulundurun:

  • Uygulamanızı çevrimdışına alın ve çoğaltmanın tüm değişiklikleri yakalamasını bekleyin. Bu yaklaşım, yaklaşık olarak çoğaltma gecikmesine eşit olan uygulama kapalı kalma süresini gerektirir.
  • Yük devretmeyi gerçekleştirin ve kurtarılmamış verilerin kaybını kabul edin.

Uygulamalarınızı gerektiğinde yeni birincil sunucuya bağlanacak şekilde yeniden yapılandırmaktan da sorumlu olduğunuzu unutmayın.

Bölge hataları testi

İşlemlerinizin geçerli olduğundan ve özelliklerin RTO ve RPO gereksinimlerinizi karşıladığından emin olmak için okuma replikası yük devretme prosedürlerini düzenli olarak test edin.

Tüm bölgeler iyi durumda olsa bile, bir okuma replikasını birincil sunucuya geçiş (failover) yaparak istediğiniz zaman birincil sunucu haline getirebilirsiniz. Veri kaybına neden olabileceği ve el ile yeniden çalışma gerektirdiği için bu testleri üretim dışı bir ortamda gerçekleştirmenizi öneririz.

Olağanüstü durum kurtarma stratejinizin bir parçası olarak, düzenli olarak tam kurtarma tatbikatları çalıştırın. Bu alıştırmalar veri doğrulama, uygulama işlevselliği testi ve belgelenmiş geri alma prosedürlerini içermelidir.

Yedekleme ve geri yükleme

MySQL için Azure Veritabanı belirli bir noktaya kurtarma özellikleri sağlayan yedeklemeleri otomatik olarak gerçekleştirir ve verilerin yanlışlıkla bozulmasına ve silinmesine karşı korunmanıza yardımcı olur. Microsoft yedeklemeleri tam olarak yönetir, sunucunun kullanılabilirliğini kesintiye uğratmaz ve hem tam yedeklemeleri hem de işlem günlüğü yedeklemelerini içerir.

  • Yedekleme depolama alanı: Sunucu alanlar arası yedekli yüksek kullanılabilirlik ile yapılandırılmışsa, yedeklemeler alanlar arası yedekli depolamada (ZRS) depolanır. Yüksek kullanılabilirlik olmadan veya yerel olarak yedekli yüksek kullanılabilirlikle yapılandırılan sunucular için yedeklemeler yerel olarak yedekli depolamada (LRS) depolanır.

    Çiftli Azure bölgelerinde, bölge hatalarına karşı ek koruma için yedeklemeleri eşleştirilmiş Azure bölgesine kopyalamak amacıyla sunucu oluşturma sırasında coğrafi olarak yedekli (GRS) yedekleme depolama alanını yapılandırabilirsiniz. Yedeklemeler zaman uyumsuz olarak çoğaltılır.

    Varsayılan yedekleme saklama süresi 7 gündür ve saklama süresini 35 güne kadar uzatma seçeneği vardır. Tüm yedeklemeler şifrelenir.

  • Geri yükleme: Belirli bir noktaya kurtarma, yedekleme saklama süresi içinde veritabanınızı istediğiniz an geri yüklemenize olanak tanır. Geri yükleme işlemi, kullanıcı tarafından sağlanan yeni bir sunucu adıyla yeni bir veritabanı sunucusu oluşturur ve bu sunucuya as-is kullanabilir veya veri kopyalayabilirsiniz.

    Coğrafi olarak yedekli bir yedeklemeyi geri yüklerken, eşleştirilmiş bölgede yeni bir sunucu oluşturursunuz. Bazı bölgelerde, coğrafi yedekli bir yedeği, birincil bölgenizin eşlenik bölgesi olmayan bir bölgeye geri yüklemek için Evrensel Geo-Restore'u kullanabilirsiniz.

    Bu özellik yanlışlıkla yapılan veri değişikliklerinden, uygulama hatalarından veya test senaryolarından kurtarmak için kullanışlıdır.

Çoğu çözüm için yalnızca yedeklemelere güvenmemeniz gerekir. Bunun yerine, dayanıklılık gereksinimlerinizi desteklemek için bu kılavuzda açıklanan diğer özellikleri kullanın. Ancak yedeklemeler, diğer yaklaşımların koruma altına almayan bazı risklere karşı koruma sağlar. Daha fazla bilgi için bkz. Yedeklilik, çoğaltma ve yedekleme nedir?

Daha fazla bilgi için bkz. MySQL için Azure Veritabanı'de Yedekleme ve Geri Yükleme.

Hizmet bakımına dayanıklılık

MySQL için Azure Veritabanı temel donanım, işletim sistemi ve veritabanı altyapısına düzeltme eki uygulama gibi kritik hizmet görevlerini otomatik olarak işler. Hizmet, planlı bakımın bir parçası olarak güvenlik güncelleştirmelerini, yazılım güncelleştirmelerini ve ikincil sürüm yükseltmelerini içerir. Daha fazla bilgi için bkz. MySQL için Azure Veritabanı'de Planlanmış Bakım.

Sunucunuzun bakım pencereleri sırasında kullanılabilir durumda kaldığından emin olmak için şu önerileri izleyin:

  • Bakım dönemlerinde yönetim işlemlerinden kaçının: Bu işlemler sunucunuzun güvenilirliğini etkileyebileceğinden, bakım devam ederken sunucu yönetimi işlemleri gerçekleştirin.

  • Neredeyse sıfır kapalı kalma süresine yakın bakım kullanın: Sunucunuzda yüksek kullanılabilirlik etkinse ve diğer uygunluk ölçütlerini karşılıyorsa, bakım işlemleri genellikle 10-30 saniye içinde tamamlar. Yüksek kullanılabilirliği etkinleştirdiyseniz bakım işlemleri genellikle kapalı kalma süresini en aza indirmek için sıralı güncelleştirmeleri kullanır. Küçük sürüm yükseltmeleri gibi periyodik bakım etkinlikleri önce yedek kopyada gerçekleşir. Kesinti süresini azaltmak amacıyla, yedekteki düğüm birincil olarak yükseltilir, böylece bakım görevleri kalan düğüme uygulanırken iş yükleri devam edebilir. Bu sıralama, sunucunuzun alanlar arası yedekli veya yerel olarak yedekli yüksek kullanılabilirlik kullanıp kullanmadığını belirler. Daha fazla bilgi için bkz. Sıfıra yakın çalışma süresi bakımı.

  • Özel bakım pencerelerini yapılandırma: Bakım zamanlamasını sistem tarafından yönetilecek şekilde yapılandırabilir veya iş operasyonlarınız üzerindeki etkiyi en aza indirmek için özel bir bakım penceresi tanımlayabilirsiniz. Planlı bakım işlemlerini de yeniden zamanlayabilirsiniz. İş etkisini en aza indirmek için düşük etkinlik dönemlerinde bakım zamanlayın. Daha fazla bilgi için bkz. MySQL için Azure Veritabanı için zamanlanmış bakım ayarlarını yönetme.

  • Yeniden deneme mantığını uygulama: Uygulamalarınızın bakım yeniden başlatmaları sırasında oluşabilecek kısa bağlantı kesintileriyle başa çıkabileceğinden emin olun. Uygulamalarınızın bu tür sorunlara dayanıklı olmasını sağlamak için bkz. Geçici hatalara dayanıklılık kılavuzu.

  • Geliştirme ve test sunucularında Sanal Kanarya bakımını etkinleştirin: Sanal Kanarya bakımı, güncelleştirmelere erken erişim sağlar. Geliştirme ve test sunucularında etkinleştirerek, iş yükünüzün üretim sunucularınıza ulaşmadan önce yaklaşan güncelleştirmelerden etkilenmediğini doğrulayabilirsiniz. Daha fazla bilgi için bkz. Sanal Kanarya bakımı.

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için bkz. çevrimiçi hizmetler için SLA’lar.

MySQL için Azure Veritabanı, sunucunun yapılandırmasına göre farklı kullanılabilirlik SLA'ları sağlar:

  • Bölgeler arası yedekli yüksek kullanılabilirlik ile yapılandırılmış sunucular.
  • Yerel olarak yedekli yüksek kullanılabilirlik ile yapılandırılan sunucular.
  • Yüksek kullanılabilirlik olmadan yapılandırılan sunucular.

İlgili içerik

  • Last updated on