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 ve Microsoft SQL Server 2019 Kurulumu sizlerle paylaşmıştık.
Daha önceki yazımız da
W22SQL22NOD1 ve W22SQL22NOD2 isimli Windows Server 2022 sunucularımız üzerinde Windows Server Failover Cluster ( WSFC ) kurulumu ve yapılandırmasını sizlerle paylaşmıştk.
Daha sonraki yazımız da
Windows Server Failover Cluster ( WSFC ) yapısında Cluster Shared Volumes yapılandırmasını tamamlayarak sizlere paylaşmıştık.
Daha sonraki yazımız da
W22SQL22NOD1 isimli Windows Server 2022 sunucumuz üzerinde Microsoft SQL Server 2022 Failover Cluster kurulumunu tamamlayarak sizlere paylaşmıştık.
Daha sonraki yazımız da
W22SQL22NOD2 isimli Windows Server 2022 sunucumuzu Microsoft SQL Server 2022 Failover Cluster yapısına dahil işlemini sizlere paylaşmıştık.
Bu yazımızda da Microsoft SQL Server 2022 Failover Cluster yapısına Database ( Veritabanı ) oluşturma işlemini anlatıyor olacağız.
Peki Nedir Failover Cluster :
Yapımız içerisinde bulunan Windows Server Failover Cluster ( WSFC ) üyesi sunucuların ve bu sunucular üzerinde çalışan rol ve servislerin kapalı olduklarında Donanımsal ve Yazılımsal sorun nedeniyle Down duruma geldiklerinde Windows Server Failover Cluster ( WSFC ) üyesi olan bir sunucudan diğer sunucuya aktarılmasıdır. Bu tanımlamayı şu örnekle daha iyi anlayabileceğinizi düşünüyorum. Yapımız içerisinde 2 Adet sunucumuz olsun bu sunucular üzerinde çalışan Virtual Machine ( Sanal Makine) var. Sunucularımızın herhangi birinde Donanımsal ya da Yazılımsal bir sorun nedeniyle Down duruma geldiğinde yani kapandığında üzerinde çalışan Virtual Machine ( Sanal Makine) bununla birlikte Down duruma gelerek ulaşılamayacaktır. İşte böyle bir sorunda Windows Server Failover Cluster ( WSFC ) yapısı imdadımıza yetişecektir. Down durumda olan sunucumuz üzerindeki Virtual Machine ( Sanal Makine) otomatik olarak diğer fiziksel sunucumuz üzerinde hizmet vermeye başlayacaktır.
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 SQL22CLUSTER isimli Microsoft SQL Server 2022 Failover Cluster yapısının ismini yazıyoruz.
W22SQL22NOD1 isimli sunucumuz üzerine Microsoft SQL Server 2022 Failover Cluster yapısına bağlantı sağlamak için Authentication bölümünü Windows Authentication seçiyoruz ve Connect diyoruz.
W22SQL22NOD1 isimli sunucumuz üzerinde SQL22CLUSTER isimli Microsoft SQL Server 2022 Failover Cluster yapısına bağlantı sağlıyoruz.
W22SQL22NOD1 isimli sunucumuz üzerinde SQL22CLUSTER isimli Microsoft SQL Server 2022 Failover Cluster yapısında Microsoft SQL Server Management Studio ( SSMS ) konsolun da Databases bölümü altında herhangi bir Database ( Veritabanı ) olmadığını görüyoruz.
Microsoft SQL Server 2022 Always ON yapılandırması öncesinde sunucumuz üzerinde Database ( Veritabanı ) oluşturuyorduk. Çünkü yapıda bir Database ( Veritabanı ) olmadan Microsoft SQL Server 2022 Always ON yapılandırmasına devam edemiyorduk.
Microsoft SQL Server 2022 Failover Cluster yapılandırması öncesinde sunucumuz üzerinde herhangi bir Database ( Veritabanı ) oluşturmuyoruz. Çünkü yapıda bir Database ( Veritabanı ) olmadan Microsoft SQL Server 2022 Failover Cluster yapılandırmasına devam edebilirsiniz.
W22SQL22NOD1 isimli sunucumuz üzerinde SQL22CLUSTER isimli Microsoft SQL Server 2022 Failover Cluster yapısında Microsoft SQL Server Management Studio ( SSMS ) konsolun da Databases bölümü üzerinde sağ tuş New Database diyerek yeni bir Database ( Veritabanı ) oluşturuyoruz.
New Database ekranın da General sekmesin de Database name bölümün de oluşturacağımız Database ( Veritabanı ) için bir Name ( İsim ) belirlememiz gerekiyor.
New Database ekranın da General sekmesin de Database name bölümün de BAKICUBUKDB isimli bir Database ( Veritabanı ) oluşturacağız.
New Database ekranın da General sekmesin de Database files bölümün de oluşturacağımız Database ( Veritabanı ) için yapılandırma bilgisini görüyoruz.
New Database ekranın da General sekmesin de Database files bölümün de Patch sekmesin de BAKICUBUKDB isimli Database ( Veritabanı ) Microsoft SQL Server 2022 kurulumu sırasında yapılandırmış olduğumuz dizin üzerinde oluşturulacağını görüyoruz.
Microsoft SQL Server 2022 Server Always ON yapısında Data, Log, Temp ve Backup dizinleri sunucularımız üzerindeki diskler üzerinde tutulurken
Microsoft SQL Server 2022 Server Always ON yapısında farklı olarak Data, Log, Temp ve Backup dizinleri Cluster Volume Disklerimiz üzerinde tutulacaktır.
New Database ekranın da Options sekmesin de oluşturacağımız BAKICUBUKDB isimli Database ( Veritabanı ) için gerekli yapılandırma seçeneklerini görüyoruz.
New Database ekranın da Options sekmesin de Recovery model bölümünün Full olması gerekmektedir. SQL Server 2022 Always ON yapısı için bu şekilde yapılandırması gerekmektedir.
Recovery 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.
NOT : Options bölümün de yapılandırmalar oluşturulacak olan Database ( Veritabanı ) kullanılacağı yazılım ve uygulamalar ( Logo Tiger, Logo Bordro, Nebim, Mikro gibi ) yapılandırması için farklılık gösterebilir.
New Database ekranın da Options sekmesin de gerekli yapılandırmayı tamamladıktan sonra Filegroups sekmesine geçiyoruz.
New Database ekranın da Filegroups sekmesin de oluşturacağımız BAKICUBUKDB isimli Database ( Veritabanı ) için gerekli yapılandırmayı görüyoruz.
New Database ekranın da oluşturacağımız BAKICUBUKDB isimli Database ( Veritabanı ) için gerekli yapılandırmayı tamamladıktan sonra OK diyoruz.
W22SQL22NOD1 isimli sunucumuz üzerinde SQL22CLUSTER isimli Microsoft SQL Server 2022 Failover Cluster yapısında Microsoft SQL Server Management Studio ( SSMS ) konsolun da Databases bölümü altında BAKICUBUKDB isimli Database ( Veritabanı ) oluşturulduğunu görüyoruz.
W22SQL22NOD1 isimli sunucumuz üzerinde SQL22CLUSTER isimli Microsoft SQL Server 2022 Failover Cluster yapısında Microsoft SQL Server Management Studio ( SSMS ) konsolun da Databases bölümü altında BAKICUBUKDB isimli Database ( Veritabanı ) oluşturulduğunu görüyoruz.
W22SQL22NOD1 isimli sunucumuzun Local Disk (C:) dizini altında bulunan C:\ClusterStorage\Volume1\DATA klasöründe BAKICUBUKDB isimli Database ( Veritabanı ) SQL Server Database Primary Data File (. mdf ) dosyasının oluşturulduğunu görüyoruz.
W22SQL22NOD1 isimli sunucumuzun Local Disk (C:) dizini altında bulunan C:\ClusterStorage\Volume2\LOG klasöründe BAKICUBUKDB_log isimli SQL Server Database Transaction Log File ( .ldf ) dosyasının oluşturulduğunu görüyoruz.
