Microsoft SQL Server 2017 Always ON Full Recovery Mode is Required

High Availability ( Yüksek Erişebilirlik ) şirket ortamlarınızda bulunan Datacenter ( Veri Merkezi ) üzerinde birden fazla sunucu ile yapılır. Sunuculardan birinin Donanımsal ya da Yazılımsal bir sorun nedeniyle arızalanması durumunda diğer sunucunuzun devreye girmesini sağlayan teknolojidir.

Disaster Recovery ( Felaket Kurtarma ) şirket ortamlarınızda bulunan Datacenter ( Veri Merkezi ) üzerinde oluşabilecek herhangi beklenmedik bir felaket sonucu ( Deprem, Sel, Yangın ) Datacenter ( Veri Merkezi ) tamamen hizmet veremez duruma gelme ihtimaline karşı farklı bir uzak lokasyonda Datacenter ( Veri Merkezi ) kurularak sağlanır. Örneğin Datacenter ( Veri Merkezi ) Istanbul’da ise Disaster Recovery ( Felaket Kurtarma ) olarak İstanbul’da farklı bir lokasyonu ya da Ankara,İzmir gibi uzak ve daha az riskli bir lokasyonu Disaster Recovery ( Felaket Kurtarma ) için tercih edebilirsiniz. Microsoft Azure Cloud ve Amazon Cloud gibi Cloud ( Bulut ) hizmetlerinde Disaster Recovery ( Felaket Kurtarma ) Datacenter ( Veri Merkezi ) olarak yapılandırabilirsiniz.

Microsoft SQL Server Always On yapısı kurulum ve yapılandırması için ortamınızda Windows Server Failover Cluster yapısı içinde en az iki sunucuya ihtiyac duymakdır.

Availability Group yapısını Synchronous ( Senkron ) olarak yapılandırırsanız Availability Group yapısı içindeki tüm Database ( Veritabanı ) Synchronous ( Senkron ) bir şekilde çalışacaktır. Yani ortamdaki Primary Database ( Veritabanı ) gelen bir istek Secondary Database ( Veritabanı ) işlenmeden kullanıcıya işlem tamamlandı bilgisi iletilmeyecektir. Bu çok yoğun Transaction ( İşlem ) alan Database ( Veritabanı ) biraz performans kaybına neden olabilir. Ama Automatic ( Otomatik ) Failover Synchronous ( Senkron ) Availability Group yapısı yapılabildiği için herhangi bir sorun yaşamazsınız. Sunucularda herhangi bir Donanımsal ya da Yazılımsal bir sorun olması durumunda herhangi bir kesinti yaşanmadan Availability Group yapısı diğer sunucudan Automatic ( Otomatik ) bir şekilde hizmet vermeye devam edecektir.

Availability Group yapısını Asynchronous ( Asenkron ) olarak yapılandırısanız eğer. Primary Database ( Veritabanı ) veritabanına gelen bir istek Secondary Database ( Veritabanı ) işlenmeyi beklemeden direk kullanıcıya işlem tamamlandı bilgisi iletilecektir ve arka tarafta Synchronous ( Senkron ) yapılacaktır. Asynchronous ( Asenkron ) olarak yapılandırılan Availability Group yapısında Secondary Database ( Veritabanı ) yazma işlemi için belli bir süresi yoktur. Buradaki yazma işlemi ortamınızda mevcut Donanım ve Network yapınızın Performansına bağlı olarak değişkenlik gösterebilir.

Availability Group yapısını Automatic ( Otomatik ) ya da Manual ( Manuel ) olarak Failover yapabilirsiniz. Automatic ( Otomatik ) Failover yapabilmek için Availability Group yapısını Synchronous ( Senkron ) olarak yapılandırmanız gerekmektedir. Çok yoğun Transaction ( İşlem ) içeren sistemlerde Availability Group yapısını Synchronous ( Senkron ) ve Automatic ( Otomatik ) olarak yapılandırabiliriz. Index Rebuild ( Dizin Yeniden Oluşturma ) işlemlerinde Performans kaybı daha fazla olduğu için sıkıntı yaşayan yapılarda Index Rebuild ( Dizin Yeniden Oluşturma ) öncesinde Availability Group yapısını Asynchronous ( Asenkron ) olarak yapılandırabilirsiniz.

Automatic ( Otomatik ) Failover işlemi Availability Group yapısını dahil bir Database ( Veritabanı ) oluşan bir hata sonucu gerçekleşmez. Availability Replica seviyesinde gerçekleşir. Availability Group yapısında Database ( Veritabanı ) biri Corrupt ( Bozulma ) olması Transaction Log ( İşlem Logu ) dolmuş, Database ( Veritabanı ) bulunduğu Data dizini dolmuş gibi sebeplerde Automatic ( Otomatik ) Failover işlemi gerçekleşmez.

