AlwaysOn properties’dan backup preferences kısmından backupların nereden alınıp nereden alınmayacağını seçebiliriz.
Prefer Secondary: Default olarak gelen kısımdır. Secondary makinayı öncelikli backup olarak belirliyorum. Neden bunu kullanmalıyız çünkü backup alma işlemlerinde bir CPU kullanımı oluyor disk üzerinde bir okuma yazma işlemi olduğunda buda performansı ciddi anlamda etkiliyor bunun için backupların öncelikle secondary makinadan olması gerekmektedir.
Herhangi bir AG altında bulunan veritabanımızın backup’ını almak istiyorsak backup alma işlemini AG yapımızı belirterek veya ola hallengren scriptleri ile backup almamız gerekmektedir. Ne kadar AG properties ekranından backup alınacak sunucuyu değiştirsek bile secondary sunucusudan backup işlemi gerçekleşmez. Secondary sunucusunda full backup sadece copy only yöntemiyle alınmaktadır. Secondary sunucusunda log backup hem copy only hem de normal bir şekilde alınmaktadır. Diff backup ise ne copy only nede normal bir diff backup şekilde alınmaz. Tabi bunlar AG altında bulunan veritabanları için geçerli bir özelliktir.
Soru: Secondary’den alınan COPY_ONLY Full yedeği ile Primary’den alınan Diff ve Log yedeklerini beraber dönebilir miyim?
Cevap: HAYIR.
SQL Server’da Differential (fark) yedekleri, asla bir COPY_ONLY Full yedeğe bağlanamazlar. Fark yedekleri her zaman kendinden önceki en son alınan Normal Full (Copy-only olmayan) yedeği baz alır.
- Sonuç: Eğer Primary’de Diff yedek alıyorsanız, bu yedek Primary’deki son normal Full yedeğe bakacaktır. Secondary’den aldığınız Copy-Only Full yedeğin üzerine bu Diff yedeğini restore edemezsiniz.
- Log yedekleri ise dönebilir: Copy-only Full üzerine Log yedeklerini (nereden alındığı fark etmeksizin) basabilirsiniz.
Log yedeklerini hem Secondary’de hem Primary’de farklı modlarda almak mantıklı mı?
Cevap: Bu yöntem büyük bir risktir. Log yedeklerinde COPY_ONLY kullanmak, log dosyasının içindeki “truncate” (temizleme) işlemini yapmaz.
- Eğer Secondary’de sürekli COPY_ONLY log alırsanız, log dosyası şişmeye devam eder.
- Eğer bir yerde “normal” log yedeği, bir yerde “copy-only” alırsanız, geri dönüş anında hangi yedeğin hangi LSN aralığını kapsadığını bulmak tam bir kabusa dönüşür.
Eğer Primary sunucuya yük binmesin istiyorsanız:
- Full ve Log yedeklerini sadece Secondary’den (Normal modda, copy-only değil) alın. AlwaysOn buna izin verir ve logları her iki tarafta da temizler.
- Diff yedekleme kullanmayın. Bunun yerine Secondary’den sık Full ve sık Log yedeği alın.
Secondary sunucuda alınan Log yedeği “Truncate” işlemini yapar.
Ancak burada çok kritik bir teknik detay var: SQL Server bu işlemi “iş birliği” içinde yapar. Süreç tam olarak şu şekilde işler:
Log Truncate Mekanizması Nasıl Çalışır?
- Siz Secondary sunucuda bir Log yedeği alırsınız.
- Secondary sunucu bu yedeği başarıyla tamamladığında, Primary sunucuya “Ben bu LSN (Log Sequence Number) aralığını yedekledim” bilgisini gönderir.
- Primary sunucu, bu aralığın hem Primary hem de tüm Secondary sunucularda diske yazıldığından emin olduktan sonra, kendi üzerindeki Transaction Log dosyasında (.ldf) bu alanı “yeniden kullanılabilir” (truncate edilmiş) olarak işaretler.
- Bir sonraki senkronizasyon döngüsünde bu bilgi tekrar Secondary’ye iletilir ve her iki tarafta da log alanı boşalmış olur.
Bir finans kurumunda Primary sunucu üzerindeki yükü azaltmak için yedekler şu şekilde yapılandırılmıştı:
- Full Backup: Haftada bir Secondary sunucudan (COPY_ONLY).
- Diff Backup: Her gün Primary sunucudan.
- Log Backup: 15 dakikada bir Primary sunucudan.
Yaşanan Olay: Çarşamba günü veritabanı bozuldu. Admin, Pazar günkü Full yedeği (Secondary’den alınan) döndü. Ardından Salı günkü Diff yedeğini dönmeye çalıştığında “The log scan number (LSN) passed is invalid” hatasını aldı.
Çünkü Salı günkü Diff yedeği, Primary sunucuda aylar önce alınmış olan (ve belki de silinmiş olan) son “Normal Full” yedeği arıyordu. Secondary’den alınan Copy-Only Full yedek, Diff yedeğinin “base” (temel) ihtiyacını karşılamadı.
Sonuç: Admin, Diff yedeklerini kullanamadı. Pazar günkü Full yedekten başlayıp, çarşamba gününe kadar olan tüm Log yedeklerini (yüzlerce dosya) tek tek sırayla dönmek zorunda kaldı. Recovery süresi 2 saat olması gerekirken 12 saate çıktı.
Şimdi bir database’in backup’ını alalım. Bakalım backup’ını nereye alıyor bunu gözlemleyelim.
Yukarıdaki ayarlamayı yaptıktan sonra aşağıdaki komutumuzu primary ve secondary sunucularında çalıştırıyoruz. İlk olarak kodumu primary olan sunucuda çalıştırıyorum. Bunun için ola hallangren scriptlerini kullanıyorum.
EXECUTE [dbo].[DatabaseBackup]
@AvailabilityGroups='SQLAG1',
@Directory = N'C:\BACKUP',
@CopyOnly ='Y',
@BackupType = 'FULL',
@Verify = 'Y',
@CleanupTime = 168,
@CleanupMode = 'AFTER_BACKUP',
@CheckSum = 'Y',
@Compress = 'Y',
@LogToTable = 'Y';
Backup işleminin primary sunucusu üzerinde gerçekleşmediğini görmüş oluyorum. Aynı komutu secondary sunucunda çalıştırdığımda backup işleminin başarılı bir şekilde gerçekleştiğini görmüş oluyorum.
EXECUTE [dbo].[DatabaseBackup]
@AvailabilityGroups='SQLAG1',
@Directory = N'C:\BACKUP',
@CopyOnly ='Y',
@BackupType = 'FULL',
@Verify = 'Y',
@CleanupTime = 168,
@CleanupMode = 'AFTER_BACKUP',
@CheckSum = 'Y',
@Compress = 'Y',
@LogToTable = 'Y';
Backup işleminin başarılı bir şekilde gerçekleştiğini görmüş oluyoruz.
Prefer Secondary yönteminin en önemli özelliği eğer Secondary sunucumuzda servisimiz kapanmış ise Primary sunucusu üzerinden backup işlemi gerçekleşmektedir. Aşağıdaki resimde secondary sunucusu servisinin kapandığını görmüş oluyoruz.
Secondary sunucu servisi kapandıktan sonra Primary sunucusu üzerinden backup işlemi gerçekleştiriyoruz.
Copy-only üzerine normal log backup alınırsa herhangi bir sorun ile karşılaşılmaz.
Bu makalede Prefer Secondary Yöntemi ile Backup Alma yöntemini görmüş olduk. Başka bir makalede görüşmek dileğiyle..
Ey iman edenler, sabırla ve namazla yardım dileyin. Gerçekten Allah, sabredenlerle beraberdir. Bakara Suresi, 153. Ayet
