Bu makalede Log Shipping kavramını ele almış olacağız Ortak bir paylaşım klasörüne log backupların atılarak ikinci sunucuda bu loglar restore edilerek sistemin kısa sürelide olsa bir kesintiden sonra ayağa kalkmasını sağlamaktır. Oluşturacağımız her adımda system arka plan bir job oluşturmaktadır. Veritabanı seviyesinde yapılan bu işlemde recovery model full olması gerekmektedir.
Burada sıkıntı aktif pasif çalışması durumudur. Burada herhangi bir arıza durumunda kullanıcıları veya connection stringleri manuel bir şekilde değiştirmem gerekiyor. Failover mode olmadığı için kullanmak mantıklı değildir. Gerçek sistemde sisteme getirilecek yükü azaltmak için ikinci bir sunucu üzerinde raporlama amaçlı kullanılabilir.
Log shipping kurulumuna başlamadan önce Transaction log dosyalarını tutacağımız bir paylaşım klasörü yapacağız.
Uygulamalı bir şekilde yapmak için ilk başta bir database oluşturuyorum. Daha sonra bu database’de bir tablo oluşturup içerisine bir değer insert edelim. Buradaki amaç log shipping yaptıktan sonra insert edilen değerlerin ikinci sunucudaki database’e kaydedilip kaydedilmediğini görmek.
İnstance altında bulunan Databases > New Database diyiyoruz.
Veritabanımızı oluşturduktan sonra sıra geldi bir tablo oluşturmada içine manuel değerler insert etmede. TARIH adında tablomuzu oluşturduktan sonra içerisine manuel bir değer insert ettik.
Bu işlemleri yaptıktan sonra şimdi ise veritabanı üzerinde log shipping özelliğini aktif etmede.
Veritabanı üzerine sağ tıklanır properties kısmına gelinir.
Gelen ekranda Transaction Log Shipping sekmesine gelinir. İlgili Enable this as a primary database in a log shipping configuration checkbox’ı aktif edilir.
Transaction Log Shipping sekmesini aktif ettikten sonra Transactions log backups bölümünde bulunan Backup Settings.. kısmına tıklanır.
Gelen ekranda Backup job bölümünde Job Name kısmında job’a bir isim verdikten sonra Schedule kısmına tıklayarak backup için gerekli olan zaman konfigürasyonunu yapmam gerekiyor. Default olarak 15 dakika ayarlanmış onun düzenlenmesini yapalım. Bu işlem primary sunucusunda backup alınacak job’ın ne kadar sürede bir çalışacağını belirleyen yapı. Gerçek sistemlerde default şeklinde bırakılmaktadır.
Gelen ekranda kaç dakikada bir Log Backup almak istiyorsak onu seçeriz. 30 sn’de bir transaction log backup alacak şekilde ayarlamaları yaparız.
Alacağımız transaction backup’ı sıkıştırarakmı yoksa varsayılan olarak mı alacağımız seçenek karşımıza çıkıyor.
Db boyutum küçük olsa bile sıkıştırarak alıyorum. Daha sonra backuplarımı alacağım bir paylaşım klasörü oluşturmam gerekiyor. Çünkü primary sunucuda oluşturacağımız klasöre yukarıda tanımladığımız job’ımız backup alacak ikinci sunucuda bu klasörden kendi üzerinde bulunan klasöre kopyalayıp üzerindeki restore job ile backup restore işlemi tabi tutacak.
Bunun için backup diskimin altında ABC diye bir klasör oluşturuyorum ve buna paylaşım yetkisi veriyorum. Çünkü farklı bir sunucunun bu klasöre ulaşması gerekiyor.
Aşağıdaki resimde belirtilen not bölümünde “If you backup the transaction logs of this database with any other job or maintenance plan, Management Studio will not be able to restore the backups on the secondary server instances.”
Bu database’in transaction log’ları BAŞKA BİR YEDEKLEME Job’ı ile alınırsa:
- Log shipping BOZULUR
- Secondary sunucular restore edemez
- Data kaybı riski oluşur
Sql server üzerinde bulunan backup joblarından Log shipping yapılacak veritabanı çıkarılır. Veritabanı küçükse çıkarılması log shipping başlamadan önce gerçekleşir. Veritabanı büyük ise ilk başta secondary sunucuya veritabanının Full backup’ının NoRecovery modunda restore edilmesi gerekmektedir. log shipping başlatılacak sunucuda en son log backup log shipping yapılacak sunucuda Restoring modda olan veritabanı üzerine NoRecovery modunda eklenmesi gerekmektedir. Yani log shipping başlamadan önce trn uzantılı tüm log dosyalarının log shipping yapılacak sunucuda Restore edilmiş olması gerekmektedir.
S2 sunucusunda(primary olan sunucu) BACKUP diskimin altında ABC diye bir klasör oluşturuyorum.
ABC klasörümün üzerine sağ tıklayıp properties’den Sharing bölümüne geliyorum.
Daha sonra alt kısımda bulunan Advanced Sharing sekmesine tıklanır.
Advanced sharing sekmesine tıkladıktan sonra gelen ekranda Share this folder checkbox’ını aktif ettikten sonra alt kısımda bulunan Permissions kısmına tıklanır.
Gelen ekranda Everyone’a full kontrol yetkisi verilmesi tavsiye edilmez. Sql server’ın yapacağı tüm işlerde database engine’a tanımladığımız sql server servisi sorumludur.
Servisimiz aşağıda gözükmekte.
Bunun için add kısmına tıklayıp active directory üzerinden servisimizi seçiyoruz ve full kontrol yetkisi veriyorum.
Servisi ekledikten sonra Full kontrol yetkisi veriyorum.
Apply dedikten sonra gelen ekranda tekrardan işlemleri onaylıyorum ve paylaşım yolunu kopyalıyorum.
Şimdi oluşturmuş olduğum sharing yolunu kopyalayalım. Şunu belirtmek gerekirse S1 ve S2 sunucusu aynı network içerisinde olduğu için S1(secondary) sunucusu bu paylaşım klasörünü görmüş olacak.
Garanti olması açısından zaten bizim yukarıdaki kısımlarda klasörü okuma yetkisi verdik sadece okuma değil yazma yetkiside verilebilir. Yukarıdaki ekran görüntüsündeki Share kısmına tıklanır.
Gelen ekrana sql servis hesabımız yazılır ve add kısmına tıklanır. Aşağıdaki resimde dikkat edersek default olarak read yetkisine sahip herhangi bir sıkıntı yaşamamak için read write yetkisi verilebilir.
Bu ayarlamalardan sonra Share denilip çıkılır.
Paylaşım yolunu kopyalayıp transaction log shipping kurulum ekranına yapıştırıyorum.(\\S2\abc) Bu yapıştırdığımız uzantı log backup’ı nereye almak istiyorsak o uzantı yazılır.
İkinci seçenekte paylaşım yeri network’de değil de bu makine üzerindeyse yazmamızı istiyor. Yazılmamasında herhangi bir sakınca yoktur. Genellikle paylaşım yolu tercih edilir. Aynı instance altında log shipping yapımızı oluşturacaksanız normal klasör yolu verilebilir.
Yukarıdaki ayarlamaları yaptıktan sonra alt kısımda hangi zamandan önceki dosyaları silmemiz gerektiğini söylüyor.
Delete files older than kısmından kaç saat sonra eski backup’ların silineceğini, Alert if no backup occurs within kısmından da backup alınmamışsa kaç saat sonra alert üreteğini ayarlayabilirsiniz.
Log dosyalarının yedeklerini kaybetmemek için Delete files older than kısmının dikkatli seçilmesi gerekmektedir. Bu kısım neden önemli: Temel olarak bir Retention Policy (Saklama Politikası) yönetimidir. Yedekleme dosyaları zamanla disk alanınızı tamamen doldurabilir. Eğer eski yedekler otomatik silinmezse, disk dolar ve yeni (güncel) yedekler alınamaz hale gelir. Özellikle bulut depolama kullanıyorsanız, gereksiz her GB için ekstra ücret ödersiniz. Onlarca eski yedek arasından doğru olanı bulmak zordur.
“Alert if no backup occurs within” kısmı, sistemin pasif bir izleme (monitoring) yapmasını sağlar. Yazılım, son başarılı yedekleme işleminin ne zaman bittiğine dair bir log (kayıt) tutar. Siz burada “1 saat” dediğinizde, sistem sürekli şu kontrolü yapar: Şu anki zaman – Son başarılı yedekleme zamanı > 1 saat mi diye bakar. Eğer aradan geçen süre 1 saati aşmışsa, sistem bir hata durumu (trigger) oluşturur. Bu ayar sadece “Yedek dosyası oluştu mu?” sorusuna bakar. Eğer yedekleme job’ı bir hata nedeniyle yarıda kalırsa veya hiç başlamazsa, belirlenen süre (1 saat) sonunda size e-posta, SMS veya sistem bildirimi yoluyla uyarı gönderir.
Bu mekanizma bir “ölü adam anahtarı” (dead man’s switch) gibidir. Sistemden düzenli olarak “ben iyiyim, yedeği aldım” sinyali gelmezse, alarm çalar.
Default değerlerle bırakıp OK deyip primary makinamda işlemlerimi tamamlıyorum.
Ok ikonuna bastıktan sonra şimdi ise gelen ekranda secondary makine için bu ayarlamaları yapmak var. Bu işlemlerin hepsi primary olan sunucuda yapılıyor.
Yukarıdaki resimde Add ikonuna tıkladıktan sonra aşağıdaki ekran karşımı gelmekte burada connect ikonuna tıklayıp S1 sunucuma bağlantı işlemlerimi yapıyorum. Benim şuan S1 sunucum secondary, S2 sunucusu primary sunucusu..
İşaretlemiş olan Yes, generate a full backup of the primary database and restore it into the secondary database (and create the secondary database if it doesn’t exist) seçeneğinde primary veritabanının tam yedeğini alır ve secondary (ikincil) sunucuya geri yükler. Eğer secondary sunucuda ilgili veritabanı yoksa, otomatik olarak oluşturulur. Yeni bir Log Shipping yapılandırması oluştururken bu seçeneği kullanabilirsin.
Bu işlemler sıralı (sequential) yapılır. Yani:
- Önce Primary sunucuda Full Backup alınır (Disk I/O tavan yapar).
- Yedek biter bitmez ağ üzerinden Secondary sunucuya kopyalanır (Network bant genişliği dolar).
- Secondary sunucuda Restore başlar (Secondary sunucu yorulur)
Ayrıca yukarıdaki işlem aynı zamanda log dosyasının şişmesinede sebep olmaktadır.
Restore options kısmında ikinci sunuda oluşturulacak veritabanın mdf ve ldf uzantıların hangi uzantıda oluşturacağını seçiyoruz.
Yes, restore an existing backup of the primary database into the secondary database (and create the secondary database if it doesn’t exist) ile başlayan kısmı seçersek primary veritabanının daha önce alınmış bir yedeği varsa, onu kullanarak secondary sunucuda aynı veritabanını oluşturur. Bu işlem için bir ağ yolunda (network path) bulunan bir yedek dosyasını (backup file) belirtmek gerekir. Mevcut bir yedeği manuel olarak yükleyerek Log Shipping başlatmak için kullanılır. Eğer yedeği aldığınız andan itibaren çok fazla işlem yapıldıysa ve Transaction Log’lar ezildiyse, yedek geri yüklense bile “Log Chain” (günlük zinciri) bozulduğu için senkronizasyon başlamayabilir.
No, the secondary database is initilalize kısmını seçerseniz, ikincil veritabanının zaten oluşturulduğunu ve restore işleminin yapılmayacağını belirtir. Yani primary sunucudan bir full backup alınmasına veya restore edilmesine gerek yoktur. Çok büyük veritabanlarında (VLB – Very Large Databases). Yedeği harici bir diskle taşıyıp kendiniz NORECOVERY modunda geri yüklediğiniz durumlarda en güvenli yoldur. En kontrollü yöntemdir. SSMS’in zaman aşımına uğraması (timeout) gibi sorunların önüne geçer.
Manuel işlem gerektirir. Eğer veritabanını WITH RECOVERY (erişilebilir modda) açtıysanız, sistem çalışmaz. Mutlaka NORECOVERY modunda bekliyor olmalıdır. En büyük sıkıntı “LSN mismatch” (LSN uyuşmazlığı) hatasıdır. Eğer ikincil sunucudaki veritabanı, birincil sunucunun güncel durumundan çok geride kaldıysa aradaki fark kapatılamaz ve her şeye baştan başlamanız gerekir.
Kısacası No, the secondary database is initilalize yöntemiyle ile veritabanının full backup’ı alınıp restore işleminin yapılması gerekmektedir. log shipping yapısı başlatılmadan önce tüm trn uzantılı log dosyalarının restore edilmesi gerekmektedir. Artık restore edilecek log dosyası kalmadıktan sonra log shipping yağısı başlatılır.
Bu seçeneği seçip iki farklı sunucuya Restore işlemi yapılıp Log Shipping özelliği başlatılabilir.
Hangi Seçeneği Kullanmalısın?
Yeni bir Log Shipping yapılandırması yapıyorsan ve secondary veritabanın yoksa: 1. Seçenek (Yes, generate a full backup…)
Zaten bir backup aldıysan ve manuel restore etmek istiyorsan: 2. Seçenek (Yes, restore an existing backup…)
Secondary veritabanı zaten hazırsa ve sadece Log Shipping’i devam ettirmek istiyorsan: 3. Seçenek (No, the secondary database is initialized)
Daha sonra Copy Files sekmesine geçilir. İkinci sunucuda kopyalar hangi klasör içerisinde dursun oluşturduğumuz secondary(S1) sunucusundaki klasörü yazıyoruz. Bu klasörün paylaşım klasörü olmasına gerek yok. Destination folder for… ile başlayan kısma secondary sunucudaki lokal bir path’i yazmalısınız. Secondary sunucusunda oluşturulan klasörde sql server servis hesaplarının yetkisi olması gerekmektedir. Delete copied files after yazan kısım kopyalanan backup’ın 72 saat sonra silineceğini gösterir.
Bu işlemleri yaptıktan sonra alt tarafta bulunan Copy Job kısmında kopyalama işlemlerinin ne kadar süreyle olacağını belirtiyoruz. Kısacası aşağıdaki copy job ile paylaşım klasöründen log dosyasını alır belirtmiş olduğumuz disk uzantısına kaydetmektedir.
Bu ayarlamaları yaptıktan sonra Restore Transaction Log bölümüne geçilir.
Bu kısım ikinci sunucuda log backuplar restore edilirken veritabanın davranış şeklini belirtir. No recovery mode veritabanını restoring moduna sokar bu da ulaşılmasını engeller. Yani secondary sunucunda kullanıcılar select çekemez. No recovery moda değişmediği müddetçe biz veritabanına ulaşamayız.
Biz burada ikinci seçenek olan Standby mode’u seçiyoruz ne zaman veritabanı restoring moda girerse kullanıcıların bağlantısını keser. Veritabanı ne zaman kopyalamış olduğu log’u üzerine dönerse veritabanı ulaşılamaz olur yoksa erişilebilir haldedir. Standby modunun altında bulunan Disconnect users in the database when restoring backups seçenek ise veritabanına restore yapılmadan önce kullanıcı varsa ilgili kullanıcının bağlantısını koparır.
Delay Restoring Backups At Least: Bir hata veya yanlışlıkla yapılan bir işlem primary veritabanında gerçekleşirse, gecikmeli restore sayesinde bu hatayı fark edip geri alma şansı sağlar. Örneğin, bir kullanıcı yanlışlıkla önemli bir tabloyu sildi. Eğer log restore işlemi gecikmeli yapılandırılmışsa, bu hatayı fark edip primary sunucudaki bir backup veya point-in-time recovery ile düzeltme yapabilirsiniz. Örnek: Delay Restoring Backups At Least = 30 dakika ise, primary sunucuda alınan her Transaction Log yedeği, secondary sunucuda en az 30 dakika bekletildikten sonra restore edilir. Kısacası Log Shipping restore işlemini geciktirerek yanlış işlemlerden kaçınma şansı tanır.
Alert If No restore occurs within: Eğer belirlenen süre içinde primary sunucuda yeni bir log yedeği alınmazsa, log shipping’in çalışmadığını veya bir hata olduğunu gösteren bir uyarı üretir.
Daha sonra ikinci sunucumda bir restore işlemi için aşağıda belirtilen Schedule bölüme girip 1 dakikalık arayla restore edilmesi gerektiğini söylüyor. Bu joblar kendiliğinden oluşuyor biz sadece Schedule tanımlıyoruz.
Schedule bölümüne tıkladıktan sonra 1 dakika bir restore etme schedule’nı tanımlıyorum.
Ok tuşuna basıp secondary sunucusunda ayarlamaları yaptıktan sonra ana ekrana gelip tekrar ok tuşuna basıp işlemi sonlandırıyoruz.
Ok ikonuna bastıktan sonra gelen ana kurulum ekranında da ok tuşuna basıp işlemlerimizi sonlandırıyoruz.
Şunu da belirtmek gerekir aşağıdaki ekranda bulunan Use a monitor server instance kısmı backup almada kopyalamada veya restore işlemlerinde bir problem varsa bize bunun için alert üretiyor. Burada settings kısmında alert için bir alert job oluşturmamız gerekiyor. Açılan moniter server instance bölümünde alertlerimizi izleyeceğimiz bir instance belirtmemiz gerekiyor. Bu instance primary ve secondary sunucusuda olabilir. 3. Farklı bir instance seçmek daha faydalı olacaktır.
Başarılı bir şekilde sonuçlanmış oldu.
S2\TEST sunucum üzerinde belirtilen klasöre full backup aldıktan sonra log backup almaya başlıyor 30 saniyede bir. S1 sunucusuda full backup’ı log backup’ı restore işlemlerine tabi tuttu.
Şimdi S1\TEST sunucum da oluşturmuş olduğum klasöre bakayım restore edeceği belgeleri oluşturduğumuz klasöre alıyor mu. Aşağıdaki bak ve trn uzantıları primary sunucusunda(S1) paylaşım klasöründe alıyor.
S1\TEST sunucusunda backup restore edilmiş ve log backuplar restore ediliyor 1dk aralıklarla
S1\TEST sunucusunda görünüm şekli.
Şimdi ise primary olan S2 sunucusunda bir insert yapalım bakalım ne zaman restore işlemi gerçekleşiyor ve restore tam anlamıyla oluyor mu.
İkinci sunucuda(S1) hala değerlerim gelmedi.
Bir dakika schedule’da belirlediğim süre dolduktan sonra değerlerimin geldiğini görmüş oluyorum.
Yeni değerler insert ettiğimde bu değerlerinde belirli bir gecikmeyle geldiğini görmüş oldum.
Aşağıdaki resimde log shipping aktif edildikten sonra system tarafında oluşturulan joblar görülmektedir. Dikkat edersek paylaşım klasöründe kopyalayıp restore ediyor.
Log shipping oluşturulan sunucuda sadece Backup ve Alert jobları oluşmaktadır. Hedef sunucuda ise bu jobların yanında bir de copy job’ı oluşmaktadır.
Aşağıdaki resimde S2 sunucusunda sadece backup işlemleri için oluşturulan job’ı görmekteyiz.
Bu joblarlarda sürelerini tekrardan düzenleye biliriz gerekli değişikli ayarlarını yapabiliriz.
Log backup’ın alıp ikinci makinaya restore edene kadar ikinci makinaya F5 tuşuna basarak yeniliyorum stand by kısmını başta seçtiğimiz zaman veritabanı restore anında aşağıdaki gibi ulaşılamaz olur. Restore işlemi gerçekleşene kadar sürmektedir.
Restore tamamlandıktan sonra secondary(S2) sunucum kaldığı yerden devam eder.
Şimdi restore modunu değiştirelim no recovery mode yapalım bakalım ne gibi bir sonuçla karşılaşacağız. Bu işlemleri primary(S2) sunucunda yapılır. Bu işlemi kurulum aşamasında yapmıştık dikkat etmişseniz.
Bunu yaptıktan sonra veritabanı üzerine yeni değerler insert edelim S1 sunucusunda gözlemleyelim.
Yeni değer insert etmeden S1 sunucusundaki ABC veritabanı kendini restoring moduna aldı ve sürekli bu şekilde kalır hiçbir işlem yapılamaz. Ancak primary sunucum ulaşılamaz olduğunda manuel bu şekilde bu restore modundan dönülür.
Tekrar restoring modunu düzelttikten sonra eski halime dönmüş oldum. Son olarak log shipping yapısının mevcut durumunu öğrenmek için instance üzerine sağ tıklanır. Report>Standard Reports bölümünden Transaction Log Shipping Status seçilir.
Yukarıda belirtilen bölüme tıklandığında aşağıdaki ekran ile karşılaşılır.
Hedef Sunucular:
Log shipping başlatılan sunucuda backupların ne zaman alındığıyla ilgili bilgileri görmekteyiz. Dosyalardaki zaman dilimi farklılık göstermesinin sebebi uluslar arası zaman diliminden olmasından dolayıdır.
Not: Always On AG altında bir veritabanı secondary replica’da restore (NORECOVERY veya STANDBY) modunda olmasa bile , Log Shipping ile restore işlemi yapılamaz. Always On’daki secondary replika, zaten primary’dan gelen logları kendi mekanizması ile işlediği için, Log Shipping restore işine müdahale edemez. Log Shipping, transaction log backup alarak logları bir secondary sunucuya kopyalar ve orada restore eder. Always On ise logları doğrudan diğer replikalara aktararak sürekli senkronizasyon sağlar. Eğer bir veritabanı zaten AG altındaysa, transaction log’lar Always On tarafından kullanılmaktadır ve ayrı bir Log Shipping mekanizması ile aynı anda restore edilemez. Bu sebepten alwayson mekanizmasındaki log backuplar kapatılır. Log shipping kurulmadan önce kapatılmaktadır. Tek bir backup job’ının olması gerekmektedir.s
Log Shipping’i Always On’daki PRIMARY REPLICA üzerinde değil, bir SECONDARY REPLICA üzerinde yapılandırarak TEST ORTAMINDA yaptıgında secondary sunucuları backup alma işlemi gerçekleşmez.
Alwayson yapsında primary replica üzerinde log shipping özelliği açılıp AG altında olmayan bir sunucuya yapılabilir. Sadece primary replicada database log dosyası nerede oluşturulmuşsa backupların oraya alınması gerekmektedir.
Alwayson Yapıların da nasıl bir yol izlenmesi gerekmektedir.
Log Shipping mimarisinde failover sonrası sistemin aksamadan devam etmesi için her iki sunucunun da “hem primary hem secondary” rollerini üstlenebilecek şekilde hazır olması gerekir.
İşte bu yapıyı kurarken dikkat etmeniz gerekenler:
1. Jobların Hazırlanması
Primary sunucudaki Backup jobı ile Secondary sunucudaki Copy ve Restore joblarının scriptlerini alıp karşılıklı olarak diğer sunucularda oluşturmalısınız.
- Primary Sunucuda: Backup jobı zaten var. Buraya Secondary’den gelen Copy ve Restore joblarını (pasif halde) kurmalısınız.
- Secondary Sunucuda: Copy ve Restore jobları zaten var. Buraya Primary’den gelen Backup jobını (pasif halde) kurmalısınız.
2. Jobların Durumu (En Kritik Nokta)
- Her iki sunucuda da tüm jobların aynı anda Enabled (Etkin) olması çakışmalara ve hatalara yol açar.
- Normal Şartlarda: Primary’de sadece “Backup” jobı çalışır; Secondary’de “Copy” ve “Restore” jobları çalışır.
Failover Anında: Rol değiştirdiğinizde, eski Primary’deki backup jobını durdurup (Disable), yeni Primary olan sunucudaki backup jobını çalıştırmanız (Enable) gerekir.
Özetle: Sadece scriptleri alıp oluşturmak yeterli değildir; failover anında hangi jobın “Enable” hangi jobın “Disable” edileceğine dair bir manuel kontrol listesi veya bunu otomatize eden bir failover scripti hazırlamanız sağlıklı bir yapı için şarttır. Bu durumda yapılacak en önemli konu AG kontrol şartı eklenmesi gerekmektedir.
Log shipping veritabanı canlı bir sistemden farklı bir ortama aktarılmak istendiğinde log shipping yapısı kullanılmaktadır. Geçiş durumlarında aşağıdaki yöntemler uygulanır:
- Transaction Log Shipping Status bölümünden son duruma kontrol edilir.
- Log Shipping yapılan tüm sunucularda joblar disable edilir.
- Log Shipping başlatılan sunucuda backup jobı manuel olarak tekrardan çalıştırılır 1 defalağına daha sonra secondary sunucularında copy ve restore jobları çalıştırılıp restore işlemi yapılır yada restore işlemi manuel yapılmaktadır.
- Ana sunucuda log shipping ayarları delete edilir.
- Ana sunucudaki loginler disable edilir.
- Ana sunucuda aktif transation varmı diye kontrol edilmektedir.
select * from sys.sysprocesses where dbid = DB_ID('DB_NAME');- Ana sunucuda veritabanı tail log backup alınabilmesi için veritabanı Ag’den çıkarılır. Bu işlemden sonra Tail Log backup alınması gerekmektedir. Bu backup yeni ortamdaki sunuculara restore edilmektedir.
- Yeni ortamdamki primary olacak veritabanı restore moddan çıkarılıp online moda’a alınmaktadır.
Restore database DB_NAME with recovery;- Son olarak yeni primary makinada log backup alınıp restoring modunda olan secondary sunucusuna restore edilmektedir.
- İlgili veritabanı join only seçeneği ile AG’ye alınır.
Bu makalede uygulamalı bir şekilde sql server Log Shipping işlemini ele almış oldum.Başka bir makalede görüşmek dileğiyle.
“Allah, rüzgarları gönderendir. Onlar da bulutları hareket ettirir. Biz de bulutları ölü bir toprağa sürer ve onunla ölümünden sonra yer yüzünü diriltiriz. İşte ölümden sonra diriliş de böyledir. “Fâtır-9
