Microsoft SQL Server 2022 Always ON Database Attach

bakicubuk

2 yıl önce

Merhaba

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 işlemini anlatıyor olacağız.

Microsoft SQL Server 2022 Always ON yapısına NIHATCUBUKDB isimli Database ( Veritabanı ) Attach edeceğiz.

W22SQL22NOD1 isimli sunucumuz üzerinde öncelikle NIHATCUBUKDB isimli Database ( Veritabanı ) SQL Server Database Primary Data File (. mdf ) ve SQL Server Database Transaction Log File ( .ldf ) dosyalarını Microsoft SQL Server 2022 Always ON uygun dizinler altına kopyalıyoruz.

NIHATCUBUKDB.mdf isimli SQL Server Database Primary Data File (. mdf ) dosyasını Microsoft SQL Server 2022 Always ON yapısındaki DATA dizinine kopyalıyoruz.

NIHATCUBUKDB_log isimli SQL Server Database Transaction Log File ( .ldf ) dosyasını Microsoft SQL Server 2022 Always ON yapısındaki LOG dizinine kopyalı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.

W22SQL22NOD1 isimli sunucumuz üzerine Microsoft SQL Server 2022 Always ON kurulumu ve yapılandırması için Authentication bölümünü Windows Authentication seçiyoruz ve Connect diyoruz.

W22SQL22NOD1 isimli sunucumuz da Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database seçeneği altında sadece BAKICUBUKDB isimli Database ( Veritabanı ) görüyoruz.

W22SQL22NOD1 isimli sunucumuz da Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database seçeneği üzerinde sağ tuş Attach diyerek NIHATCUBUKDB isimli Database ( Veritabanı ) SQL Server Database Primary Data File (. mdf ) ve SQL Server Database Transaction Log File ( .ldf ) dosyalarını ekliyoruz.

Attach Databases ekranın da General sekmesin de Database to attach bölümün de geliyor karşımıza.

Attach Databases ekranın da General sekmesin de Database to attach bölümün de Add diyoruz.

Locate Database Files – W22SQL22NOD1 ekranın da NIHATCUBUKDB.mdf isimli SQL Server Database Primary Data File (. mdf ) dosyasını Microsoft SQL Server 2022 Always ON yapısındaki DATA dizininden seçiyoruz ve OK diyoruz.

Attach Databases ekranın da General sekmesin de Database to attach bölümü altında MDF File Location bölümüne F:\DATA\NIHATCUBUKDB.mdf olarak geldiğini görüyoruz.

Attach Databases ekranın da General sekmesin de Original File Name bölümü altında NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File ( .ldf ) dosyasını bulamadığı için Message bölümünde hata verdiğini görüyoruz.

NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File ( .ldf ) dosyası bulunduğu dizini gösterebilirsiniz ya da NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File ( .ldf ) dosyasını yeniden oluşturabilirsiniz.

Attach Databases ekranın da General sekmesin de Original File Name bölümü altında NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File ( .ldf ) dosyasının bulunduğu dizini göstermek için üç noktaya tıklıyoruz.

Locate Database Files – W22SQL22NOD1 ekranın da NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File ( .ldf ) dosyasını Microsoft SQL Server 2022 Always ON yapısındaki LOG dizininden seçiyoruz ve OK diyoruz.

Attach Databases ekranın da General sekmesin de Database to attach bölümü altında MDF File Location bölümüne F:\DATA\NIHATCUBUKDB.mdf olarak geldiğini görüyoruz.

Attach Databases ekranın da General sekmesin de Original File Name bölümü altında NIHATCUBUKDB.mdf isimli SQL Server Database Primary Data File (. mdf ) ve NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File ( .ldf ) dosyalarını ve dizinlerini görüyoruz.

Attach Databases ekranın da gerekli yapılandırmayı tamamladıktan sonra OK diyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database bölümü altında NIHATCUBUKDB isimli Database ( Veritabanı ) Attach işleminden sonra W22SQL22NOD1 isimli sunucumuz üzerine geldiğini görüyoruz.

W22SQL22NOD1 isimli sunucumuz üzerinde NIHATCUBUKDB isimli Database ( Veritabanı ) Attach işleminden sonra Microsoft SQL Server 2022 Always ON yapısına dahil etmeden önce NIHATCUBUKDB isimli Database ( Veritabanı ) bir kaç işlemi yapmanız gerekmektedir.

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.

Eğer NIHATCUBUKDB isimli bir Database ( Veritabanı ) Recovery model bölümünü Full yapılandırmazsanı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 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.

NIHATCUBUKDB isimli bir Database ( Veritabanı ) Microsoft SQL Server 2022 Always ON yapısına dahil edebilmek için Full Backup almamız gerekiyor.

Eğer NIHATCUBUKDB isimli bir 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.

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.

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.

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.

Microsoft SQL Server 2022 Always ON yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Recovery model seçeneğini Full olarak yapılandırdık ve NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde Full Backup aldıktan sonra Microsoft SQL Server 2022 Always ON yapısına dahil ediyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability bölümü altında bulunan Availability Groups üzerinde sağ tuş Add Database tıklıyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability bölümü altında bulunan Availability Groups bölümün de BAKICUBUKAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasını,

Availability Databases bölümü üzerinde sağ tuş Add Database tıklıyoruz.

Introduction ekranın da Always On High Availability yapısı için gerekli yapılandırma için bilgileri görüyoruz. Next diyerek devam ediyoruz.

