MySQL için Azure Veritabanı - Esnek Sunucu ile iş sürekliliğine genel bakış

  • Makale

ŞUNLAR IÇIN GEÇERLIDIR: MySQL için Azure Veritabanı - Esnek Sunucu

MySQL için Azure Veritabanı esnek sunucu, planlı ve plansız bir kesinti durumunda veritabanlarınızı koruyan iş sürekliliği özellikleri sağlar. Otomatik yedeklemeler ve yüksek kullanılabilirlik gibi özellikler, farklı kurtarma süresi ve veri kaybına maruz kalma ile farklı hata koruması düzeylerini giderir. Hatalara karşı koruma sağlamak için uygulamanızın mimarisini oluştururken, her uygulama için kurtarma süresi hedefini (RTO) ve kurtarma noktası hedefini (RPO) dikkate almanız gerekir. RTO kapalı kalma süresi toleransıdır ve RPO veritabanı hizmeti kesintiye uğramasının ardından veri kaybına dayanıklılıktır.

Aşağıdaki tabloda MySQL için Azure Veritabanı esnek sunucunun sunduğu özellikler gösterilmektedir.

Özellik Açıklama Kısıtlamalar
Yedekleme ve Kurtarma Hizmet, veritabanı dosyalarınızın günlük yedeklemelerini otomatik olarak gerçekleştirir ve işlem günlüklerini sürekli olarak yedekler. Yedeklemeler 1 ila 35 gün arasında herhangi bir süre saklanabilir. Veritabanı sunucunuzu yedekleme saklama süreniz içinde herhangi bir noktaya geri yükleyebilirsiniz. Kurtarma süresi, geri yükleneceği verilerin boyutuna ve günlük kurtarma gerçekleştirme süresine bağlıdır. Diğer ayrıntılar için Kavramlar - Yedekleme ve Geri Yükleme bölümüne bakın. Yedekleme verileri bölge içinde kalır
Yerel yedekli yedekleme Hizmet yedeklemeleri otomatik olarak ve güvenli bir şekilde bir bölge içinde ve aynı kullanılabilirlik alanında yerel yedekli bir depolamada depolanır. Yerel olarak yedekli yedeklemeler, sunucu yedekleme veri dosyalarını birincil bölgedeki tek bir fiziksel konumda üç kez çoğaltır. Yerel olarak yedekli yedekleme depolama, belirli bir yıl boyunca nesnelerin en az %99,999999999999 (11 dokuz) dayanıklılığını sağlar. Diğer ayrıntılar için Kavramlar - Yedekleme ve Geri Yükleme bölümüne bakın. Tüm bölgelerde geçerlidir
Coğrafi olarak yedekli yedekleme Hizmet yedeklemeleri oluşturma zamanında coğrafi olarak yedekli olarak yapılandırılabilir. Coğrafi yedekliliği etkinleştirmek, bölgesel dayanıklılık sağlamak için sunucu yedekleme veri dosyalarını birincil bölgenin ™eşleştirilmiş bölgesinde çoğaltır. Coğrafi olarak yedekli yedekleme depolama, belirli bir yıl boyunca nesnelerin en az %99,999999999999999 (16 dokuz) dayanıklılığını sağlar. Diğer ayrıntılar için Kavramlar - Yedekleme ve Geri Yükleme bölümüne bakın. Tüm Azure eşleştirilmiş bölgelerinde kullanılabilir
Alanlar arası yedekli yüksek kullanılabilirlik Hizmet, birincil ve bekleme sunucularını bir bölge içindeki iki farklı kullanılabilirlik alanına dağıtan yüksek kullanılabilirlik modunda dağıtılabilir. Alanlar arası yedekli yüksek kullanılabilirlik, bölge düzeyindeki hatalara karşı koruma sağlar ve planlı ve plansız kapalı kalma süresi olayları sırasında uygulama kapalı kalma süresini azaltmaya yardımcı olur. Birincil sunucudaki veriler eşzamanlı olarak hazır bekleyen çoğaltmaya çoğaltılır. Herhangi bir kapalı kalma olayı sırasında veritabanı sunucusu otomatik olarak hazır bekleyen çoğaltmaya yük devretme gerçekleştirir. Diğer ayrıntılar için Kavramlar - Yüksek kullanılabilirlik bölümüne bakın. Genel amaçlı ve İş Açısından Kritik işlem katmanlarında desteklenir. Yalnızca birden çok bölgenin kullanılabildiği bölgelerde kullanılabilir.
Premium dosya paylaşımları Veritabanı dosyaları, otomatik veri kurtarma özelliklerine sahip bir kullanılabilirlik alanında depolanan çoğaltmanın üç kopyasıyla veri yedekliliği sağlayan son derece dayanıklı ve güvenilir bir Azure premium dosya paylaşımlarında depolanır. Daha fazla ayrıntı için Premium Dosya paylaşımlarına bakın. Kullanılabilirlik alanında depolanan veriler

Planlı kapalı kalma süresini azaltma

Kapalı kalma süresine neden olan bazı planlı bakım senaryoları şunlardır:

Senaryo İşlem
İşlem ölçeklendirme (Kullanıcı) İşlem ölçeklendirme işlemi gerçekleştirdiğinizde, ölçeklendirilmiş işlem yapılandırması kullanılarak yeni bir esnek sunucu sağlanır. Mevcut veritabanı sunucusunda etkin denetim noktalarının tamamlanmasına izin verilir, istemci bağlantıları boşaltılır, kaydedilmemiş işlemler iptal edilir ve ardından kapatılır. Depolama daha sonra yeni sunucuya eklenir ve veritabanı başlatılır ve bu da istemci bağlantılarını kabul etmeden önce gerekirse kurtarma gerçekleştirir.
Yeni yazılım dağıtımı (Azure) Yeni özelliklerin piyasaya sürülmesi veya hata düzeltmeleri, hizmetin planlı bakımının bir parçası olarak otomatik olarak gerçekleşir ve bu etkinliklerin ne zaman gerçekleşebileceğini zamanlayabilirsiniz. Daha fazla bilgi için belgelere bakın ve ayrıca portalınızı denetleyin
İkincil sürüm yükseltmeleri (Azure) MySQL için Azure Veritabanı esnek sunucu, veritabanı sunucularına otomatik olarak Azure tarafından belirlenen ikincil sürüme düzeltme eki ekler. Hizmetin planlı bakımının bir parçası olarak gerçekleşir. Bu işlem saniyeler içinde kısa bir kapalı kalma süresine neden olur ve veritabanı sunucusu yeni ikincil sürümle otomatik olarak yeniden başlatılır. Daha fazla bilgi için belgelere bakın ve portalınızı denetleyin.

Esnek sunucu alanlar arası yedekli yüksek kullanılabilirlik ile yapılandırıldığında, esnek sunucu önce bekleme sunucusunda, ardından yük devretme olmadan birincil sunucuda işlemler gerçekleştirir. Diğer ayrıntılar için Kavramlar - Yüksek kullanılabilirlik bölümüne bakın.

Planlanmamış kapalı kalma süresini azaltma

Planlanmamış kapalı kalma süreleri, temel alınan donanım hatası, ağ sorunları ve yazılım hataları gibi öngörülemeyen hatalardan kaynaklanabilir. Veritabanı sunucusu beklenmedik şekilde kapanırsa, yüksek kullanılabilirlik [HA] ile yapılandırılırsa, bekleme çoğaltması etkinleştirilir. Aksi takdirde, yeni bir veritabanı sunucusu otomatik olarak sağlanır. Planlanmamış bir kapalı kalma süresi önlenemez ancak esnek sunucu, insan müdahalesi gerektirmeden hem veritabanı sunucusunda hem de depolama katmanlarında kurtarma işlemlerini otomatik olarak gerçekleştirerek kapalı kalma süresini azaltır.

Planlanmamış kapalı kalma süresi: hata senaryoları ve hizmet kurtarma

Bazı planlanmamış hata senaryoları ve kurtarma işlemi şunlardır:

Senaryo Kurtarma işlemi [HA olmayan] Kurtarma işlemi [HA]
Veritabanı sunucusu hatası Veritabanı sunucusu bazı temel donanım hataları nedeniyle çalışmıyorsa, etkin bağlantılar bırakılır ve tüm trafik trafik işlemleri durdurulır. Azure, veritabanı sunucusunu yeniden başlatmayı dener. Bu başarılı olursa veritabanı kurtarma gerçekleştirilir. Yeniden başlatma başarısız olursa, başka bir fiziksel düğümde veritabanı sunucusu yeniden başlatma girişiminde bulunulur.

Kurtarma süresi (RTO), büyük işlem ve veritabanı sunucusu başlatma işlemi sırasında gerçekleştirilecek kurtarma miktarı gibi hata sırasındaki etkinlik de dahil olmak üzere çeşitli faktörlere bağlıdır. RPO sıfırdır, ancak işlenen işlemler için veri kaybı beklenmemektedir. MySQL veritabanlarını kullanan uygulamaların bırakılan bağlantıları ve başarısız işlemleri algılayıp yeniden deneyecek şekilde derlenmiş olması gerekir. Uygulama yeniden denendiğinde, bağlantılar yeni oluşturulan veritabanı sunucusuna yönlendirilir.

Diğer kullanılabilir seçenekler yedeklemeden geri yüklenir. Eşleştirilmiş bölgeden hem PITR hem de Coğrafi geri yükleme kullanabilirsiniz.
PITR : RTO: Değişken, RPO=0sec
Coğrafi Geri Yükleme : RTO: RPO <1 s'ye göre değişir.

Okuma amaçlı çoğaltmayı DR çözümü olarak da kullanabilirsiniz. Çoğaltmayı durdurarak okuma amaçlı çoğaltmayı okuma-yazma (tek başına) ve ardından uygulama trafiğini bu veritabanına yeniden yönlendirebilirsiniz. Çoğu durumda RTO birkaç dakika ve RPO < 1 s'dir. RTO ve RPO, siteler arasındaki gecikme süresi, iletilecek veri miktarı ve önemli ölçüde birincil veritabanı yazma iş yükü gibi çeşitli faktörlere bağlı olarak bazı durumlarda çok daha yüksek olabilir.		 Veritabanı sunucusu hatası veya kurtarılamayan hatalar algılanırsa, bekleyen veritabanı sunucusu etkinleştirilir ve böylece kapalı kalma süresi azalır. Daha fazla ayrıntı için HA kavramları sayfasına bakın. RTO'nun RPO=0 ile 60-120 sn olması beklenir.

