MSSQL Server AlwaysOn’da Secondary Only Yöntemi ile Backup Alma

Bu makalede Alwayson yapımızda secondary only yöntemiyle backup alma işlemini ele almış olacağız. Primary yöntemiyle backup alma işleminin tam tersi olarak karşımıza çıkmaktadır. Bu yöntemle backuplarımızın sadece secondary sunucusu üzerinden backup alma işlemini yapmış olacağız.

Not: Herhangi bir AG altında bulunan veritabanımızın backup’ını almak istiyorsak backup alma işlemini sadece AG yapımızı belirterek 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 hemde 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?

1. Siz Secondary sunucuda bir Log yedeği alırsınız.
2. Secondary sunucu bu yedeği başarıyla tamamladığında, Primary sunucuya “Ben bu LSN (Log Sequence Number) aralığını yedekledim” bilgisini gönderir.
3. 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.
4. 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ı:

1. Full Backup: Haftada bir Secondary sunucudan (COPY_ONLY).
2. Diff Backup: Her gün Primary sunucudan.
3. 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ı

Herhangi bir AG properties ekranında Secondary only yapısı aktif edilir.

İlk olarak primary sunucusu üzerinden backup işlemini gerçekleştirelim.

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';

Yukarıdaki komutu Primary olan replicamız üzerinde bulunan ilgili AG altında çalıştırdığımızda bu replicadan backup alınamayacağına dair mesaj almış oluruz. Copy only ifadesi eklenmesi primary sunucusu üzerinden backup işlemi gerçekleşmektedir.

Aynı komutu secondary sunucusu üzerinde çalıştırdığımızda işlemin başarılı ile sonuçlandığını görmüş oluyoruz. İlgili komutun secondary sunucusunda çalıştırılması yeterli değildir. Backup komutumuzun içeriğine copy_only seçeneğinin eklenmesi gerekmektedir.

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';

Aşağıdaki ekran resminde backup’ın secondary sunucusunda başarılı bir şekilde alındığını görmüş oluyoruz.

Aşağıdaki komutta AG yapımızı belirtmezsek bile availability group üzerinden primary sunucusundan backup almadığını sadece stand alone veritabanlarında backup işleminin gerçekleştiğini görebiliriz.

EXECUTE [dbo].[DatabaseBackup]
@Databases='USER_DATABASES',
@Directory = N'C:\BACKUP',
@CopyOnly ='Y',
@BackupType = 'FULL',
@Verify = 'Y',
@CleanupTime = 168,
@CleanupMode = 'AFTER_BACKUP',
@CheckSum = 'Y',
@Compress = 'Y',
@LogToTable = 'Y';

Aynı komutu secondary sunucusunda çalıştırıldığında backup’ın başarılı bir şekilde alındığını görmüş oluyoruz.

Resimde dikkat ederseniz sadece Secondary only seçeneği aktif olan AG yapımızın backup’ının alındığını görmekteyiz. Stand alone veritabanları için bir sıkıntı olmadığını dile getirmiştik.

Log backup işleminin primary sunucu üzerinde sadece stand alone veritabanlarında gerçekleştiğini görmüş oluyoruz.

EXECUTE [dbo].[DatabaseBackup]
@Databases='USER_DATABASES',
@Directory = N'C:\BACKUP',
@BackupType = 'LOG',
@Verify = 'Y',
@CleanupTime = 168,
@CleanupMode = 'AFTER_BACKUP',
@CheckSum = 'Y',
@Compress = 'Y',
@LogToTable = 'Y';

Bu makalede Secondary Only Yöntemi ile Backup Alma işlemini görmüş olduk. Başka bir makalede görüşmek dileğiyle..

“Demek ki, zorlukla beraber bir kolaylık var.” İnşirah-5