Aracılığıyla paylaş

SQL Server'ın her zaman kullanılabilirlik gruplarını yedekleme

Azure Backup, SQL Server Always On kullanılabilirlik gruplarını (AG) yedeklemek için, tüm düğümler Kurtarma Hizmetleri kasasıyla aynı bölgede ve abonelikte olduğu sürece uçtan uca destek sunar. Ancak AG düğümleri bölgelere/aboneliklere/şirket içi ve Azure'a yayılmışsa dikkat edilmesi gereken birkaç nokta vardır.

Bugün desteklediğimiz yedekleme ve geri yükleme senaryolarını görüntülemek için destek matrisine bakın. Sık sorulan sorular için sık sorulan sorulara bakın.

Uyarı

Temel Kullanılabilirlik Grubu veritabanlarının yedeklenmesi Azure Backup tarafından desteklenmez.

Azure Backup SQL AG tarafından kullanılan yedekleme tercihi, yalnızca birincil çoğaltıcıdan tam ve farklılık yedeklemelerini destekler. Bu nedenle, yedekleme tercihi ne olursa olsun bu yedekleme işleri her zaman Birincil düğümde çalışır. Yalnızca kopya tam ve işlem günlüğü yedeklemeleri için, yedeklemenin çalıştırılacağı düğüme karar verilirken AG yedekleme tercihi dikkate alınır.

AG Yedekleme tercihi Tam ve Fark yedeklemeleri çalıştırılır Copy-Only ve Log yedeklemeleri alınır
Birincil Birincil replikası Birincil replikası
Yalnızca ikincil Birincil replikası İkincil kopyalarından herhangi biri
İkincili Tercih Et Birincil replikası İkincil çoğaltmalar tercih edilir, ancak yedeklemeler birincil çoğaltmada da çalıştırılabilir.
Yok/Herhangi Biri Birincil replikası Herhangi bir replika

İş yükü yedekleme uzantısı, Azure Backup hizmetine kaydettiğinizde düğüme yüklenir. Bir AG veritabanı yedekleme için yapılandırıldığında, yedekleme zamanlamaları AG'nin tüm kayıtlı düğümlerine gönderilir. Zamanlamalar tüm AG düğümlerinde başlatılır ve bu düğümlerdeki iş yükü yedekleme uzantıları, hangi düğümün yedekleme işlemini gerçekleştirebileceğine karar vermek için birbirleriyle senkronize olur. Düğüm seçimi, 1. bölümde açıklandığı gibi yedekleme türüne ve yedekleme tercihlerine bağlıdır.

Seçili düğüm yedekleme görevine devam ederken, diğer düğümlerde tetiklenen iş işlemden vazgeçiyor, yani işi atlıyor.

Uyarı

Azure Backup, ikincil çoğaltmalar arasında karar verirken yedekleme önceliklerini veya çoğaltmaları dikkate almaz.

AG düğümlerini Kurtarma Hizmetleri deposuna kaydetme

Kurtarma Hizmetleri kasası, veritabanlarının yalnızca kasayla aynı bölgedeki ve abonelikteki VM'lerden yedeklerini destekler.

  • Birincil düğümü kasaya kaydedin (aksi takdirde tam yedeklemeler gerçekleşemez).
  • Yedekleme tercihi yalnızca ikincilse kasaya en az bir ikincil düğüm kaydedin (aksi takdirde günlük/yalnızca kopyalama tam yedeklemeleri gerçekleşemez).

AG veritabanları için yedeklemeleri yapılandırma işlemi, yukarıdaki koşullar karşılanmazsa FabricSvcBackupPreferenceCheckFailedUserError hata koduyla başarısız olur.

Şimdi aşağıdaki AG dağıtımını bir referans noktası olarak ele alalım.

Referans olarak AG dağıtım diyagramı.