Not: Kurtarma işlemi [HA olmayan] seçenekleri de burada geçerlidir.
Depolama hatası Uygulamalar, disk hatası veya fiziksel blok bozulması gibi depolamayla ilgili sorunlar için herhangi bir etki görmez. Veriler üç kopyada depolandığından, verilerin kopyası kalan depolama alanı tarafından sunulur. Blok bozulmaları otomatik olarak düzeltilir. Verilerin bir kopyası kaybolursa, verilerin yeni bir kopyası otomatik olarak oluşturulur.

Nadir veya en kötü durumdaki bir senaryoda, tüm kopyalar bozulursa Coğrafi geri yüklemeden (eşleştirilmiş bölge) geri yükleme özelliğini kullanabiliriz. RPO 1 s ve < RTO farklılık gösterebilir.

Okuma amaçlı çoğaltmayı yukarıda açıklandığı gibi DR çözümü olarak da kullanabilirsiniz.		 Bu senaryo için seçenekler Kurtarma işlemi [HA olmayan] ile aynıdır.
Mantıksal/kullanıcı hataları Yanlışlıkla bırakılan tablolar veya yanlış güncelleştirilmiş veriler gibi kullanıcı hatalarından kurtarma, hata oluşmadan hemen önce verileri geri yükleyip kurtararak belirli bir noktaya kurtarma (PITR) gerçekleştirmeyi içerir.

Silinen esnek sunucu kaynağını, sunucu silindikten sonra beş gün içinde kurtarabilirsiniz. Silinen bir sunucuyu geri yükleme hakkında ayrıntılı bir kılavuz için [belgelenen adımlara bakın] (.. /flexible-server/how-to-restore-dropped-server.md). Dağıtım sonrasında sunucu kaynaklarını yanlışlıkla silinmeye veya beklenmeyen değişikliklere karşı korumak için yöneticiler yönetim kilitlerini kullanabilir.		 Tüm kullanıcı işlemleri de bekleme konumuna çoğaltıldığından bu kullanıcı hataları yüksek kullanılabilirlikle korunmaz. Bu senaryo için seçenekler Kurtarma işlemiyle aynıdır [HA olmayan]
Kullanılabilirlik alanı hatası Bu nadir bir olay olsa da, bölge düzeyinde bir hatadan kurtarmak istiyorsanız, eşleştirilmiş bir bölgeden Coğrafi geri yükleme gerçekleştirebilirsiniz. RPO 1 s ve <RTO farklılık gösterebilir.

Okuma amaçlı çoğaltmayı, başka bir kullanılabilirlik alanında çoğaltma oluşturarak DR çözümü olarak da kullanabilirsiniz. RTO\RPO, yukarıda ayrıntılarıyla belirtilen gibidir.		 Alanlar arası yedekli HA'yı etkinleştirdiyseniz, esnek sunucu bekleme sitesine otomatik yük devretme gerçekleştirir. Daha fazla ayrıntı için HA kavramlarına bakın. RTO'nun RPO=0 ile 60-120 sn olması beklenir.

Diğer kullanılabilir seçenekler yedeklemeden geri yüklenir. Eşleştirilmiş bölgeden hem PITR hem de Coğrafi geri yükleme kullanabilirsiniz.
PITR : RTO: Değişken, RPO=0 sn
Coğrafi Geri Yükleme : RTO: Değişken, RPO <1 s

Not: Aynı bölge HA'sı etkinse, seçenekler Kurtarma işlemi [HA olmayan] ile aynıdır.
Bölge hatası Nadir bir olay olsa da, bölge düzeyinde bir hatadan kurtarmak istiyorsanız, aynı abonelik altında sağlanan en son coğrafi olarak yedekli yedeklemeyi kullanarak yeni bir sunucu oluşturarak veritabanı kurtarma gerçekleştirerek en son verilere ulaşabilirsiniz. Seçilen bölgeye yeni bir esnek sunucu dağıtılır. Geri yükleme için geçen süre, önceki yedeklemeye ve kurtarılması gereken işlem günlüklerinin sayısına bağlıdır. Çoğu durumda RPO 1 s ve <RTO farklılık gösterebilir. Bu senaryo için seçenekler Kurtarma işlemi [HA olmayan] ile aynıdır.

Gereksinimler ve Sınırlamalar

Bölge Veri Yerleşimi

Varsayılan olarak, MySQL için Azure Veritabanı esnek sunucu müşteri verilerini dağıtılan bölgenin dışına taşımaz veya depolamaz. Ancak müşteriler isteğe bağlı olarak coğrafi olarak yedekli yedeklemeleri etkinleştirmeyi veya verileri başka bir bölgede depolamak için bölgeler arası çoğaltmayı ayarlamayı seçebilir.

Sonraki adımlar