SQL Server'ın her zaman kullanılabilirlik gruplarını yedekleme
Azure Backup, tüm düğümler Kurtarma Hizmetleri kasasıyla aynı bölgede ve abonelikteyse SQL Server'ı her zaman kullanılabilirlik gruplarına (AG) yedeklemek için 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.
Not
- Temel Kullanılabilirlik Grubu veritabanlarının yedeklenmesi Azure Backup tarafından desteklenmez.
- Desteklenen yapılandırmalar ve senaryolar hakkında daha fazla bilgi edinmek için SQL yedekleme destek matrisine bakın.
Azure Backup SQL AG tarafından kullanılan yedekleme tercihi, yalnızca birincil çoğaltmadan tam ve değişiklik 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 üzerinde çalışır | Salt Kopya ve Günlük yedeklemeleri |
|---|---|---|
| Birincil | Birincil çoğaltma | Birincil çoğaltma |
| Yalnızca ikincil | Birincil çoğaltma | İkincil çoğaltmalardan herhangi biri |
| İkincil Tercih Et | Birincil çoğaltma | İkincil çoğaltmalar tercih edilir, ancak yedeklemeler birincil çoğaltmada da çalıştırılabilir. |
| Yok/Herhangi Biri | Birincil çoğaltma | Herhangi bir çoğaltma |
İş yükü yedekleme uzantısı, Azure Backup hizmetine kaydedildiğinde 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 tetiklenir ve bu düğümlerdeki iş yükü yedekleme uzantıları, yedeklemeyi hangi düğümün gerçekleştireceğine karar vermek için kendi aralarında eşitlenir. 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 işiyle devam ederken, diğer düğümlerde tetiklenen iş serbest bırakılıyor, yani işi atlıyor.
Not
Azure Backup, ikincil çoğaltmalar arasında karar verirken yedekleme önceliklerini veya çoğaltmaları dikkate almaz.
AG düğümlerini Kurtarma Hizmetleri kasasına kaydetme
Kurtarma Hizmetleri kasası, veritabanlarının yalnızca kasayla aynı bölgedeki ve abonelikteki VM'lerden yedeklendiğini destekler.
- Birincil düğümü kasaya kaydetmeniz gerekir (aksi takdirde tam yedeklemeler gerçekleşemez).
- Yedekleme tercihi yalnızca ikincilse kasaya en az bir ikincil düğüm kaydetmeniz gerekir (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 başvuru olarak ele alalım.
Yukarıdaki ö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 işleme
AG ikincil düğümlerden birine yük devrettikten sonra:
- Kasaya kayıtlıysa, tam ve değişiklik yedeklemeleri yeni birincil düğümden devam eder.
- Günlük ve yalnızca kopyalama tam yedeklemeleri, yedekleme tercihi temelinde birincil/ikincil düğümden devam eder.
Not
Yük devretme bir yedeklemeyle çakışmazsa yük devretmede günlük zinciri kesmeleri gerçekleşmez.
Yukarıdaki örnek AG dağıtımına bağlı olarak, çeşitli yük devretme olasılıkları aşağıda verilmiştir:
- VM2'ye yük devretme
- VM2'den tam ve değişiklik yedeklemeleri gerçekleşir.
- Yedekleme tercihi temelinde VM1 veya VM2'den günlük ve yalnızca kopyalama tam yedeklemeleri gerçekleşir.
- 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.
- VM4'e yük devretme (başka bir bölge)
- 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/değişiklik yedeklemeleri yalnızca birincil düğüme sahip kasada başarıyla gerçekleşir. Diğer kasalardaki bu yedeklemeler başarısız olur.
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.
Not
Günlük yedeklemelerinin başarısız olmasına 15 gün daha fazla sabit bir sınır vardır.
Yalnızca kopya tam yedeklemeler tüm kasalarda ç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
- Birincil düğümün Kasa 2'de mevcut olması için AG'nin VM3'e yük devretmesi.
- Kasa 2'deki AG veritabanları için yedeklemeleri yapılandırın.
- Bu noktada:
- Kayıtlı düğümlerin hiçbiri bu yedeklemeyi alamamasından, Kasa 1'de tam/değişiklik yedeklemeleri başarısız olur.
- Günlük yedeklemeleri, Kasa 2'de çalışana ve Vault 1 için günlük zincirini kırana kadar Vault 1'de başarılı olur.
- 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'daki tam ve değişiklik yedeklemeleri başarısız olur. Günlük yedeklemeleri, günlük zinciri sonu gerçekleşene/15 gün geçene kadar devam edebilir.
AG veritabanında yedekleme işleri için azaltma
Şu anda yedekleme azaltma 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ğundan, dengesiz AG düğümlerinin 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'in zamanlanmış 55 veritabanı yedekleme işi varken Node 2'de yalnızca 5 veritabanı yedekleme işi vardır. Ayrıca, tüm bu yedeklemeler saatte bir aynı anda çalışacak şekilde yapılandırılır. Bir noktada Düğüm 1'de 55 yedeklemenin tümü tetiklenir ve bunların 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, Node 1'in devre dışı olduğunu ve bu nedenle oradan gelen işlerin eşitleme için gelmeyeceğini varsayabilir. 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ı azaltma sınırından fazlaysa 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:
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, VERITABANı benzersiz adı olarak SQL örneği veya AG adı\Veritabanı adı olarak kabul eder. Tek başına veritabanı korunduğunda benzersiz adı StandAloneInstanceName\DBName'tir. 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 olur: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.
Veritabanının AG'nin altından koruma için yapılandırılması gerekir. 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ının tek başına örneğin altında koruma için yapılandırılması gerekir. Bu, ayrı bir kurtarma noktası zincirine sahip yeni bir veri kaynağı olarak ele alınacaktır. Ag veritabanının eski koruması, gelecekteki yedeklemelerin tetiklenmesi ve üzerinde başarısız olmasını önlemek için verileri saklama ile durdurulabilir.
Ag'ye düğüm ekleme/kaldırma
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 Backup hizmeti bu yeni düğümü AG yedeklemelerini gerçekleştirmek için gerekli meta verilerle yapılandıran bir iş akışı tetikler.
Bundan sonra, yeni düğüm Azure Backup hizmetinden AG yedekleme zamanlaması bilgilerini eşitler ve eşitlenen 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 tetiklendiğinde, AG yedeklemeleri için de düğümün yeniden yapılandırılması zorlanır. 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 AG'den kaldırmanı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'lerin yeniden oluşturulması, 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
Şunları nasıl yapacağınızı öğrenin: