Merhaba
Daha önceki yazılarımız da Microsoft SQL Server 2016 Failover Cluster Kurulumu 1, Microsoft SQL Server 2016 Failover Cluster Kurulumu 2, Windows Server 2016 üzerinde Microsoft SQL Server 2017 Failover Cluster Kurulumu 1, Windows Server 2016 üzerinde Microsoft SQL Server 2017 Failover Cluster Kurulumu 2, Windows Server 2019 üzerinde Microsoft SQL Server 2017 Failover Cluster Kurulumu 1, Windows Server 2019 üzerinde Microsoft SQL Server 2017 Failover Cluster Kurulumu 2, Windows Server 2019 üzerinde Microsoft SQL Server 2019 Always ON Kurulumu 1, Windows Server 2019 üzerinde Microsoft SQL Server 2019 Always ON Kurulumu 2, Windows Server 2019 üzerinde Microsoft SQL Server 2019 Always ON Kurulumu 3, Microsoft SQL Server 2019 Failover Cluster Yapısına Sunucu Eklemek, Microsoft SQL Server 2019 Failover Cluster Yapısına Database Oluşturmak ve Microsoft SQL Server 2019 Failover Cluster Yapısına Database Eklemek sizlerle paylaşmıştık.
Peki Nedir SQL Server Always ON :
Microsoft SQL Server Always ON yapısı High Availability ( Yüksek Erişebilirlik ) ve Disaster Recovery ( Felaket Kurtarma ) çözümüdür.
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 yazımız da
W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerinde Windows Failover Cluster kurulumu ve yapılandırmasını yapmıştık.
Daha sonraki yazımız da
W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2022 kurulumlarını tamamladık.
Daha sonraki yazımız da
Microsoft SQL Server 2022 SQL Always ON yapılandırması öncesinde W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerindeki gerekli yapılandırmayı tamamladık.
Bu yazımız da Microsoft SQL Server 2022 Always ON yapısına Database ( Veritabanı ) Attach ya da Restore işlemini yaptığınızda alınan Full Recovery Mode Is Required hatasının düzeltmek için yapılması gereken işlemleri anlatıyor olacağız.
Microsoft SQL Server 2022 Always ON yapılandırması sonrasında NIHATCUBUKDB isimli bir Database ( Veritabanı ) eklemeye çalışıyoruz.
Ancak Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full recovery mode is required hatası alıyoruz.
Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full recovery mode is required tıkladığımız da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) uygun olmadığı bilgisini görüyoruz.
W22SQL22NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio ( SSMS ) konsolunu açıyoruz.
Connect to Server ekranın da Server name bölümüne W22SQL22NOD1 isimli sunucumuzun ismini yazıyoruz.
Connect to Server ekranın da Authentication bölümünü Windows Authentication seçiyoruz ve Connect diyoruz.
Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database bölümü altında NIHATCUBUKDB isimli Database ( Veritabanı ) W22SQL22NOD1 isimli sunucumuz üzerinde görüyoruz.
Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database bölümü altında NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde sağ tuş Properties seçeneğine tıklıyoruz.
Database Properties – NIHATCUBUKDB ekranın da Options seçeneğine tıklıyoruz.
Recovery model bölümünü Simple olarak görüyoruz.
NIHATCUBUKDB isimli bir Database ( Veritabanı ) Microsoft SQL Server 2022 Always ON yapısına dahil edebilmek için Recovery model bölümünün Full olarak yapılandırmamız gerekiyor.
ecovery model bölümün de 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 ( SSMS ) konsolunda NIHATCUBUKDB isimli Database ( Veritabanı ) Microsoft SQL Server 2022 Always ON yapısına dahil etmeden önce Full Backup alıyoruz.
Eğer Microsoft SQL Server 2022 Always ON yapısına dahil etmeden önce NIHATCUBUKDB isimli Database ( Veritabanı ) Full Backup almazsanız.
Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full backup is required hatası alırsınız.
Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full backup is required tıkladığımız da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) uygun olmadığı bilgisini görüyoruz.
NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde sağ tuş Tasks menüsünden Back Up… diyoruz.
Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Back up-to seçeneğine altında direkt olarak Backup dizini gelecektir. Biz Backup alınacak olan dizin yapılandırmasını göstermek istediğimiz için burada herhangi bir yapılandırma görünmemektedir.
Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Back up-to seçeneğinde Disk olarak seçiyoruz.
Eğer daha önce Backup almışsanız Destination bölümünü altında dizin görünecektir. Biz Backup alınacak olan dizin yapılandırmasını göstermek istediğimiz için burada herhangi bir yapılandırma görünmemektedir.
Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Back up-to seçeneğinde Disk ve ya URL olarak seçebilirsiniz.
Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Backu up-to seçeneğinde Disk olarak seçiyoruz. Microsoft SQL Server 2022 Always ON yapılandırması sırasında yapılandırmış olduğumuz Disk üzerinde Backup almak için Add diyoruz.
Select Backup Destination ekranın da Destinations on disk bölümü altında File name bölümü altında Backup alınacak dizini görüyoruz.
Select Backup Destination ekranın da Destinations on disk bölümü altında File name bölümünde Backup alınacak dizini yapılandırmak için üç noktaya tıklıyoruz.
Locate Database Files – W22SQL22NOD1 ekranın da Select the file bölümü altında W22SQL22NOD1 isimli sunucumuz üzerinde Backup alabileceğimiz dizinleri görüyoruz.
Selected patch bölümünde Backup alınacak dizini görüyoruz. File of type bölümünde Backup türünü ( .bak, .trn ) olarak görüyoruz. File name bölümüne alınacak Backup için bir isim belirlememiz gerekiyor.
Locate Database Files – W22SQL22NOD1 ekranın da File name bölümüne alınacak Backup için bir isim belirliyoruz ve OK diyoruz.
Select Backup Destination ekranın da Destinations on disk bölümü altında File name bölümü altında Backup alınacak dizini yapılandırdıktan sonra OK diyoruz.
Back Up Database – NIHATCUBUKDB üzerinde Destination bölümün de Backup alınacak dizini yapılandırdık.
BAKICUBUKDB isimli Database ( Veritabanı ) üzerinde Backup işleminin başlatmak için OK diyerek Backup işlemini başlatıyoruz.
NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde Backup işleminin tamamlandı. OK diyerek kapatıyoruz.
Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Meets prerequisities olarak görünüyoruz. Yani artık NIHATCUBUKDB isimli Database ( Veritabanı ) Availability Group yapısına dahil edebiliriz.
Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Meets prerequisities tıkladığımız da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) uygun olduğu bilgisini görüyoruz.
Başka bir yazımızda görüşmek dileğiyle….