Always On Mimarisinde Restore Etmeden SQL Server Kurulumu

Bu yazımızda AlwaysOn Mimarisinde olan 2 sunucudan secondary makine üzerinde olan database’leri yeniden restore etmeden Windows Format sonrası tekrar AlwayOn’a bağlarken yapılması gereken senaryoları adım adım işleyeceğiz.   Adım: Sunucu içinde yer alan tüm Cluster Bilgileri Alınır (Ekran Görüntüleri ile Roles ve Nodes bilgileri dâhil). Varsa Witness Share File veya Disk Quarum bilgileri alınır. Buradaki amaç herhangi bir beklenmeyen durumda tüm bilgileri tekrar girip cluster’ı ayağa kaldırmak.   Adım: Sunucu içinde kullanmış olduğunuz Disklerin Bilgisini almak. Aşağıdaki komut ile diske ait ihtiyaç olabilecek bilgileri bir csv uzantılı bir dosyaya yazdırabilirsiniz. Bu bilgileri almamızın sebebi, biz sql server yapımızda root and mount disk yapısı kullandığımız için root diske bağlanacak olan mount diskler offline moda çekilecek ve sonrasında tekrar bağlantı yapıldığında doğru diskleri doğru yere bağlamak için bu bilgiler önemlidir.   get-disk | select disknumber,uniqueid,FriendlyName,Size | Sort-Object -Property DiskNumber > H:\DiskInf\Disks_All.csv Adım: Sql Server kullanıcı bilgilerini sp_help_revlogin komutu ile bir notepad.txt dosyası […]

Always On Mimarisinde Restore Etmeden SQL Server Kurulumu

Bu yazımızda AlwaysOn Mimarisinde olan 2 sunucudan secondary makine üzerinde olan database’leri yeniden restore etmeden Windows Format sonrası tekrar AlwayOn’a bağlarken yapılması gereken senaryoları adım adım işleyeceğiz.

 

  1. Adım: Sunucu içinde yer alan tüm Cluster Bilgileri Alınır (Ekran Görüntüleri ile Roles ve Nodes bilgileri dâhil). Varsa Witness Share File veya Disk Quarum bilgileri alınır. Buradaki amaç herhangi bir beklenmeyen durumda tüm bilgileri tekrar girip cluster’ı ayağa kaldırmak.

 

  1. Adım: Sunucu içinde kullanmış olduğunuz Disklerin Bilgisini almak. Aşağıdaki komut ile diske ait ihtiyaç olabilecek bilgileri bir csv uzantılı bir dosyaya yazdırabilirsiniz. Bu bilgileri almamızın sebebi, biz sql server yapımızda root and mount disk yapısı kullandığımız için root diske bağlanacak olan mount diskler offline moda çekilecek ve sonrasında tekrar bağlantı yapıldığında doğru diskleri doğru yere bağlamak için bu bilgiler önemlidir.

 

get-disk | select disknumber,uniqueid,FriendlyName,Size | Sort-Object -Property DiskNumber > H:\DiskInf\Disks_All.csv

  1. Adım: Sql Server kullanıcı bilgilerini sp_help_revlogin komutu ile bir notepad.txt dosyası içinde yedeklenmelidir.

 

  1. Adım: Sql Server üzerinde kullanılan tüm linked server’ların create bilgisi notepad.txt içinde yedeklenmelidir.

 

  1. Adım: Sunucu içinde ODBC kullanılıyorsa (Oracle, postgre vs.) tüm bilgiler yedeklenmelidir. Ayrıca Windows Search => HKEY_LOCAL_MACHINE => SOFTWARE=> ODBC klasörünü sağ click => export ederek yedekleyiniz. Daha sonra bunu sunucu kurulumu tamamlandıktan sonra regedit açılıp File kısmından import ettiğinizde kullanmış olduğunuz ODBC’ye ait önceki tüm bilgiler gelecektir.

Görsel 1: ODBC regedit Export

 

  1. Adım: SQL server path bilgileri saklanmalıdır. Aşağıdaki script ile bu bilgileri bir csv dosyası içerisinde saklayınız.

 

select a.physical_name,DB_NAME(a.database_id)as

name,a.size,b.volume_mount_point,b.total_bytes  from sys.master_files a