High Availability ( Yüksek Erişebilirlik ) ve Disaster Recovery ( Felaket Kurtarma ) SQL ServerAlways ON’da nasıl kullanıldığını için örnek vermemiz gerekirse.

Datacenter ( Veri Merkezi ) iki Adet sunucumuz var. Bu iki sunucumuzu Windows Server Failover olarak yapılandırdınız. Bu iki sunucumuz üzerinde SQL Server Always ON yapılandırdınız ve Synchronous ( Senkron ) olarak yapılandırdınız. Bu yapılandırmaya High Availability ( Yüksek Erişebilirlik ) yapılandırması deriz.

Datacenter ( Veri Merkezi ) iki Adet sunucumuz var. Bu iki sunucumuzu Windows Server Failover olarak yapılandırdınız Datacenter ( Veri Merkezi ) bir sıkıntı olma ihtimaline karşı başka bir lokasyonda Datacenter ( Veri Merkezi ) üzerinde bir sunucuz var. Bu sunucuyuda mevcut Windows Server Failover yapınıza dahil ettiniz ve mevcut SQL Server Always ON yapınıza Replica ( Kopya ) olarak yapılandırdınız ve Asynchronous ( Asenkron ) olarak yapılandırdınız. Bu yapılandırmaya Disaster Recovery ( Felaket Kurtarma ) yapılandırması deriz. SQL Server Always ON yapısında aynı Availability Group yapısı içinde birden fazla Secondary yapılandırması yapabilirsiniz.

Daha önceki Microsoft SQL Server Management Studio 18.4 Kurulumu sizlerle paylaşmıştık. Microsoft SQL Server 2017 Always ON Kurulumu yaparken BAKICUBUK isimli bir Database ( Veritabanı ) ekleyeceğiz.

Microsoft SQL Server Management Studio konsolu üzerinde W19SQLNOD1 isimli Microsoft SQL Server 2019 sunucumuz üzerine Connect diyerek bağlanıyoruz.

Microsoft SQL Server 2017 Always ON Kurulumu yaparken BAKICUBUK isimli bir Database ( Veritabanı ) eklemeye çalışıyoruz ancak Status bölümünde Full recovery mode is required hatasını düzeltmek için Microsoft SQL Server Management Studio konsolunu açıyoruz ve BAKICUBUK isimli bir Database ( Veritabanı ) üzerinde sağ tuş Properties diyoruz.

Database Properties – BAKICUBUK ekranın da Options diyoruz.

Recovery model bölümünü Simple olarak görüyoruz. BAKICUBUK isimli bir Database ( Veritabanı ) Microsoft SQL Server 2017 Always ON yapısına dahil edebilmek için Recovery model bölümünün Full olarak yapılandırmamız gerekiyor.

Recovery model bölümünde Full, Simple ve Bulk-Logged olarak 3 farklı seçenek bulunmaktadır.

Simple : Simple Recovery modeldeki veritabanlarında tutulan transaction loglar Checkpoint işleminden sonra silinirler. Bu nedenle Simple Recovery modelde transaction logların sürekli büyümesi söz konusu değildir. Fakat burada bir çok kişi tarafından yanlış anlaşılan bir noktaya değinmek istiyorum. Simple Recovery model de dahil olmak üzere tüm recovery modellerde transaction loglar tutulur. Fakat diğerlerinden farklı olarak Simple Recovery modelde transaction loglar checkpoint işleminden sonra otomatik olarak silinirler.

Simple Recovery modelde log yönetimi kolay olmasına rağmen Simple Recovery modelin dezavantajı ise geriye dönük transaction loglar silindiği için transaction logların yedeklenmesi ve dolayısıyla restore işlemleri mümkün değildir. Bu nedenle veri kaybı olaslığı çok büyüktür. Çünkü herhangibir felaket durumunda en iyi ihtimalle bir önceki aldığımız Full veya Differential backup tarihine kadar veritabanımızı restore edebiliriz. Bu nedenle Simple Recovery model Production ortamlarında tercih edilmemelidir.

