SQL Server Log Shipping Mimarisi nedir? Log Shipping Nedir? Log Shipping Kurulumu nasıl yapılır?
Merhabalar
Bu yazımda MS SQL Server mimarisi olan LOG SHIPPING mimarisinden ve kurulumundan bahsettim.
Log Shipping Nedir?
Log Shipping, Primary veritabanında meydana gelen değişikliklerin (inserts, updates, deletes) Secondary veritabanına aktarılmasını sağlar. Bu işlem, düzenli olarak alınan transaction log yedeklerinin bir veya birden fazla Secondary sunucuya uygulanmasıyla gerçekleşir.
Log Shipping, genellikle şunlar için kullanılır:
- Felaket Kurtarma (Disaster Recovery): Primary Sunucu Arızalandığında Secondary sunucudan devam etmeyi sağlar.
Burada tabiki herkesin aklındaki soru Veri Kaybı evet burada bir veri kaybı olacaktır. Bunun sebebi alınan son transaction log backup sonrasında yapılan işlemler Secondary sunucuda bulunmayacaktır.
Kısaca özetlemek gerekir ise Her 10 Dakikada bir Transaction Log backup alınan ortamda En son alınan Transaction Log backup saat 12:50 de alındığını düşünelim ve Primary sunucumuz arızalandığı saat ise 12:55 burada 5 dakika içerisinde gerçekleşen işlemlerin hiç biri Secondary sunucuda bulunmayacaktır.
- Readable Secondary (Standby/ Read-Only)
Secondary sunucuda Database modu StandBy modda kullanabilirsiniz yani sadece okunabilir modda kullanım sağlar.
daha detaylı bilgi için https://www.veritabani.org/sql-server-standby-restore-ile-istenidiginiz-zamana-geri-donus/
- Database Boyutu Büyük olan Ortamalar
Burada anlatmak istediğim AlwaysOn Mimarisinde bulunan Databaseslerin Veri boyutları 50 TB ile 500 TB arasındaki Databaselerin Failover Sonrası Secondary Sunucuda işlem verebilir olma durumu geçikebilir.
Bu durum arıza anında Primary sunucudaki Transaction işlemlerin ROLLBACK olması ve daha bir çok etkene göre uzamasına sebep olur. Veri kaybı göz ardı edilerek Log Shipping Yapılan Secondary sunucuda hizmet vermesi sağlanabilir.
Ayrıca Bu tip Databaselerde gerçeklebilecek yanlış bir Transaction işlemlerin (Insert,Update,Delete) Backupdan geri dönmek uzun süreceği için Geriden gelen Secondary sunucusudan eski halini alabilir. Yapılan yanlışı düzeltme fırsatı sağlayabilir. Örnek olarak 6 saat geriden gelmesi sağlanabilir.
Log Shipping Nasıl Çalışır?
- Primary Sunucuda Yapılan tüm işlemler transaction log’lara kaydedilir ve primary server üzerinde çalışan bir job yardımıyla belirlediğimiz sürelerde transaction log backup’ları alınarak secondary server’ın erişebileceği bir lokasyona kopyalanır.
- Secondary server, üzerinde Log Shipping için konfigüre ettiğimiz veritabanının bir kopyası bulunur.
- Primary server’da olduğu gibi secondary server’da da bizim belirlediğimiz sürede bir job çalışarak primary server üzerindeki veritabanından kopyalanan transaction log backup’larını okuyarak kendi üzerindeki veritabanına restore eder.
- Böylece belirlenen zaman kadar bir gecikmeyle primary server’ın bir kopyasını secondary server üzerinde elde etmiş oluruz.
Log Shipping Kurulumu
İlk olarak Databasesimizin Full yada Bulk Logged mode da olması gerekmektedir.
Yukarıdaki Görselde görüldüğü gibi Recovery Model kısmından veri tabanımızı hangi modda olduğunu görebiliriz ve değiştirebiliriz.
Aynı Şekilde Transaction Log Shipping Penceresine Tıklayarak Kuruluma başlıyoruz.
Log Shipping özelliğini aktif edebilmek için “Enable this as a primary database in a log shipping configuration” seçeneğini işaretlememiz gerekiyor.
NOT: Log Backupları Aldığımız Klasörde yetki kontrollerinin yapılması gerekiyor.
İlk olarak Backup alınacak yer ve ayarlamalar için “Backup Settings” kısmına tıklıyoruz.
- “Network path to backup folder” kısmı backupların alınacağı Path kısmıdır.
- “If the backup folder is located on the primary server, type a local path to the folder” ise Primary sunucu üzerine log backup alınacak ise Dizin Bilgisi girilir.
- “Delete files older than”: transaction log backuplarının ne kadar saklanacağı varsayılan olarak 72 saatten daha eski olan transaction log backup dosyaları belirttiğimiz klasörden silinecektir.
- “Alert if no backup occurs within”: Belirtilen zaman aralığında herhangi bir Transaction Log Backup alınmadığında SQL Server’ın bize uyarı vermesini sağlar.
Ardından Backup alacak Job Schedule‘ını ayarlıyoruz.
Backup job’ının 5 dakikada bir çalışmasını istiyorum bu nedenle ayarlarımızı aşağıdaki gibi yapıyorum.
Bu aşamaya kadar olan kısım Primary sunucudaki Backup ayarlamalarıydı buradan sonra Secondary Sunucudaki ayarlamalara geçiyoruz.
Aşağıdaki görseldeki gibi Add diyerek Secondary sunucumuzu ekleme işlemine başlıyoruz.
Connect olarak Secondary sunucumuzdaki işlemlere başlıyoruz.
Initialize Secondary Database kısmında 2 secenek göreceğiz.
Burada 1.YES seçerek ilerlersek Otomatik olarak Full Backup al ve Secondary sunucuya aç
2.YES seçerek ilerlersek var olan backup ‘ın bulunduğu PATH göstermemizi isteyecektir Veri Tabanımız Boyut olarak büyük ise bu seçenek seçilip ilerleyebilirsiniz.
Copy Files Kısmına geldiğimizde ise
Alınan Transaction Log Backup ların Kaydedileceği yer kısmı (Destination Folder for copied files) ekliyoruz.
Buraya kopyalanan Transaction Log Backup ların ne zaman silineceğini ayarlıyoruz.(Deleted copied files after)
En son Backup dosyasını başka yere kopyalayacak Jobımızın Schedule ‘ını ayarlıyoruz.
Restore Transaction Log kısmında ise Secondary sunucuda veri tabanın okunabilir olup olmayacağını seçiyoruz (İhtiyaçlara göre bu durum değişebilir.)
No Recovery Mode (Secondary Sunucuda Restoring modda kalmasını sağlar)
Standby Mode (Okunabilir modda açık kalacak şekilde Secondary sunucu üzerinden okuma yapılabilir.)
“Disconnect users in the database when restoring backups” seçeneğini seçersek restore edilirken buradaki bağlantıların sonlandırılması daha saglıklı çalışmasını sağlayacaktır.
En son Restore Job ‘ı için de Schedule ayarlaması yapıyoruz.
Başka bir sunucu üzerinden izlemek istenir ise Monitor sunucusu eklenebilir.
Burada ise Monıtor yapılacak olan sunucu Connect oluyoruz.
Jobımızı oluşturarak Monıtor sunucudan kontrol sağlayabilirsiniz.
Log Shipping kurulumdan sonra hatasız çalıştığını görmek için
İnstance Sağ tıklayarak –Reports–Transaction Log Shipping Status seçilerek durumuna baka bilirsiniz. “GOOD” yazıyor ise herşey çalıştığı anlamına gelmektedir.
Veri tabanımızın görüntüsü aşağıdaki gibi olup okunabilir modda çalışaçaktır.
0 Yorum