Select Databases ekranın da Availability Group dahil edeceğimiz Database ( Veritabanı ) seçmemiz gerekiyor. Daha önce Availability Group yapısına dahil ettiğimiz BAKICUBUK ve MUGECUK isimli Database ( Veritabanı ) Status bölümünde Already part of this availability group olarak görüyoruz. Availability Group yapısına dahil edeceğimiz NIHATCUBUK isimli Database ( Veritabanı ) Status bölümünde Meets prerequisities olarak görünüyor. 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.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) seçmemiz gerekiyor.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Meets prerequisities olarak görünmesi gerekmektedir.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Full recovery mode is required hatası alırsanız. Database ( Veritabanı ) üzerinde Recovery model seçeneğini Full yapmanız gerekmektedir.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Full backup is required hatası alırsanız. Database ( Veritabanı ) üzerinde Full Backup almadığınız için Availability Group yapısına ekleyemezsiniz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Meets prerequisities tıkladığımız da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) uygun olduğu bilgisini görüyoruz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) seçiyoruz ve Next diyerek devam ediyoruz.

Connect to Existing Secondary Replicas ekranın da W22SQL22NOD2 isimli sunucumuzu Secondary olarak yapılandıracağımız için bu sunucularımız üzerine bağlanmamız gerekiyor.

Connect to Existing Secondary Replicas ekranın da Connect diyerek Microsoft SQL Server 2022 Always ON bağlanmak istediğiniz sunucuyu bağlayabilirsiniz. Connect All diyerek Microsoft SQL Server 2022 Always ON yapısındaki bütün sunucularınıza bağlantı sağlayabilirsiniz.

Connect to Existing Secondary Replicas ekranın da W22SQL22NOD2 isimli sunucumuzu Secondary olarak yapılandıracağımız için bu sunucumuz üzerine Connect diyerek bağlanıyoruz.

Connect to Server ekranın da Server name bölümüne W22SQL22NOD2 olarak geliyor ve Connect diyoruz.

Connect to Existing Secondary Replicas ekranın da W19SQL19NOD2 isimli sunucumuzu Secondary olarak yapılandırdık sonra Next diyerek devam ediyoruz.

Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine Database ( Veritabanı ) senkronizasyonun ilk yapılandırmasını nasıl yapılacağını yapılandırdığımız ekrandır.

Automatic seeding : Bu seçenek ile devam edersek eğer Secondary sunucusu üzerine Database ( Veritabanı ) senkronizasyonu için gerekli olan bütün işlemler Automatic ( Otomatik ) olarak gerçekleştirilecektir.

Full database and log backup : Bu seçenek ile devam edersek eğer her Database ( Veritabanı ) Full Backup ve Log Backup dosyalarını yapılandırmış olduğumuz Share ( Paylaşım ) üzerinden alarak Secondary sunucumuz üzerine kendisi aktarır ve bu işlem için sunucularımız üzerindeki Instance’ın SQL Server Servis hesaplarının Write ( Yazma ) ve Read ( Okuma ) yetkisi olan bir Share ( Paylaşım ) istemektedir. Yapılandırdığınız Share ( Paylaşım ) diskinde bulunan Database ( Veritabanı ) Full Backup ve Log Backup sığacağı kadar yer olmalıdır.

Join only : Bu seçenek ile seçtiğimiz her Database ( Veritabanı ) Full Backup ve Log Backup Manuel ( Manuel ) olarak alıp Manuel ( Manuel ) olarak Secondary sunucusuna bu adımı geçmeden önce kopyalamamız gerekir.

Skip initial data synchronization : Bu seçenek ile yine her Database ( Veritabanı ) Full Backup ve Log Backup Manual ( Manuel ) olarak alıp Manual ( Manuel ) olarak Secondary sunucumuz üzerine kopyalamamız gerekir. Ancak Join only seçeneğinden farklı olarak bu işlemi sonra yapabiliriz.

Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine senkronizasyonun otomatik olarak yapılması için Automatic seeding seçeneğini seçiyoruz ve Next diyerek devam ediyoruz.

Validation ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için gerekli kontroller yapılıyor.

NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için bütün adımları Success olarak görüyoruz. Eğer bir sorun varsa Error olarak görürdük ve Previous diyerek geri gidebilirsiniz ve yanlış yaptığınız bir yapılandırma varsa yapılandırmayı düzelttikten sonra Re-run validation diyebilirsiniz.

Validation ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için herhangi bir sorun olmadığı için Next diyerek devam ediyoruz.

Summary ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için gerekli olan yapılandırmanın bir özetini görüyoruz.

Summary ekranın da Finish diyerek NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için işlemi başlatıyoruz.

Script bölümünde Database ( Veritabanı ) Availability Group yapısına dahil etmek için yapılandırmış olduğunuz yapılandırmayı Script ( Senaryo ) olarak alabilirsiniz.

Results ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına başarılı bir dahil edildiğini görüyoruz.

Results ekranın da Close diyerek Add Database to Availability Group Wizard ekranını kapatıyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database seçeneği altında NIHATCUBUKDB isimli Database ( Veritabanı ) geldiğini ve NIHATCUBUKDB (Synchronized) olarak görüyoruz.

Availability Databases bölümü altında NIHATCUBUKDB isimli Database ( Veritabanı ) geldiğini görüyoruz.

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