cross apply sys.dm_os_volume_stats(a.database_id,a.file_id) b

order by volume_mount_point asc

 

  1. SQL Server için kullandığınız Trace Flag’ların bilgisi not ediniz. Bu bilgiler C diskinde yapılacak format sonrası sistem veri tabanları yedeklemiş olsanız da gelmeyecektir. O yüzden bu bilgileri kesinlikle not etmelisiniz.

 

  1. Adım: Bu adım en önemli kısmı. Format işlemimizi C klasörüne atacağız. Biz SQL Server sadece bin klasörünü bu path’te tutuyoruz. Sistem veri tabanlarımız(msdb, master ve model) ayrı bir local olmayan disk altında tutuyoruz. Veri tabanlarına, joblara, AlwaysOn ait tüm bilgiler bu veri tabanlarında tutulduğu için bu veri tabanlarını mdf ve ldf file’larını başka bir sunucuda ya da local bilgisayarınızda yedekleyiniz.

 

  1. Format işlemi yapılacak olan Secondary makine AlwaysOn Primary Availability Group (AG) altında Availablity Replicas altından Remove edilerek çıkarılır. Bu işlem sonrası Secondary Makine üzerindeki tüm database’lerin Restoring Moda geçmesini bekleyiniz. Ve Eğer Primary üzerinden transaction log backup almaya devam edecekseniz. Çıkarma işlemi yaptığınız saati not ediniz. İlerdeki adımlarda log transaction işleme durumunda bu saat önemli olacak.

Görsel 2: Primary AG üzerinden Secondary Makine’nin Çıkarılması

Görsel 3: Primary AG üzerinden çıkarılan Secondary Makine’nin veri tabanları

 

  1. SQL Server system database’lerinin kurulu olduğu klasörün adını değiştiriniz. Örneğin MSSQL14 ise MSSQL14_Old Olarak

Görsel 4: Yeni SQL Server kurulumu öncesi dosya ismi değişikliği görüntüsü ve kurulum sonrası oluşacak olan klasör.

  1. Adım: Yukarıdaki adımlar tamamlandıktan sonra mdf ve ldf file’ların bilgisinin tutulduğu diskler herhangi bir corruption meydana gelmemesi adına offline moda alınır.

Görsel 5: Formatlama öncesi disklerde problem yaşanmaması için Offline mode çekilmesi

 

  1. Sistemimiz Always On mimarisinde olduğu için Failover Cluster Manager Ekranından => Nodes kısmında format işlemi yapacağımız Node üzerinden sağ click => More Actions => Stop Cluster Service diyoruz ve node’u susturuyoruz. Tekrardan Node üzerinde sağ click => More Actions => Evict ederek cluster’dan node’u koparıyoruz. Node durdurmadan da Evict edilebilir fakat bu yöntem daha güvenli olduğu için bu yöntemi izlemenizi tavsiye ederiz.

Görsel 6: Failover Cluster Manager’dan çıkarılacak Node’un Durdurulması

Görsel 7: Failover Cluster Manager çıkarılacak Node’un Cluster’dan çıkarılması

 

  1. Adım: Windows Server formatlama işlemine başlanılır. Formatlama hatasız bir şekilde sonlandıktan sonra bir sonraki adıma geçilir.

 

  1. Adım: Server Manager’dan Failover Cluster Manager Kurulumu gerçekleştirilir ve Node tekrardan Failover Cluster Manager’e eklenir. Failover Cluster Manager => Add Node => Enter Server Name kısmına server name eklenerek Node Cluster’a dahil edilir.

Görsel 8: Format işlemi sonrası Node Failover Cluster Manager’a eklenmesi

 

  1. Adım: Diskler tekrardan Online moda çekilir ve SQL Server kurulumu yapılır. Kurulum esnasında dikkat edilmesi gereken hususlar;
  • Instance adı kurulum önceki Instance adı ile aynı olmalıdır.
  • System Database’lerin path’leri kurulum önceki path’ler ile aynı olmalıdır.
  • Service ve agent hesapları kullanıcıları özellikle AlwaysOn olan sistemlerde kurulum öncesi hesaplar ile aynı olmasına dikkat edilmelidir.

 

  1. Adım: SQL Server kurulumu tamamlandıktan sonra system database’lerinin kurulu olduğu klasörün altındaki veri tabanlarının uzantılarını değiştiriniz. Örneğin msdb.mdf ise msdb_new.mdf şeklinde tüm system veri tabanları adlarını değiştiriniz.

 

  1. Adım: Kurulum öncesi MSSQL14_Old (9.Adımda örnekte verdiğimiz Klasör) klasörün altındaki system database’leri (mdf ve ldf file) kopyalanıp yeni kurulum sonrası oluşan MSSQL14 altındaki system veri tabanları yerine yapıştırılır. Tüm bu adımlar SQL Server Service hesabı kapalı iken yapılır. SQL Server Service start edildikten sonra Tüm database’ler restoring mode’da gelecektir.

 

Görsel 9: SQL Server kurulumu sonrası eski sistem veri tabanlarının yeni kurulum sonrası oluşan sistem veri tabanlarının yerine kopyalanması sonrası oluşan görüntü.

 

  1. Adım: Cluster içine eklemiş olduğumuz node’u SQL Server Always On üzerinde Availability Replicas üzerinden Replikayı ekliyoruz.

 

Görsel 10: Secondary ile Primary makine arasındaki AlwaysOn bağlantısının yapılması için Yeni kurulan secondary makinenin primary AG üzerinden replicaya eklenmesi

  1. Adım: Replika eklendikten sonra database’leri eklememiz gerekmektedir. Biz işlemimiz süresince oluşabilecek herhangi bir aksaklık durumunda backupların alınmasına devam ettik. Sizler burada transaction log alınmasını durdurursanız. Database’leri AlwaysOn’da herhangi bir işlem yapmadan join edebilirsiniz.

 

  1. Adım: Eğer backup almaya devam ettiyseniz. Tüm transactional log backupların Restoring mode’daki databaselere işlememiz gerekmektedir. Aşağıdaki scriptle replikayı kopardığınız tarihi not ettiyseniz. Aşağıdaki script ile tarih şartını kullanarak çıktı restore edeceğiniz Instance üzerinde kullanabilirsiniz.(Doğru Instance üzerinde olduğundan emin olunuz.). Eğer script boyutunuz sığmaz ise SSMS => Query => Query Options=> Maximum Number of characters displayed in each column değerini arttırınız.
 
DECLARE @i int = 5

WHILE @i<= (Select max(database_id) from sys.databases)

BEGIN

DECLARE @dbName sysname

Select @dbName=name from sys.databases where database_id=@i


SELECT

'RESTORE LOG ['+@dbName+'] FROM  DISK = N''' + m.physical_device_name + ''' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10' +CHAR(10) + CHAR (13) + '

GO'

FROM msdb.dbo.backupset s

INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id

WHERE s.database_name = @dbName and s.[type]='L' -- Remove this line for all the database

and backup_finish_date >='2023-08-24 15:00:38.000'

ORDER BY backup_finish_date ASC


SET @i=@i+1

END

i+1

END

 

 

  1. Windows search > Local Security Policy > User Rights Assignment > Perform Volume Maintenance Tasks ve Windows search > Local Security Policy > User Rights Assignment > Lock Pages in Memory  içeriğine SQL Server Engine kullanıcı eklenerek IFI için aktif edilir. konu hakkında detaylı bilgi için SQL SERVER – INSTANT FILE INITIALIZATION adlı makaleyi inceleyebilirsiniz.
  2. Adım: Transaction Log backupları işleyerek, Primary makine ile Secondary makine eşit zamana getirilir. Sonrası Avaliability Database altından ilgili Database join edilerek hizmete açılır.

 

 

 

Benzer Yazılar

HashTable HashIndex HashPartition

SQL Server 6 gün önce

Bu makalede modern veri tabanı sistemlerinde verimliliği artıran HashTable, HashIndex ve Hashpartition yapılarını inceleyeceğiz. Bu kavramların nasıl çalıştığını, avantajlarını, dezavantajlarını ve pratik kullanım örneklerini SQL kodlarıyla açıklayacağız.İçindekilerHash Table Nedir?Hash Index Nedir?Hash Partitioning Nedir? Hash tabanlı bir veri yapısı tasarlayacağımız ortamda bilmemiz gereken özellikle hash partitioning ya da bucketing gibi bölümlendirme stratejilerinde sıkça karşımıza çıkacak bir parametre olan bucket_count, verilerin kaç adet bucket içine dağıtılacağını belirleyen sayısal bir değerdir. Her bir bucket, belirli bir hash değeri aralığına denk gelir ve veriler, belirli bir kolona uygulanan hash fonksiyonunun çıktısına göre bu bucket ‘lardan birine atanır. Peki, bu bizim için neden önemli? Doğru belirlenmiş bir bucket_count değeri, verilerin eşit dağılımı sağlar bu da sorgu performansını iyileştirir. Bucket sayısı, paralel çalışan işlemlerin sayısını doğrudan etkiler, örneğin bir tablo 16 bucket sahipse, aynı anda 16 thread veriyi işleyebilir. Aynı bucket sayısıyla bölünmüş tablolar arasında yapılan join işlemleri daha verimli olur. CREATE TABLE UserActiviy ( Id_user […]

In-Memory Table and Native Stored Procedures

SQL Server 1 ay önce

Bu makalede 2014 yılında yayınlanan In-Memory Table OLTP(Online Transaction Processing) Engine yapısından bahsedeceğim.İçindekilerKaynak: In-Memory Table, adından da anlaşılacağı üzere, verileri fiziksel disk yerine RAM üzerinde saklandığı özel bir tablo türüdür. Bu yapı, geleneksel disk tabanlı tablolara kıyasla çok daha hızlı veri okuma ve yazma performansı sunar çünkü disk erişimi esnasında yaşanan darboğaz sorununa alternatif bir çözüm sunmuştur. Verinin, buffer pool içinde cache’lenmesi, düşük gecikme(low latency) ve yüksek throughput en büyük avantajlarıdır. Özellikle yüksek hacimli veri işleyen, çok sayıda eş zamanlı işlem gerçekleştiren veya gerçek zamanlı yanıt süresi gerektiren sistemlerin kullanımı oldukça yaygındır. (Örneğin: finansal platformlar, IoT işlemleri, sipariş işlemleri) Avantajlarını göz önünde bulundurarak o zaman her ortama bunu yapalım diyebiliriz 🙂 pahalı bir donanım olan RAM ‘den sınırsız bir şekilde elinizde bulunduruyor olmanız gerekebilir çünkü In-Memory bulunduğu ortama yüksek RAM maliyeti, kendine has filegroup yapısı ile yönetimsel zorluklar, failover sürelerinin uzaması gibi dezavantajları da beraberinde getirmektedir. In-Memory Tabloların kendine özgü […]

SMART BACKUP

SQL Server 1 ay önce

Bu makalede SQL Server 2017 versiyonuyla gelen DMV ‘ler ile kullanımı kolaylaşan bir özellik olan Smart Backup dan bahsedeceğim. Bu makaleye başlamadan şunu belirtmekte fayda var; bu özelliği üçüncü parti yazılımlar veya eklentiler ile yapabilmek mümkün MSSQL haricinde diğer ilişkisel veri tabanı sistemlerinde de buna benzer özellikler tanımlanabilir, kullanılabilir. Bu makalemizin anlaşılabilirliğini artırmak adına öncelikle performans ve veri bütünlüğü açısından hayati öneme sahip olan Checkpoint kavramından bahsetmek istiyorum; SQL Server, veri değişikliklerini önce RAM’de (buffer cache) tutar, bu sırada log dosyasına (LDF) işlemi yazar. Checkpoint olduğunda, bu değişmiş (dirty) geçici verileri .LDF dosyasından kalıcı hale getirir .MDF dosyasına (diske) yazar. Checkpoint, varsayılan olarak her 60 saniyede bir çalışır ancak SQL Server 2012 ile indirect checkpoints tanıtıldı ve veri tabanı bazlı olarak ayarlanabilir. Şimdi iki Checkpoint yönetimine daha yakından bakarak artı ve eksilerinden bahsedelim; Otomatik checkpoint modunda, tüm buffer pool’daki sayfalar taranır ve değişmiş sayfalar bulunur bu ilk baktığımızda bizim için […]

0 Yorum

Yorum Yaz

Rastgele