Verilen örnek AG dağıtımına bağlı olarak, aşağıda dikkat edilmesi gereken çeşitli noktalar verilmiştir:

  • Birincil düğüm bölge 1 ve abonelik 1'de olduğundan, bu AG'yi korumak için Kurtarma Hizmetleri kasasının (Kasa 1) Bölge 1 ve Abonelik 1'de olması gerekir.
  • VM3 farklı bir abonelikte olduğundan Vault 1'e kaydedilemez.
  • VM4 farklı bir bölgede olduğundan Vault 1'e kaydedilemez.
  • Yedekleme tercihi yalnızca ikincilse, VM1 (Birincil) ve VM2 (İkincil) Kasa 1'e kaydedilmelidir (çünkü tam yedeklemeler birincil düğüm ve günlükler ikincil düğüm gerektirir). Diğer yedekleme tercihleri için VM1 'in (Birincil) Kasa 1'e kaydedilmesi gerekir; VM2 isteğe bağlıdır (çünkü tüm yedeklemeler birincil düğümde çalıştırılabilir).
  • VM3, 2. abonelikte kasa 2'ye kaydedilebilse de AG veritabanları kasa 2'de koruma için görünür ancak kasa 2'de birincil düğümün olmaması nedeniyle yedeklemeleri yapılandırma başarısız olur.
  • Benzer şekilde, VM4 bölge 2'deki kasa 4'e kaydedilebilse de, birincil düğüm kasa 4'e kaydedilmediğinden yedeklemeleri yapılandırma işlemi başarısız olabilir.

Yük devretmeyi yönetme

AG, ikincil düğümlerden birine geçiş yaptıktan sonra:

  • Kasa kaydedilmişse, tam ve değişken yedeklemeler yeni birincil düğümden devam edecektir.
  • Günlük yedeklemeler ve yalnızca kopyalama tam yedeklemeler, yedekleme tercihine bağlı olarak birincil veya ikincil düğümden yapılmaya devam edecektir.

Uyarı

Yük devretmenin yedeklemeyle çakışmaması halinde, günlük zinciri kopmaları meydana gelmez.

Yukarıdaki örnek AG dağıtımına bağlı olarak, çeşitli yük devretme olasılıkları aşağıda listelenmiştir.

  • VM2'ye yük devretme
    • VM2'den tam ve diferansiyel yedeklemeler yapılacaktır.
    • Yedekleme tercihlerine bağlı olarak VM1 veya VM2 tarafından günlük ve yalnızca kopya tam yedeklemeler yapılacaktır.
  • VM3'e yük devretme (başka bir abonelik)
    • Kasa 2'de yedeklemeler yapılandırılmamış olduğundan yedekleme gerçekleşmez.
    • Yedekleme tercihi yalnızca ikincil değilse, birincil düğüm bu kasaya kaydedildiğinden yedeklemeler artık Kasa 2'de yapılandırılabilir. Ancak bu, çakışmalara/yedekleme hatalarına neden olabilir. Bu konuda daha fazla bilgi için bkz. Çok bölgeli AG için yedeklemeleri yapılandırma.
  • Başka bir bölgedeki VM4'e yük devretme
    • Kasa 4'te yedeklemeler yapılandırılmamış olduğundan yedekleme gerçekleşmez.
    • Yedekleme tercihi yalnızca ikincil değilse, birincil düğüm bu kasaya kaydedildiğinden yedeklemeler artık Kasa 4'te yapılandırılabilir. Ancak bu, çakışmalara/yedekleme hatalarına neden olabilir. Bu konuda daha fazla bilgi için bkz. Çok bölgeli AG için yedeklemeleri yapılandırma.

Çok bölgeli AG için yedeklemeleri yapılandırma

Kurtarma hizmetleri kasası abonelikler arası veya bölgeler arası yedeklemeleri desteklemez. Bu bölümde, abonelikleri veya Azure bölgelerini kapsayan AG'ler için yedeklemelerin nasıl etkinleştirileceği ve ilgili önemli noktalar özetlenir.

  • Tüm düğümlerden yedeklemeleri gerçekten etkinleştirmeniz gerekip gerekmediğini değerlendirin. Bir bölgede/abonelikte AG düğümlerinin çoğu varsa ve diğer düğümlere yük devretme çok nadir gerçekleşirse, yedeklemeyi ilk bölgede ayarlamak yeterli olabilir. Başka bir bölgeye/aboneliğe yük devretme işlemleri sık sık ve uzun süre gerçekleşirse, yedeklemeleri diğer bölgede proaktif olarak da ayarlamak isteyebilirsiniz.

  • Yedeklemenin etkinleştirildiği her kasanın kendi kurtarma noktası zincirleri vardır. Bu kurtarma noktalarından geri yüklemeler yalnızca o kasada kayıtlı VM'lere yapılabilir.

  • Tam/biriksiz yedeklemeler yalnızca birincil düğüme sahip kasada başarıyla yapılabilir. Diğer kasalardaki bu yedeklemeler sürekli başarısız olmaya devam edecek.

  • Günlük yedeklemeleri, yeni kasada (yeni birincil düğümün bulunduğu kasada) bir günlük yedeklemesi çalıştırılıp eski kasa için günlük zincirini kırana kadar önceki kasada çalışmaya devam eder.

    Uyarı

    Günlük yedeklemelerin başarısız olmaya başlayacağı 15 günlük kesin bir sınır vardır.

  • Yalnızca kopya tam yedeklemeler tüm depolarda çalışır.

  • Her kasadaki koruma ayrı bir veri kaynağı olarak kabul edilir ve ayrı olarak faturalandırılır.

