Log Shipping, veri tabanı yönetim sistemlerinde özellikle Microsoft SQL Server için kritik öneme sahip, yüksek kullanılabilirlik ve felaket kurtarma (Disaster Recovery - DR) stratejilerinden biridir. Bu mimari, birincil sunucudan (Primary Server) ikincil bir veya daha fazla bekleme sunucusuna (Standby Server) işlem günlüğü yedeklerinin (transaction log backups) otomatik olarak aktarılması, geri yüklenmesi ve uygulanması prensibine dayanır. Temel amacı, birincil sunucuda meydana gelebilecek fiziksel arıza, donanım hatası veya veri merkezi kaybı gibi durumlarda minimum veri kaybı (RPO - Recovery Point Objective) ile hızlı bir şekilde (RTO - Recovery Time Objective) ikincil sunucuya geçişi sağlamaktır.
İşleyiş mekanizması üç temel adımdan oluşur: Yedekleme (Backup), Kopyalama (Copy) ve Geri Yükleme (Restore). İlk adımda, birincil sunucudaki işlem günlüğü yedekleri belirlenen bir zamanlamaya göre alınır. Bu işlem, veritabanının tam yedeğinden sonra çalışan artımlı ve düşük etkili bir yöntemdir. İkinci adımda, bu yedek dosyaları ağ üzerinden ikincil sunucu(lar)a taşınır. Son adımda ise ikincil sunucu, bu günlük yedeklerini sırayla uygulayarak kendisini birincil sunucuyla sürekli olarak senkronize tutar. Bu döngüsel süreç, veri kaybı penceresini daraltarak ikincil sunucuyu neredeyse gerçek zamanlı bir yansıma haline getirir.
Log Shipping'in çalışması için veritabanının tam kurtarma modelinde (FULL Recovery Model) olması zorunludur. Bu model, tüm işlemlerin günlüğe ayrıntılı bir şekilde kaydedilmesine olanak tanır, böylece herhangi bir noktaya geri dönüş mümkün olur. Basit veya Toplu İşlenmiş kurtarma modellerinde, işlem günlüğü yeterince detaylı tutulmadığından Log Shipping senaryosu çalıştırılamaz.
| Terim | Açıklama | Log Shipping'deki Rolü |
|---|---|---|
| Primary Database | Asıl, çevrimiçi ve kullanıcılar tarafından erişilen üretim veritabanı. | Log yedeklerinin kaynak noktası. Tüm işlemlerin başladığı sunucu. |
| Secondary (Standby) Database | Birincil veritabanının yedeği olan, genellikle salt okunur (read-only) veya NORECOVERY durumunda bekleyen veritabanı. | Log yedeklerinin uygulandığı hedef. Felaket durumunda devreye girer. |
| Transaction Log Backup | Veritabanında yapılan tüm değişikliklerin kaydını içeren .trn dosyası. | Taşınan ve senkronizasyonu sağlayan temel veri birimi. |
Log Shipping'in temel prensibi, süreklilik ve otomasyon üzerine kuruludur. Sistem yöneticisi, yalnızca ilk kurulum ve yapılandırmayı yapar; sonrasında süreç tamamen otomatik olarak işler. Bu otomasyon, günlük yedek alma aralıkları, dosya temizleme eşikleri ve bağlantı kesilirse yeniden deneme politikaları gibi parametrelerle yönetilir. Bu sayede, insan hatası riski minimize edilir ve sunucular arasındaki veri tutarlılığı sürekli olarak korunur. Basit ancak etkili bir mimaridir.
Log Shipping Mimarisi Bileşenleri
Log Shipping mimarisinin düzgün çalışması, birbirleriyle senkronize halde çalışan üç temel bileşen tarafından sağlanır. Bu bileşenler, birincil sunucuda bir iş (job), ikincil sunucularda ise iki ayrı iş olarak SQL Server Agent servisi altında yapılandırılır. Her bileşen belirli bir görevi yerine getirir ve bir sonraki adımın tetiklenmesini sağlar. Bu işlerin başarısız olması durumunda, yöneticileri uyarmak için izleme sunucusu üzerinden alarmlar (alert) tanımlanabilir.
İlk ve en kritik bileşen, Birincil Sunucu Yedekleme İşi'dir (Primary Server Backup Job). Bu iş, birincil veritabanında belirlenen aralıklarla (örneğin, her 15 dakikada bir) işlem günlüğü yedeği almakla sorumludur. Yedek tamamlandıktan sonra, dosya hem birincil sunucunun yerel diskinde hem de ikincil sunucuların erişebileceği bir paylaşılan ağ yolunda (network share) saklanır. Bu iş aynı zamanda, başarılı bir şekilde kopyalanıp geri yüklendikten sonra belirli bir yaş sınırını aşmış eski yedek dosyalarını temizler.
İkinci bileşen, İkincil Sunucu Kopyalama İşi'dir (Secondary Server Copy Job). Bu iş, her ikincil sunucuda ayrı ayrı çalışır. Görevi, birincil sunucuda oluşturulan yeni işlem günlüğü yedek dosyalarını belirlenen paylaşımdan veya yoldan almak ve kendi yerel diskine kopyalamaktır. Dosyaların başarıyla kopyalanıp kopyalanmadığını kontrol eder ve bir sonraki adım olan geri yükleme işini tetikleyebilir. Ağ performansı ve gecikmesi, bu işin verimliliğini doğrudan etkiler.
- Yedekleme İşi (Primary): Transaction Log yedeğini alır ve paylaşıma koyar.
- Kopyalama İşi (Secondary): Yedek dosyasını paylaşımdan alır ve ikincil sunucunun belirlenen klasörüne taşır.
- Geri Yükleme İşi (Secondary): Taşınan yedek dosyasını ikincil veritabanına uygular (restore).
Üçüncü ve son bileşen ise İkincil Sunucu Geri Yükleme İşi'dir (Secondary Server Restore Job). Bu iş, ikincil sunucunun yerel diskine kopyalanmış olan günlük yedek dosyalarını sırayla ve otomatik olarak ikincil veritabanına uygular. İkincil veritabanı, bu işlem sırasında genellikle "NORECOVERY" durumundadır; bu, daha fazla günlük yedeği uygulanmaya hazır olduğu anlamına gelir. Ancak, ikincil veritabanının salt okunur modda (STANDBY mode) yapılandırılması da mümkündür. Bu durumda, geri yükleme işi raporlama gibi amaçlarla veritabanına sorgu çalıştırılmasına izin verir, ancak her geri yüklemeden önce kullanıcı bağlantılarını kesmek zorunda kalır. Doğru geri yükleme modunun seçimi, bekleme sunucusunun nasıl kullanılacağını belirler.
Tüm bu bileşenlerin durumu, isteğe bağlı olarak yapılandırılan bir İzleme Sunucusu (Monitor Server) tarafından takip edilebilir. İzleme sunucusu, tüm yedekleme, kopyalama ve geri yükleme işlerinin geçmiş kayıtlarını (history) merkezi bir noktada tutar ve belirlenen eşiklerde gecikme olması durumunda operatörlere e-posta veya uyarı gönderir. Bu sayede, senkronizasyondaki bir kopukluk proaktif olarak tespit edilir ve müdahale edilir. Mimari, bu bileşenlerin her birinin güvenilir ve hataya dayanıklı (fault-tolerant) şekilde çalışmasına bağlıdır.
İş Akışı ve Operasyonel Süreç
Log Shipping iş akışı, bir otomatik döngü olarak tasarlanmıştır ve her adım bir sonrakini besler. Süreç, birincil veritabanındaki bir işlem günlüğü yedeğinin başarıyla tamamlanmasıyla başlar. SQL Server Agent, birincil sunucuda yapılandırılan zamanlamaya göre (örneğin, her 15 dakikada bir) tetiklenir ve veritabanının transaction log'unu belirtilen yerel yola ve ağ paylaşımına yedekler. Bu yedek dosyası, ikincil sunucuların erişimi için kritik bir köprü görevi görür.
Yedekleme tamamlandığında, ikincil sunucu(lar)daki Kopyalama İşi devreye girer. Bu iş, belirli aralıklarla birincil sunucunun yedek klasörünü veya ağ paylaşımını tarar ve henüz kopyalanmamış yeni .trn dosyalarını tespit eder. Dosyalar bulunduğunda, ikincil sunucunun kendi belirlenen "kopya hedefi" klasörüne aktarılır. Bu aşamanın başarısı, ağ bant genişliği, gecikme süresi ve dosya izinleri gibi faktörlere bağlıdır. Herhangi bir sorun olmazsa, dosya artık ikincil sunucunun yerel diskinde hazırdır ve sıra geri yükleme aşamasına gelir.
Geri Yükleme İşi, ikincil sunucunun yerel "kopya hedefi" klasöründeki yeni günlük yedeklerini alır ve bunları sırayla ikincil veritabanına uygular. Uygulama sırası çok önemlidir; dosyalar, birincil sunucuda alındıkları kronolojik sıra ile uygulanmalıdır. Bu iş, ikincil veritabanını NORECOVERY durumunda tutarak, gelecekteki yedeklerin sorunsuz bir şekilde uygulanmaya devam edebilmesini sağlar. Bu üç adımlı iş akışı (Yedekle-Kopyala-Geri Yükle), birincil veritabanı çevrimiçi olduğu sürece sürekli olarak tekrarlanır.
Operasyonel süreçte en kritik noktalardan biri, kesinti yönetimi ve manuel müdahale senaryolarıdır. Örneğin, ikincil sunucu bir süreliğine çevrimdışı kaldığında, birincil sunucuda alınan günlük yedekleri birikir. İkincil sunucu tekrar çevrimiçi olduğunda, Kopyalama İşi biriken tüm yedekleri sırayla aktarır ve Geri Yükleme İşi bunları toplu halde uygulayarak ikincil veritabanını en güncel duruma getirir. Bu, Log Shipping'in esnek ve dayanıklı yapısını gösterir. Ancak, birincil sunucuda donanım arızası gibi kalıcı bir sorun olması durumunda, operatörün manuel olarak rol değişimi (role switch veya failover) başlatması gerekir.
Rol değişimi basit bir işlem değildir ve planlı bir süreç gerektirir. Operatör öncelikle, birincil sunucuda kalan son işlem günlüğü yedeğini "kuyruk yedeği" (tail-log backup) olarak almalı ve bunu ikincil sunucuya manuel olarak kopyalayıp uygulamalıdır. Ardından, ikincil veritabanını RECOVERY durumuna getirerek kullanıcı erişimine açar. Son olarak, uygulama bağlantı dizelerini ve diğer bağımlılıkları yeni birincil sunucuya (eski ikincil) yönlendirmelidir. Bu süreç RTO'yu doğrudan etkiler ve düzenli tatbikatlar yapılmasını zorunlu kılar.
Senaryolar ve Kullanım Alanları
Log Shipping, öncelikle bir felaket kurtarma çözümü olarak konumlandırılır. Birincil veri merkezinin tamamen kullanılamaz hale gelmesi durumunda, coğrafi olarak uzak bir konumda bulunan ikincil sunucu, birkaç günlük yedeği farkla üretim ortamını devralabilir. Bu senaryoda amaç, iş sürekliliğini sağlamak ve kritik operasyonların durmasını engellemektir. Çoğu kuruluş için, dakikalar veya birkaç saatlik veri kaybının kabul edilebilir olduğu durumlarda, Log Shipping maliyet-etkin ve yönetimi nispeten basit bir DR seçeneği sunar.
İkinci önemli kullanım alanı, raporlama yükünü dağıtmaktır. İkincil veritabanı STANDBY (read-only) modda yapılandırıldığında, geri yükleme işlemleri arasındaki zaman dilimlerinde raporlama, analiz veya yedek sorguları (backup queries) çalıştırmak için kullanılabilir. Bu, birincil sunucu üzerindeki CPU ve I/O yükünü önemli ölçüde azaltarak performansı artırır. Özellikle ağır analitik sorguların çalıştırıldığı ortamlarda, bu salt okunur kopya bir değerli kaynak haline gelir. Ancak, geri yükleme işi her çalıştığında kullanıcıların bağlantısı kesileceğinden, bu kullanımın zamanlamasının iyi planlanması gerekir.
Bir diğer yaygın senaryo ise yedekli ve gecikmeli kopyalar oluşturmaktır. Bazı organizasyonlar, veri bozulması (data corruption) veya yanlışlıkla silme gibi mantıksal hatalara karşı koruma sağlamak ister. Log Shipping ile, ikincil sunucuya günlük yedeklerinin uygulanması kasıtlı olarak geciktirilebilir (örneğin, 4 saat). Böylece, birincil veritabanında fark edilen bir bozulma, gecikme süresi dolana kadar ikincil sunucuya yansımaz. Bu süre içinde operatör, bozulmamış durumdaki ikincil veritabanından bozuk veriyi kurtarma şansına sahip olur. Bu, mantıksal hatalara karşı basit bir koruma katmanı sağlar.
Log Shipping, ayrıca coğrafi dağıtım gerektiren senaryolarda da kullanılabilir. Örneğin, merkez ofisteki birincil sunucudan, şube ofislerdeki ikincil sunuculara log yedekleri taşınabilir. Bu, şube çalışanlarının yerel bir veritabanı örneğine düşük gecikmeyle erişmesini sağlarken, merkezle veri tutarlılığını korur. Eski bir veritabanı sunucusunu yeni ve daha güçlü bir donanıma taşırken de kullanışlıdır; kesinti süresini minimize etmek için son bir log yedeği ile geçiş tamamlanabilir.
Log Shipping, birden fazla ikincil sunucuya yedek göndermeyi destekler. Bu, katmanlı bir DR stratejisi oluşturmayı mümkün kılar: bir ikincil sunucu aynı veri merkezinde yüksek senkronizasyon için, diğeri ise uzak bir lokasyonda felaket kurtarma için kullanılabilir. Aynı zamanda, farklı ikincil sunucular farklı amaçlara (raporlama, yedekleme, test) hizmet edebilir.
Son olarak, test ve geliştirme ortamlarında da sıklıkla tercih edilir. Canlı üretim verilerinin neredeyse gerçek zamanlı bir kopyası, yazılım güncellemelerinin test edilmesi, performans deneyleri veya geliştiricilerin gerçek veriyle çalışması için kullanılabilir. Bu kullanım, üretim ortamına doğrudan erişim riskini ve yükünü ortadan kaldırır. Ancak, veri gizliliği düzenlemeleri (GDPR, HIPAA gibi) bu tür kopyaların güvenliğinin ve yönetiminin de aynı titizlikle yapılmasını gerektirir.
Diğer DR Çözümleri ile Karşılaştırma
Log Shipping, veritabanı yüksek kullanılabilirlik ve felaket kurtarma ekosistemindeki diğer popüler teknolojilerle kıyaslandığında, belirgin avantaj ve dezavantajlara sahiptir. En yaygın karşılaştırmalar, Database Mirroring, Always On Availability Groups ve Basit/İşlevsel Yedekleme-Restorasyon ile yapılır. Her birinin mimarisi, performans etkisi, başarısızlık senaryolarındaki davranışı ve maliyeti farklılık gösterir. Doğru çözümün seçimi, kuruluşun RPO ve RTO hedeflerine, bütçesine ve teknik uzmanlığına bağlıdır.
Always On Availability Groups (AG), SQL Server'ın en gelişmiş yüksek kullanılabilirlik ve felaket kurtarma çözümüdür. AG, veritabanı düzeyinde çalışır ve otomatik failover, birden fazla ikincil kopya, okunabilir ikinciller ve daha ince senkronizasyon kontrolleri sunar. Log Shipping'den temel farkı, veri senkronizasyonunu log seviyesinde değil, veri sayfası seviyesinde gerçekleştirmesidir. AG'de ikincil kopyalar sürekli olarak birincil ile iletişim halindedir ve senkron modda sıfır veri kaybı garanti edilebilir. Ancak, AG'nin kurulumu ve yönetimi daha karmaşıktır, Enterprise Edition lisansı gerektirir ve genellikle daha pahalı bir altyapı (Windows Server Failover Clustering, paylaşılan depolama gibi) ister.
| Kriter | Log Shipping | Always On Availability Groups | Database Mirroring (Eski) |
|---|---|---|---|
| Lisans Gereksinimi | Standard Edition ve üzeri | Enterprise Edition (Temel özellikler için) | Standard Edition ve üzeri |
| Senkronizasyon | Zamanlamaya bağlı, asenkron | Senkron veya asenkron seçilebilir | Senkron (Yüksek Güvenlik) veya Asenkron (Yüksek Performans) |
| Otomatik Failover | Yok (Manuel) | Var (Senkron modda) | Var (Yalnızca senkron modda ve tanık sunucu ile) |
| İkincil Kullanım | Salt okunur (STANDBY) veya yok | Salt okunur sorgular, yedekleme | Salt okunur değil (Snapshot kullanılabilir) |
| Veri Kaybı Riski (RPO) | Yedekleme aralığına bağlı (dakikalar/saatler) | Senkron modda sıfır, asenkron modda düşük | Senkron modda sıfır, asenkron modda olası |
| Karmaşıklık ve Maliyet | Düşük | Yüksek | Orta |
Eski bir teknoloji olan Database Mirroring ile karşılaştırıldığında, Log Shipping daha basit ve daha az kaynak tüketen bir yapı sunar. Mirroring, tek bir ikincil sunucu ile gerçek zamanlı veri aktarımı sağlar ve otomatik failover seçeneği vardır, ancak ikincil veritabanına doğrudan okuma erişimi sağlamaz (yalnızca database snapshot ile dolaylı olarak). Mirroring, TCP bağlantıları üzerinden çalışır ve ağ kesintilerine karşı daha hassastır. Log Shipping ise dosya tabanlı aktarım yaptığı için daha bağışıklıdır; ağ kesintisi olduğunda, bağlantı yeniden sağlandığında kaldığı yerden devam edebilir. Ayrıca, Log Shipping birden fazla ikincil sunucuyu desteklerken, Database Mirroring yalnızca bir tane ikincil sunucuya izin verir.
Temel yedekleme ve geri yükleme operasyonları ile kıyaslandığında ise Log Shipping'in ana avantajı otomasyon ve sürekliliktir. Manuel yedekleme/geri yükleme stratejilerinde, operatörün düzenli olarak yedek alması, dosyaları taşıması ve geri yüklemesi gerekir. Bu süreç hataya açıktır ve RTO'yu uzatır. Log Shipping, tüm bu adımları otomatikleştirerek insan hatası riskini azaltır ve felaket anındaki kurtarma süresini öngörülebilir hale getirir. Ancak, manuel yedeklemeler daha fazla esneklik sunar (örneğin, farklı zaman noktalarına geri dönüş), oysa Log Shipping'de veri akışı doğrusaldır ve belirli bir noktaya geri dönmek daha karmaşıktır.
Sonuç olarak, Log Shipping maliyet-etkin, sağlam ve yönetimi görece basit bir DR çözümü olarak öne çıkar. Yüksek lisans maliyetlerinden kaçınan, otomatik failover'ın kritik olmadığı, dakikalar mertebesindeki veri kaybının kabul edilebildiği ve ikincil sunucuyu raporlama gibi amaçlarla kullanmak isteyen ortamlar için ideal bir seçimdir. Daha yüksek kullanılabilirlik seviyeleri gerektiğinde ise Always On Availability Groups gibi daha sofistike teknolojilere geçiş yapılmalıdır.
Avantajları ve Sınırlamaları
Log Shipping'in en büyük avantajı, kurulum ve yönetim kolaylığıdır. SQL Server Management Studio (SSMS) üzerindeki sihirbazlar aracılığıyla, birkaç adımda yapılandırılabilir. Bu, ek bir uzmanlık veya karmaşık küme yapılandırmaları gerektirmez. İkinci önemli avantajı maliyet etkinliğidir. Enterprise Edition lisansı gerektirmez; Standard Edition ile tam fonksiyonel olarak çalışabilir. Ayrıca, özel depolama alanı ağı (SAN) veya paylaşılan disk kümeleri gibi ek donanım yatırımlarına ihtiyaç duymaz. Mevcut sunucular ve ağ altyapısı üzerinde uygulanabilir.
Sistemin dayanıklılığı ve esnekliği bir diğer artı noktadır. Ağ veya sunucu kesintileri sırasında, birincil sunucuda alınan yedekler birikir. Bağlantı yeniden sağlandığında, işlem kaldığı yerden devam eder ve tüm birikmiş yedekler otomatik olarak işlenir. Bu, geçici sorunlara karşı güçlü bir tolerans sağlar. Ayrıca, birden fazla ikincil sunucu desteklenerek katmanlı bir kurtarma stratejisi oluşturulabilir. Bir ikincil sunucu aynı lokasyonda raporlama için, diğeri uzak bir DR sitesinde koruma için kullanılabilir. İkincil veritabanının salt okunur moda getirilebilmesi, kaynak kullanımını optimize etme imkanı tanır.
Ancak, Log Shipping'in önemli sınırlamaları da vardır. En kritik sınırlama, kurtarma noktası hedefinin (RPO) yedekleme aralığına bağlı olmasıdır. Birincil sunucu, son yedek alındıktan hemen sonra çökerse, o aralıkta yapılan tüm işlemler kaybolur. Bu nedenle, sıfıra yakın RPO gerektiren kritik sistemler için uygun değildir. İkinci büyük sınırlama, otomatik failover mekanizmasının olmamasıdır. Birincil sunucu fail olduğunda, operatörün manuel olarak rol değişimini başlatması, son kuyruk yedeğini alması ve uygulama bağlantılarını yönlendirmesi gerekir. Bu süreç, kurtarma süresi hedefini (RTO) uzatır ve hata riski taşır.
Diğer bir sınırlama ise veritabanı düzeyinde koruma sağlamasıdır. Log Shipping, tek bir veritabanı veya bir grup veritabanı için yapılandırılır, sunucu düzeyindeki nesneleri (logins, jobs, linked servers) korumaz. Failover sonrasında bu nesnelerin ikincil sunucuyla senkronize edilmesi ayrı bir prosedür gerektirir. Ayrıca, ikincil veritabanı salt okunur modda kullanıldığında, her geri yükleme işlemi öncesinde mevcut kullanıcı bağlantılarının kesilmesi gerekir, bu da kesintili bir raporlama deneyimi anlamına gelebilir. Son olarak, geniş ve sık değişen veritabanlarında, büyük transaction log yedekleri ağ bant genişliği üzerinde baskı oluşturabilir ve ikincil sunucudaki geri yükleme işlemi birikmelere neden olabilir.
Özetle, Log Shipping sağlam, ekonomik ve güvenilir bir felaket kurtarma ve veri dağıtım aracıdır. Otomasyonu, esnekliği ve düşük bakım maliyeti ile özellikle orta ölçekli işletmeler ve kritik olmayan sistemler için mükemmel bir seçenektir. Ancak, yüksek kullanılabilirlik (High Availability) gereksinimleri, sıfıra yakın RPO/RTO hedefleri veya otomatik failover ihtiyacı olan senaryolarda, Always On Availability Groups gibi daha gelişmiş çözümlerin değerlendirilmesi gerekir. Doğru teknoloji seçimi, iş ihtiyaçlarının teknik kabiliyetlerle dikkatlice tartılmasını gerektirir.