SQL Server High Availability: FCI, Availability Group ve Log Shipping Karşılaştırması

SQL Server’da high availability (yüksek erişilebilirlik), açıp kapatılan tek bir özellik değildir. Birkaç teknoloji arasında bir seçimdir: failover cluster instance, Always On availability group, basic availability group, log shipping ve eski sistemlerde database mirroring. Her biri farklı bir arızaya karşı korur, farklı bir SQL Server sürümü gerektirir ve işletme maliyeti farklıdır. Yanlış seçim çoğu zaman ancak ihtiyaç duyulan gün ortaya çıkar.

Bu rehberde SQL Server high availability seçeneklerini yan yana karşılaştırıyor, her birinin neye karşı koruduğunu ve neye karşı korumadığını anlatıyor ve sürümünüze, kurtarma hedeflerinize ve gerçekten beklediğiniz arızalara göre nasıl seçim yapacağınızı gösteriyoruz.

High Availability, Felaket Kurtarma ve Yedekleme Farklı İşlerdir

Neredeyse her HA konuşmasında üç kavram birbirine karışır:

• High availability (HA), bozulan bir sunucu, çöken bir işletim sistemi ya da duran bir SQL Server servisi gibi yerel bir arızada veritabanının çalışmaya devam etmesini sağlar. Failover genellikle otomatiktir ve saniyeler ile dakikalar sürer.
• Felaket kurtarma (disaster recovery, DR), bir lokasyonu ya da veri merkezini tamamen kaybettiğinizde hizmeti geri getirir. Failover genellikle manueldir ve çoğu zaman bir miktar veri kaybı kabul edilir.
• Yedekler, HA ve DR’ın koruyamadığı her şeye karşı korur: özellikle insan hatası, yayılmış bozulma (corruption) ve fidye yazılımı.

Tasarımı iki sayı belirler: RPO (recovery point objective, ne kadar veri kaybını göze alabileceğiniz) ve RTO (recovery time objective, ne kadar süre kapalı kalabileceğiniz). RPO ve RTO’nun Always On tasarımını nasıl şekillendirdiğini SQL Server Always On rehberimizde ayrıntılı anlattık.

Önce Hangi Arızaya Karşı Korunduğunuzu Belirleyin

Özellikleri karşılaştırmadan önce atlatmanız gereken arızaları listeleyin. Her seçenek farklı bir kümeyi kapsar:

SQL Server High Availability Seçeneklerinin Karşılaştırması

Replication bu tabloda bilerek yok. Veritabanları arasında veri taşır ama bir failover mekanizması yoktur; bu yüzden bir HA çözümü değil, veri dağıtım aracıdır.

Failover Cluster Instance (FCI)

FCI, bir Windows Server Failover Cluster’ın node’larına kurulmuş tek bir SQL Server instance’ıdır. Aynı anda yalnızca bir node SQL Server’ı çalıştırır. Bu node arızalandığında cluster instance’ı başka bir node’da başlatır ve istemciler aynı sanal ağ adına (virtual network name) yeniden bağlanır.

Instance’ın tamamı taşındığı için içindeki her şey de taşınır: login’ler, SQL Server Agent job’ları, linked server’lar ve sunucu seviyesindeki ayarlar. FCI’ın en büyük gücü budur. En büyük zayıflığı ise storage’dır. Tüm node’lar aynı diskleri (SAN, Storage Spaces Direct ya da SMB paylaşımı) kullanır; yani storage tek hata noktasıdır ve FCI veri koruması için ona bağımlıdır.

Failover aslında servisin başka bir node’da yeniden başlatılmasıdır. SQL Server her veritabanında crash recovery çalıştırır, yani açık transaction’lar veritabanları online olmadan önce geri alınır. Arıza anında uzun süren bir transaction varsa failover da uzar.

Always On Availability Group

Availability group, bir grup kullanıcı veritabanının kopyasını her replikada tutar ve her replikanın kendi storage’ı vardır. Primary, transaction log kayıtlarını secondary’lere gönderir. Synchronous-commit bir replika her commit’i primary tamamlamadan önce onaylar, bu yüzden veri kaybı olmadan devralabilir. Asynchronous-commit bir replika beklemez; uzak DR lokasyonları için uygundur ama bir miktar veri kaybına izin verir.

Enterprise sürümde bir availability group, sekiz secondary replikaya ve primary dahil beş synchronous-commit replikaya kadar destekler. Secondary’ler read-only sorgulara hizmet edebilir, log backup ve copy-only full backup alabilir. İstemciler primary’yi takip eden bir listener üzerinden bağlanır. Windows’ta HA amaçlı bir availability group için Windows Server Failover Cluster gerekir; Linux’ta bu rolü Pacemaker üstlenir.

Listener, failover modları ve quorum’a daha ayrıntılı bakmak için SQL Server Always On rehberimize göz atın.

Basic Availability Group (Standard Sürüm)

SQL Server 2016’dan bu yana Standard sürüm, database mirroring’in yerini alan basic availability group’ları destekler. Normal availability group gibi çalışırlar ama sıkı sınırları vardır:

• Yalnızca iki replika: bir primary, bir secondary.
• Her availability group’ta tek veritabanı. Aynı instance’ta birden fazla basic grup oluşturabilirsiniz.
• Secondary’de okuma erişimi, yedekleme ve bütünlük kontrolü (DBCC CHECKDB) yok.
• Tam bir availability group’a yükseltilemezler. Enterprise’a geçişte silinip yeniden oluşturulmaları gerekir.

Log Shipping

Log shipping üç SQL Server Agent job’ından oluşur: primary’de transaction log yedeğini al, dosyayı bir ya da daha fazla secondary’ye kopyala ve orada restore et. Basittir, ucuzdur, uzun mesafelerde çalışır ve yavaş bağlantıları tolere eder. RPO kabaca yedekleme aralığı artı kopyalama süresidir.

Failover her zaman manueldir. Secondary, read-only raporlama için STANDBY modunda tutulabilir ama her restore sırasında kullanıcıların bağlantısı kesilir. Log shipping’e özgü bir özellik daha var: restore’ları bilerek geciktirebilirsiniz. Biri yıkıcı bir değişiklik çalıştırırsa secondary bir süre daha değişmemiş veriyi tutuyor olabilir.

Database Mirroring

Database mirroring SQL Server 2012’den bu yana deprecated durumda ve gelecekteki bir sürümde kaldırılacak. Hâlâ çalışıyor ama yeni sistemlerde kullanılmamalı. Microsoft’un önerisi, Standard sürümde basic availability group, Enterprise sürümde availability group kullanmaktır. Hâlâ mirroring kullanıyorsanız geçişi bir sonraki upgrade’inizde planlayın; ayrıntılar asenkron mirroring ile asenkron availability group karşılaştırmamızda.

Hangi SQL Server HA Seçeneği Size Uygun?

• Standard sürüm, bir ya da birkaç kritik veritabanı, iki sunucu: her veritabanı için bir basic availability group. DR da gerekiyorsa üçüncü bir sunucuya log shipping ekleyin.
• Çok sayıda Agent job’ı, login ve linked server, güvenilir ortak storage: instance’ın tamamı birlikte taşındığı için FCI. DR için başka bir lokasyona availability group ya da log shipping ekleyin.
• Enterprise sürüm ve dışarı alınacak bir raporlama yükü: HA için senkron bir replika ve raporlar için okunabilir bir secondary içeren availability group.
• Sınırlı bütçeyle ikinci bir lokasyon: log shipping ya da asenkron bir availability group replikası.
• Birkaç saatlik RTO kabul edilebiliyorsa: düzenli restore testleriyle desteklenen iyi tasarlanmış bir yedekleme planı ihtiyacınızın tamamı olabilir. İşletemeyeceğiniz bir karmaşıklığa yatırım yapmayın.

Availability Group Nasıl İzlenir?

Kimsenin izlemediği bir availability group başlı başına bir risktir. Deneyimimize göre izlenmeyen Always On ve replication gecikmesi, yeni devraldığımız ortamlarda en sık karşılaştığımız sorun kaynaklarından biridir. Bağlantısı kopmuş ya da geride kalan bir secondary, primary’de log truncation’ı da durdurur; transaction log disk dolana kadar büyür. Bu sorgu her replikadaki her veritabanının sağlık durumunu ve kuyruk boyutlarını gösterir:

SELECT ag.name                        AS ag_name,
       ar.replica_server_name,
       DB_NAME(drs.database_id)       AS database_name,
       drs.synchronization_state_desc,
       drs.synchronization_health_desc,
       drs.log_send_queue_size        AS log_send_queue_kb,
       drs.redo_queue_size            AS redo_queue_kb,
       drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups   AS ag ON ag.group_id   = drs.group_id
ORDER BY ag.name, ar.replica_server_name, database_name;

Büyüyen bir log_send_queue_kb, zorunlu (forced) bir failover’da kaybedilecek veri demektir. Büyüyen bir redo_queue_kb ise daha uzun bir failover demektir. sys.databases‘ta bir veritabanının log_reuse_wait_desc değeri AVAILABILITY_REPLICA gösteriyorsa bir replika log truncation’ı engelliyordur. Bu durumlar kullanıcılar fark etmeden birine ulaşsın diye SQL Server uyarılarını kurun.

Sık Yapılan High Availability Hataları

• HA’yı yedek sanmak. Replikalar, hataları ve bozulmaya yol açan değişiklikleri de sağlam veri kadar sadakatle kopyalar.
• Failover’ı hiç test etmemek. Hiç denenmemiş bir failover genellikle eksik login, job ya da firewall kuralı yüzünden başarısız olur.
• Asenkron replikaların hiçbir şey kaybetmediğini varsaymak. Send queue’da kalan her şey forced failover sonrasında kaybolur.
• Quorum tasarımını göz ardı etmek. Cluster quorum’u kaybettiğinde SQL Server sağlıklı olsa bile FCI ya da availability group offline olur.
• Panikle restart etmek. Failover sonrasında veritabanlarının recovery’yi bitirmesi gerekir. Yeniden restart etmek recovery’yi baştan başlatır. Önce neye bakılacağını kesinti runbook’umuzda anlattık.
• Plansız patch geçmek. Cluster’lar node node ilerleyen (rolling) bir süreç ister; bkz. AlwaysOn cluster’larda SQL Server ve Windows yamaları.