İki kasa arasında günlük yedekleme çakışmalarını önlemek için yedekleme tercihini Birincil olarak ayarlamanızı öneririz. Ardından, hangi kasa birincil düğüme sahipse günlük yedeklemelerini de alır.

Yukarıdaki örnek AG dağıtımına bağlı olarak, tüm düğümlerden yedeklemeyi etkinleştirme adımları şunlardır. Varsayım, yedekleme tercihinin tüm adımlarda karşılanmasıdır.

1. Adım: Bölge 1, Abonelik 1'de (Kasa 1) yedeklemeleri etkinleştirme

Birincil düğüm bölge ve abonelikte olduğundan, yedeklemeleri etkinleştirmeye yönelik olağan adımlar çalışır.

2. Adım: Bölge 1, Abonelik 2'de (Kasa 2) yedeklemeleri etkinleştirme

  1. AG'nin birincil düğümün Kasa 2'de yer alması için VM3'e geçiş yapması.
  2. Vault 2'deki AG veritabanları için yedeklemeleri yapılandırın.
  3. Bu noktada:
    1. Kayıtlı düğümlerden hiçbiri bu yedeklemeyi gerçekleştiremediği için Kasa 1'de tam veya değişiklik yedeklemeleri başarısız olur.
    2. Günlük yedeklemeler, Vault 2'de bir günlük yedekleme çalıştırılıp Vault 1 için günlük zincirini kırana kadar Vault 1'de başarılı olacaktır.
  4. AG'yi VM1'e yeniden çalıştırın.

3. Adım: Bölge 2, Abonelik 1'de (Kasa 4) yedeklemeleri etkinleştirme

2. Adımla aynı.

Azure'a ve şirket içi ağa yayılan bir AG'yi yedekleme

SQL Server için Azure Backup şirket içinde çalıştırılamaz. Birincil düğüm Azure'daysa ve yedekleme tercihi Azure'daki düğümler tarafından karşılanıyorsa, Azure'daki çoğaltmalar için yedeklemeleri etkinleştirmek üzere çok bölgeli AG için yukarıdaki yönergeleri izleyebilirsiniz. Şirket içi düğüme yük devretme gerçekleşirse, Azure'de tam ve farklı yedeklemeler başarısız olur. Günlük zincirinin kopması veya 15 gün geçmesi durumuna kadar günlük yedeklemeler devam edebilir.

AG veritabanında yedekleme işleri için kısıtlama

Şu anda yedekleme kontrolü sınırları tek bir makine düzeyinde geçerlidir. Varsayılan sınır 20'dir; eşzamanlı olarak 20'den fazla yedekleme tetiklenirse, ilk 20 çalıştırılır ve diğerleri kuyruğa alınır. Çalışan işler tamamlandığında, kuyruğa alınan işler çalışmaya başlar.

Eşzamanlı yedeklemeler düğümde bellek/GÇ/CPU zorlanmasına neden oluyorsa bu değeri daha küçük bir değerle değiştirebilirsiniz. Azaltma düğüm düzeyinde olduğu için, AG düğümlerinin dengesiz olması yedekleme eşitleme sorunlarına yol açabilir. Bunu anlamak için örneğin 2 düğüm ag düşünün.