Full Recovery Model : Full Recovery Modeldeki bir veritabanında yapılan tüm işlemler transaction log dosyasına kaydedilir ve manuel olarak müdahale etmedikce silinmez. Bu nedenle Full Recovery Modeldeki bir veritabanı için belli bir zaman veya işlem öncesine veritabanımızı restore etmek mümkündür. Full Recovery Modelde her işlem transaction loglara yazıldığı için en güvenilir Recovery modeldir. Fakat Full Recovery Modelde transaction logların yönetimi manuel yapıldığını söylemiştik. Bu nedenle belli aralıklar transaction loglar silinmelidir. SQL Serverda transaction logların silinmesi için iki farklı yöntem izleyebiliriz. Birinci yöntem olarak transaction log backup alabiliriz. İkinci yöntem ise veritabanımızın transaction loglarının Shrink edilmesidir.

SQL Server 2005 sonrası sürümlerinde Transaction logların shrink edilmesi için veritabanımızın Recovery modelini önce Simple olarak set edip daha sonra Shrink işlemini bitirdikten sonra Recovery modelimizi tekrar Full olarak set etmeliyiz.

Full Recovery Modelde insert,delete ve update gibi DML işlemlerinin yanında index oluşturma gibi Maintenance işlemleri, bcp veya bulk insert işlemleri de loglandığı için bu tür işlemlerden sonra transaction loglar hem aşırı büyümekte hem de bu işlemler transaction loga yazıldığı için işlemleri de az da olsa yavaşlatmaktadır. Bu nedenle bu tür toplu işlemlerin transaction loga yansıtılmaması için üçüncü recovery mkodelimiz olan Bulk Logged Recovery Modeli kullanmalıyız.

Bulk Logged Recovery Model : Bulk Logged Recovery Modelde Full Recovery modelden farklı olarak bulk işlmeler dışında tüm işlemler loglanırken herhangibir bulk işlem yapıldığında tüm işlem için tek bir kayıt log dosyasına yazılır. Bu gibi durumlarda veritabanımızı herhangibir zamana restore etmek mümkün olmaz. Bulk Logged Recovery Modelde bulk işlemler tek tek transaction log dosyasına yazılmadığı için Full Recovery modele göre bulk işlemler daha hızlı yapılır.

Bulk Logged Recovery Modelde bulk işlem içeren bir zamana veritabanımızı restore etmemiz mümkün olmadığı için bu model de Production ortamları için pek uygun değildir. Fakat Production ortamlarında herhangibir bulk işlem yapmadan önce veritabanımızın transaction log backupını alıp daha sonra recovery modelini Bulk Logged olarak değiştirip bulk işlemimizi yapmak ve daha sonra veritabanımızın recovery modelini tekrar full olarak set etmek tercih edilebilir. Diğer bir değişle Bulk Logged Recovery Model için kalıcı değil ama gecici olarak tercih edilebilecek bir Recovery modeldir demek yanlış olmaz.

Son olarak Bulk Logged Recovery Modelden bahsederken sürekli bulk işlemler diye genellediğimiz işlemlerden bir kaçını şu şekilde sıralayabiliriz. Index oluşturma, Silme, Rebuild, Select Into, bulk insert, bcp ile yapılan işlemler gibi işlemler bulk işlem olarak adlandırılırlar.

Recovery model bölümünü Full olarak seçiyoruz ve OK diyoruz.

Microsoft SQL Server Management Studio konsolu üzerinde BAKICUBUK isimli Database ( Veritabanı ) üzerinde Microsoft SQL Server 2017 Always ON kurulumu ve yapılandırması öncesinde Full Backup alıyoruz. Eğer Microsoft SQL Server 2017 Always ON kurulumu ve yapılandırması öncesinde Full Backup almazsanız aşağıdaki gibi hata alabilirsiniz.

BAKICUBUK isimli Database ( Veritabanı ) üzerinde sağ tuş Tasks menüsü altında bulunan Back UP… seçiyoruz.

Back Up Database – BAKICUBUK üzerinde Destination bölümünde Microsoft SQL Server 2017 Always ON kurulumu sırasında yapılandırmış olduğumuz Disk üzerine Backup ( Yedek ) alınacaktır. OK diyerek Backup işlemini başlatıyoruz.

BAKICUBUK isimli Database ( Veritabanı ) üzerinde Backup ( Yedek ) işlemi tamamlandı. OK diyerek kapatıyoruz.

Microsoft SQL Server 2017 Always ON yapısına dahil edebileceğimiz uygun Database ( Veritabanı ) Status bölümünde Meets prerequisities olarak görünecektir. Eğer Database ( Veritabanı ) üzerinde Full Backup almazsanız Status bölümü Full backup is required olarak görünecektir ve Database ( Veritabanı ) üzerinde Full Backup almadığınız için Availability Group yapısına ekleyemezsiniz.

Başka bir yazımızda görüşmek dileğiyle…