Örneğin, ilk düğümde korunan 50 tek başına veritabanı vardır ve her iki düğümde de 5 AG veritabanı korunur. Düğüm 1'de 55 veritabanı yedekleme işi zamanlanmışken Düğüm 2'de yalnızca 5 tane vardır. Ayrıca, tüm bu yedeklemeler saatte bir aynı anda çalışacak şekilde yapılandırılır. Belirli bir noktada, Düğüm 1 üzerinde 55 yedeklemenin tümü tetiklenir ve bunlardan 35'i kuyruğa alınır. Bunlardan bazıları AG veritabanı yedeklemeleri olabilir. Ancak Node 2'de AG veritabanı yedeklemeleri herhangi bir kuyruğa alınmadan devam eder.

AG veritabanı işleri bir düğümde kuyruğa alınıp başka bir düğümde çalıştırıldığından, yedekleme eşitlemesi (bölüm 6'da bahsedilir) düzgün çalışmaz. Düğüm 2, Düğüm 1'in kapalı olduğunu varsayabilir ve bu nedenle oradan gelen işler eşitleme için gelmiyor. Her iki düğüm de bağımsız olarak yedek alabildiği için bu durum günlük zincirinin bozulmasına veya ek yedeklemelere yol açabilir.

Korunan AG veritabanı sayısı darboğaz sınırından fazla ise benzer bir sorun oluşabilir. Bu durumda DB1 için yedekleme Node 1'de kuyruğa alınırken Node 2 üzerinde çalışır.

Bu eşitleme sorunlarını önlemek için aşağıdaki yedekleme tercihlerini kullanmanızı öneririz:

  • 2 düğümlük bir AG için Yedekleme Tercihi'ni Birincil veya Yalnızca İkincil olarak ayarlayın; ardından yedeklemeleri yalnızca bir düğüm yapabilir, diğeri her zaman serbest kalır.
  • 2'den fazla düğüme sahip bir AG için Yedekleme Tercihi'ni Birincil olarak ayarlayın; ardından yedeklemeleri yalnızca birincil düğüm yapabilir, diğerleri serbest kalır.

AG yedeklemeleri için faturalama

Tek başına SQL örneğiyle aynı şekilde, yedeklenen bir AG örneği tek bir korumalı örnek olarak kabul edilir. Bir örnekteki tüm korumalı veritabanlarının toplam ön uç boyutu ücretlendirilir. Aşağıdaki dağıtımı göz önünde bulundurun:

Veritabanlarının korumalı örneklerinin hesaplamasını gösteren diyagram.

Korumalı örnekler aşağıdaki gibi hesaplanır:

Korumalı Örnek/ Faturalama örneği Ön uç boyutunu hesaplamak için düşünülen veritabanları
AG1 DB1, DB2
AG2 DB4
VM2 DB3
VM3 DB6
VM4 DB5

Korumalı veritabanını AG içinde veya dışında taşıma

Azure Backup SQL örneği veya AG adı\Veritabanı adı'nı veritabanının benzersiz adı olarak kabul eder. Tek başına veritabanı korunduğunda benzersiz adı StandAloneInstanceName\DBName idi. Bir AG altında hareket ettiğinde, benzersiz ad AGName\DBName olarak değişir. Tek başına veritabanının yedeklemeleri şu hata koduyla başarısız olmaya başlayacaktır: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Veritabanı, AG'den korunma sağlanacak şekilde yapılandırılmalıdır. Bu, ayrı bir kurtarma noktası zincirine sahip yeni bir veri kaynağı olarak ele alınacaktır. Tek başına veritabanının eski koruması, gelecekteki yedeklemelerin tetiklenip üzerinde başarısız olmasını önlemek için verileri tutarak durdurulabilir. Benzer şekilde, korumalı bir AG veritabanı AG'nin dışına taşınıp tek başına veritabanı haline geldiğinde, yedeklemeleri şu hata koduyla başarısız olur: UserErrorBackupFailedDatabaseMovedOutOfAG.

Veritabanı, bağımsız örnek üzerinden koruma sağlamak amacıyla yapılandırılmalıdır. Bu, ayrı bir kurtarma noktası zincirine sahip yeni bir veri kaynağı olarak ele alınacaktır. AG veritabanının eski koruması, verilerin saklanarak gelecekteki yedeklemelerin tetiklenmesini ve başarısız olmasını önlemek için durdurulabilir.

Bir düğümü AG'ye ekleme veya çıkarma

Yedeklemeler için yapılandırılmış bir AG'ye yeni bir düğüm eklendiğinde, zaten kayıtlı OLAN AG düğümlerinde çalışan iş yükü yedekleme uzantıları AG topolojisi değişikliğini algılar ve bir sonraki zamanlanmış veritabanı bulma işi sırasında Azure Backup hizmetine bildirir. Bu yeni düğüm, diğer mevcut düğümlerle aynı Kurtarma Hizmetleri kasasına yedeklemeler için kaydedildiğinde, Azure Yedekleme hizmeti, AG yedeklemelerini gerçekleştirmek için gerekli meta verilerle bu yeni düğümü yapılandıran bir iş akışını tetikler.

Bundan sonra, yeni düğüm Azure Backup hizmetinden AG yedekleme zamanlaması bilgilerini senkronize eder ve senkronize yedekleme işlemine katılmaya başlar. Yeni düğüm yedekleme zamanlamalarını eşitleyemiyor ve yedeklemelere katılamıyorsa, düğümde yeniden kayıt tetiklenmesi, düğümün AG yedeklemeleri için yeniden yapılandırılmasını da zorlar. Benzer şekilde düğüm ekleme, iş yükü uzantıları bu durumda AG topolojisi değişikliğini algılar ve Azure Backup hizmetini bilgilendirir. Hizmet, AG veritabanlarının yedekleme zamanlamalarını temizlemek ve AG ile ilgili meta verileri silmek için kaldırılan düğümde bir düğüm yapılandırma dışı iş akışı başlatır.

Azure Backup'tan AG düğümünü kaydetmeyi kaldırma

Bir düğüm, yedekleme için yapılandırılmış bir veya daha fazla veritabanının olduğu bir AG'nin parçasıysa, Azure Backup bu düğümün kaydını kaldırmaya izin vermez. Bu, bu düğüm olmadan yedekleme tercihinin karşılanmaması durumunda gelecekteki yedekleme hatalarını önlemektir. Düğümün kaydını kaldırmak için önce onu AG'den (Uygulama Grubu) çıkarmanız gerekir. Düğüm yapılandırmayı kaldırma iş akışı tamamlandığında, bu düğümü temizleyerek kaydı kaldırabilirsiniz.

Veritabanını Azure Backup'tan AG SQL Kullanılabilirlik Gruplarına geri yükleme, veritabanını doğrudan AG'ye geri yüklemeyi desteklemez. Veritabanının tek başına bir SQL örneğine geri yüklenmesi ve ardından bir AG'ye katılması gerekir.

SQL veritabanı sunucusu için kullanılabilirlik grubu yeniden oluşturma senaryoları

Kullanılabilirlik grubunun (AG), yinelenen AG'lerin ve yedekleme öğelerinin yeniden oluşturulması, aşağıdaki senaryolarda korunabilir öğeler veya korumalı öğeler olarak listelenir:

  • Zaten korunan AG'ler yeniden oluşturulduğunda, Yedeklemeyi Yapılandır sayfasında ve Korumalı öğeler listesinde yinelenen AG'ler olarak görünür. Eski AG'de zaten mevcut olan yedekleme verilerini korumak istiyorsanız, yeni AG öğelerinde yedeklemeleri yeniden oluşturmadan ve zamanlamadan önce Korumayı durdur ve verileri koru seçeneğini kullanarak yedeklemeyi durdurun.

    Tasarım gereği Azure Backup, Korumalı öğeler listesindeki yinelenen öğeleri ve Yedeklemeyi Yapılandır sayfasını veya Korunabilir öğe listesini listeler ve yedekleme verilerini korumak isteyene kadar bu öğeleri görüntüler.

  • Eski AG'den yedekleme verilerini istemiyorsanız, yeni AG'de yedeklemeleri yeniden oluşturmadan ve zamanlamadan önce eski öğenin Korumayı durdur ve verileri sil seçeneğini kullanarak yedekleme işlemini durdurun.

    Dikkat

    Korumayı durdurma ve verileri silme yıkıcı bir işlemdir.

  • Yedekleme hatalarını önlemek için yukarıdaki Korumayı durdurma işleminden birini gerçekleştirdikten sonra AG'yi yeniden oluşturabilirsiniz.

Sonraki Adımlar

Nasıl yapılacağını öğrenin:

İlgili içerik

  • Last updated on