1. Giriş SQL Server her zaman Açık
1.1 Nedir SQL Server Sürekli Açık mı?
SQL Server Always On, Microsoft'un kapsamlı yüksek kullanılabilirlik ve felaket kurtarma çözümüdür ve 2017 yılında tanıtılmıştır. SQL Server 2012. Veritabanı yansıtma ve günlük gönderimi gibi önceki teknolojilere kıyasla önemli bir ilerlemeyi temsil eden bu teknoloji, kesinti süresini ve veri kaybını en aza indirirken verilere sürekli erişimi sağlar.
1.2 İşletmelerin Sürekli Erişim Sağlayan Çözümlere İhtiyaç Duymalarının Nedenleri
Günümüzün dijital ekonomisinde, veritabanı kesintileri doğrudan gelir kaybına, itibar zedelenmesine ve mevzuat uyumluluğu sorunlarına yol açmaktadır. Kuruluşlar, çeşitli arıza senaryolarına karşı koruma sağlarken neredeyse kesintisiz çalışma süresini garanti edebilen yüksek kullanılabilirlik çözümlerine ihtiyaç duymaktadır.
Geleneksel yedekleme ve geri yükleme prosedürleri, modern işletme gereksinimleri için yetersizdir. Kritik bir veritabanı arızalandığında, işletmeler yedeklerden geri yükleme için gereken saatleri karşılayamaz. Always On çözümleri, sistem arızalarının etkisini önemli ölçüde azaltarak, hizmeti saatler yerine saniyeler veya dakikalar içinde geri yükleyebilen otomatik arıza durumunda devreye girme özelliği sunar.
Temel erişilebilirliğin ötesinde, işletmelerin üretim veritabanlarından yoğun okuma gerektiren iş yüklerini kaldırmaları, kesinti olmadan bakım yapmaları ve site düzeyindeki felaketlere karşı korunmaları gerekir. SQL Server Always On, küçük ölçekli kurulumlardan küresel olarak dağıtılmış sistemlere kadar ölçeklenebilen birleşik bir mimari aracılığıyla tüm bu gereksinimleri karşılar.
1.3 Temel Kavramlar: RTO, RPO, HA ve DR
Kurtarma Süresi Hedefi (RTO) Bir arıza sonrasında kabul edilebilir maksimum kesinti süresini tanımlar; yani veritabanının ne kadar hızlı bir şekilde tekrar çevrimiçi olması gerektiğini belirtir.
Kurtarma Noktası Hedefi (RPO) Zaman bazında ölçülen, kabul edilebilir maksimum veri kaybını tanımlar; yani işletmenin yakın zamanda işleme alınan ne kadar veriyi kaybetmeyi göze alabileceğini belirler.
Yüksek Kullanılabilirlik (HA) Bu çözüm, aynı veri merkezi içindeki donanım arızaları veya yazılım çökmeleri gibi rutin arızaların neden olduğu kesinti sürelerini en aza indirmeye odaklanmaktadır.
Olağanüstü Durum Kurtarma (DR) Yüksek kullanılabilirlik (HA), tüm tesisleri etkileyen felaket olaylarını ele alır ve verilerin coğrafi olarak ayrı konumlarda kopyalarını tutar. Yüksek kullanılabilirlik (HA) kesinti süresini en aza indirmeye odaklanırken, felaket kurtarma (DR) büyük olaylar sırasında veri korumasını ve iş sürekliliğini sağlamaya odaklanır.
SQL Server Always On, tek bir birleşik mimari içinde hem yüksek kullanılabilirliği (HA) hem de felaket kurtarmayı (DR) destekler. Senkronize taahhüt modu, sıfıra yakın kurtarma hedefi (RTO) için otomatik arıza durumunda devralma ile RPO = 0 sağlar; asenkron taahhüt modu ise uzak lokasyonlar arasında daha düşük gecikme etkisi karşılığında olası veri kaybını kabul eder.
1.4 Sürekli Açık Çözümler
SQL Server Always On, farklı kullanılabilirlik ve altyapı gereksinimlerine uygun üç dağıtım seçeneği sunar. Bu kılavuz, üç seçeneğin tamamını kapsamaktadır:
- Sürekli Erişilebilirlik Grupları (AG): Paylaşımlı depolama olmadan veritabanı düzeyinde yüksek kullanılabilirlik ve felaket kurtarma.
- Always On Failover Cluster Instances (FCI): Paylaşımlı depolama kullanarak örnek düzeyinde yüksek kullanılabilirlik.
- AG + FCI birleşimi: Maksimum dayanıklılık için örnek düzeyinde ve veritabanı düzeyinde arıza durumunda devreye girme özelliğini birleştiren iki katmanlı koruma.
2. Sürekli Erişilebilirlik Grupları
Sürekli Açık Kullanılabilirlik Grupları (AG) Bu, kullanıcı veritabanları kümesini sürekli işlem günlüğü gönderimi yoluyla sekiz adede kadar ikincil kopyaya çoğaltan, veritabanı düzeyinde yüksek kullanılabilirlik ve felaket kurtarma çözümüdür.
2.1 Temel Özellikler
- Veritabanı düzeyinde yük devretme: Bireysel veritabanları veya gruplar, ana veritabanından bağımsız olarak yük devretme işlemi gerçekleştirebilir. SQL Server misal;
- Enterprise Edition'da en fazla dokuz kopya (birincil, sekiz ikincil);
- Veri kaybını önlemek için senkron taahhüt modu; uzak felaket kurtarma kopyaları için asenkron taahhüt modu;
- Birincil sunucu kullanılamaz hale geldiğinde eşzamanlı kopyalar için otomatik yük devretme;
- Raporlama ve yedekleme iş yüklerini hafifletmek için okunabilir ikincil kopyalar;
- Kullanılabilirlik grubu dinleyicisi, mevcut birincil sunucuya otomatik olarak yönlendirme yapan tek bir bağlantı uç noktası sağlar.
2.2 Uygulama Adımları
- Active Directory hizmet hesaplarını hazırlayın ve tüm düğümlerde izinleri yapılandırın;
- Katılan tüm sunuculara Windows Server Failover Clustering'i kurun ve doğrulayın;
- kurmak SQL Server Her düğümde tutarlı yollar ve ayarlar kullanılarak bağımsız bir örnek olarak;
- Always On Kullanılabilirlik Grupları özelliğini şu şekilde etkinleştirin: SQL Server Yapılandırma Yöneticisi veya PowerShell;
- Veritabanlarını tam kurtarma moduna ayarlayın ve tam ve günlük yedeklemelerini alın;
- Kullanılabilirlik grubunu oluşturun, kopyaları ekleyin ve kullanılabilirlik ve yük devretme modlarını yapılandırın;
- Otomatik tohumlama veya manuel yedekleme ve geri yükleme yöntemlerini kullanarak ikincil kopyaları oluşturun;
- Kullanılabilirlik grubu dinleyicisini oluşturun ve istemci bağlantısını doğrulayın.
Adım adım ayrıntılı kılavuz için lütfen sayfamıza bakın. Always On Kullanılabilirlik Grupları kapsamlı kılavuzu.
2.3 En İyisi
- Veri kaybının sıfır olduğu ve otomatik yedekleme gerektiren, görev açısından kritik öneme sahip veritabanları;
- Raporlama veya yedekleme yükünü hafifletme amacıyla okunabilir ikincil sunuculara ihtiyaç duyan iş yükleri;
- Afet kurtarma için birden fazla lokasyona yayılan konuşlandırmalar;
- Mevcut paylaşımlı depolama altyapısı olmayan ortamlar.
2.4 Artıları
- Paylaşımlı depolama alanı gerekmez — her kopya bağımsız yerel depolama alanı kullanır;
- Tek bir yapılandırmada hem yüksek kullanılabilirliği (HA) hem de felaket kurtarmayı (DR) destekler;
- Okunabilir ikincil dosyalar birincil iş yükünü azaltır;
- Veritabanı düzeyindeki ayrıntılandırma, her veritabanı grubu için farklı yük devretme politikalarına olanak tanır.
2.5 Eksileri
- Tüm özellik seti için Enterprise Edition gereklidir (Standart sürüm, önemli sınırlamalarla Temel AG'yi destekler);
- Senkronize taahhüt modu, ağ gidiş-dönüş süresiyle orantılı olarak yazma gecikmesi ekler;
- Oturum açma işlemleri, SQL Agent görevleri ve bağlantılı sunucular manuel senkronizasyon gerektirir. SQL Server 2019 ve öncesi;
- Tüm kopyaların aynı Windows Server Yük Devretme Kümesinin düğümlerinde bulunması gerekir.
2.6 Referansları
- Microsoft Resmi Belgesi: Sürekli Erişilebilirlik grubu nedir?
- Microsoft Resmi Belgesi: Always On Kullanılabilirlik Gruplarıyla Çalışmaya Başlamak
3. Always On Yük Devretme Kümesi Örnekleri
Always On Failover Cluster Instances (FCI) Tek bir sunucu çalıştırarak örnek düzeyinde yüksek kullanılabilirlik sağlar. SQL Server Aynı depolama alanını paylaşan birden fazla fiziksel düğümde örnek. Aktif düğüm arızalandığında, SQL Server Bekleme düğümündeki örnek otomatik olarak yeniden başlatılır, bu da geçişi istemci uygulamaları için şeffaf hale getirir.
3.1 Temel Özellikler
- Örnek düzeyinde arıza durumunda devralma: Örnekteki tüm veritabanları tek bir birim olarak birlikte arıza durumunda devralma gerçekleştirir;
- Tüm düğümler tarafından erişilebilen paylaşımlı depolama (Depolama Alanı Ağı (SAN), iSCSI, Storage Spaces Direct veya SMB);
- Sanal ağ adı ve sanal IP adresi, hangi düğümün aktif olduğuna bakılmaksızın istikrarlı bir bağlantı noktası sağlar;
- Windows Server Yük Devretme Kümelemesi, düğüm sağlığı izleme, çoğunluk ve yük devretme düzenlemesini yönetir;
- Aktif/Bekleme, Aktif/Aktif, N+1 ve N+M düğüm yapılandırma türlerini destekler.
3.2 Uygulama Adımları
- Kümedeki tüm düğümlere paylaşımlı depolama alanı sağlayın ve bunları bağlayın;
- Yük Devretme Kümeleme özelliğini yükleyin ve küme yapılandırmasını doğrulayın;
- Windows Server Yük Devretme Kümesini oluşturun ve quorum'u yapılandırın;
- çalıştırmak SQL Server Yük devretme kümesi seçeneğini seçerek ve sanal ağ adını ve paylaşılan depolama yollarını belirterek kurulum yapın;
- ek düğümler ekle SQL Server Yük devretme kümesi örneği;
- Düğümler arasında manuel bir yük devretme işlemi test ederek yük devretme davranışını doğrulayın.
Adım adım ayrıntılı kılavuz için lütfen sayfamıza bakın. SQL Server Yük Devretme Kümesi Tam Kılavuzu.
3.3 En İyisi
- Mevcut paylaşımlı depolama altyapısına (SAN veya iSCSI) sahip ortamlar;
- Veritabanlarının tamamının birlikte arıza durumunda devreye girmesi gereken, örnek düzeyinde arıza durumunda devreye girme gerektiren uygulamalar;
- Müşteri şeffaflığının kritik olduğu ve uygulama tarafında hiçbir değişikliğin kabul edilemez olduğu senaryolar;
- Tek örnekli arıza durumunda yedekleme modelinin basitliğine öncelik veren kuruluşlar.
3.4 Artıları
- İstemci yeniden yapılandırmasına gerek kalmadan, örnek düzeyinde otomatik arıza durumunda devralma;
- Veri çoğaltma yükü yok — tüm düğümler aynı depolama alanına erişiyor;
- Tüm veritabanları için eş zamanlı olarak öngörülebilir arıza durumunda devreye girme davranışı;
- Donanım kullanımını optimize etmek için esnek düğüm yapılandırmalarını (Aktif/Aktif, N+1, N+M) destekler.
3.5 Eksileri
- Paylaşımlı depolama, depolama biriminin kendisi yedekli olmadığı sürece potansiyel bir tek hata noktasıdır;
- yalnızca bir düğüm çalışıyor SQL Server bir seferde — ikincil düğümlerde okuma yükü dengelemesi yok;
- Kullanılabilirlik grubuyla eşleştirilmedikçe yerleşik bir felaket kurtarma özelliği bulunmamaktadır;
- Paylaşımlı depolama altyapısı, AG'ye kıyasla maliyet ve karmaşıklık artışı sağlar.
3.6 Referansları
- Microsoft Resmi Belgesi: Always On Failover Küme Örnekleri (SQL Server)
4. Kullanılabilirlik Gruplarını Yük Devretme Kümesi Örnekleriyle Birleştirin
Hem örnek düzeyinde hem de veritabanı düzeyinde korumaya ihtiyaç duyan kuruluşlar için, SQL Server Bu yapılandırma, Yük Devretme Kümesi Örneklerinde (FCI) kullanılabilirlik grubu kopyalarının barındırılmasını destekler. Bu yapılandırmada, her FCI düğümü tek bir kullanılabilirlik kopyası gibi davranır, bu nedenle bir FCI yük devretmesi kullanılabilirlik grubu için şeffaftır, AG yük devretmesi ise siteler genelinde veritabanı düzeyinde koruma sağlar. Bu kombinasyon, mevcut en kapsamlı yüksek kullanılabilirlik ve felaket kurtarma kapsamını sunar. SQL Server.
4.1 Temel Özellikler
- İki katmanlı yük devretme: FCI, örnek düzeyindeki düğüm arızalarını ele alır; AG ise site düzeyindeki veya çoğaltma düzeyindeki arızaları ele alır;
- Her bir FCI, içerdiği düğüm sayısından bağımsız olarak, kullanılabilirlik grubu içinde tek bir kopya olarak sayılır;
- FCI tarafından barındırılan kopyalar, standart FCI gereksinimlerine göre hala paylaşımlı depolama alanına ihtiyaç duymaktadır;
- FCI'larda barındırılan AG kopyaları yalnızca manuel yük devretmeyi destekler; FCI'da barındırılan kopyalar için otomatik yük devretme özelliği mevcut değildir;
- Bağımsız örnekler, FCI tarafından barındırılan kopyalarla aynı kullanılabilirlik grubunda yer alabilir.
4.2 Uygulama Adımları
- Her bir FCI'yı standart FCI kurulum prosedürlerini izleyerek bağımsız olarak devreye alın ve doğrulayın;
- Tüm FCI düğümlerinin ve bağımsız çoğaltma düğümlerinin aynı Windows Server Yük Devretme Kümesine ait olduğundan emin olun;
- Her FCI örneğinde Always On Kullanılabilirlik Grupları özelliğini etkinleştirin;
- Olası herhangi bir FCI arıza durumundan sonra hiçbir WSFC düğümünün aynı kullanılabilirlik grubunun iki kopyasına ev sahipliği yapmadığını doğrulayın;
- Kullanılabilirlik grubunu oluşturun, FCI örneklerini çoğaltma olarak belirleyin ve FCI'da barındırılan tüm çoğaltmalar için manuel yük devretme modunu yapılandırın;
- İkincil kopyaları oluşturun ve kullanılabilirlik grubu dinleyicisini yapılandırın.
FCI kurulum detayları için lütfen sayfamıza bakın. SQL Server Yük Devretme Kümesi (Failover Cluster) için kapsamlı kılavuz. AG kurulum detayları için Always On Kullanılabilirlik Grupları (Always On Availability Groups) kapsamlı kılavuzumuza bakın.
4.3 En İyisi
- Hem bireysel düğüm arızalarına hem de tesis düzeyindeki felaketlere karşı koruma gerektiren, görev açısından kritik öneme sahip ortamlar;
- FCI'yı zaten kullanan ve siteler arası felaket kurtarma özelliğini eklemeye ihtiyaç duyan kuruluşlar;
- Azami veri koruma ve erişilebilirlik SLA'larının zorunlu olduğu düzenlemeye tabi sektörler;
- Örnek düzeyinde ve veritabanı düzeyinde arıza durumunda devreye girme politikalarının bir arada bulunması gereken büyük ölçekli dağıtımlar.
4.4 Artıları
- Maksimum koruma: düğüm arızaları FCI tarafından, saha arızaları AG tarafından ele alınır;
- FCI yük devretmesi kullanılabilirlik grubu için şeffaftır — AG, FCI yük devretmesi sırasında herhangi bir kopya değişikliği görmez;
- Esnek topoloji: FCI tarafından barındırılan ve bağımsız kopyaları aynı kullanılabilirlik grubunda karıştırın.
4.5 Eksileri
- FCI tarafından barındırılan kopyalar yalnızca manuel AG yük devretmeyi destekler; bu kopyalar için otomatik AG yük devretme özelliği kullanılamaz;
- Bir FCI arıza durumunda tek bir düğümün aynı AG'nin iki kopyasına ev sahipliği yapmasını önlemek için dikkatli bir WSFC düğüm planlaması gerektirir;
- AG veya FCI'ya kıyasla daha yüksek altyapı maliyeti ve operasyonel karmaşıklık;
- Her bir FCI bileşeni için paylaşımlı depolama alanı hala gereklidir.
4.6 Referansları
- Microsoft Resmi Belgesi: Yük Devretme Kümelemesi ve Always On Kullanılabilirlik Grupları (SQL Server)
- Microsoft Resmi Belgesi: Sürekli Erişilebilirlik grubu nedir?
- Microsoft Resmi Belgesi: Always On Kullanılabilirlik Gruplarıyla Çalışmaya Başlamak
- Microsoft Resmi Belgesi: Always On Failover Küme Örnekleri (SQL Server)
5. Sürekli Açık Çözümlerin Karşılaştırılması
5.1 Özellik Karşılaştırma Tablosu
| Özellik | Kullanılabilirlik Grupları | Yük Devretme Kümesi Örnekleri | AG + FCI Kombine |
|---|---|---|---|
| Yük devretme kapsamı | Veritabanı düzeyinde | Örnek düzeyi | Her ikisi de |
| Paylaşımlı depolama alanı gereklidir. | Yok hayır | Evet | Evet (FCI bileşeni için) |
| Veri kopyalama | Her bir kopyaya ilişkin log tabanlı bilgiler. | Yok (paylaşımlı depolama) | FCI'ler arasında logaritmik tabanlı |
| Otomatik yük devretme | Evet (senkron kopyalar) | Evet | FCI: Evet; AG: Hayır |
| Okunabilir ikincil bilgiler | Evet | Yok hayır | Evet (AG bileşeni) |
| Olağanüstü durum kurtarma | Gömme | Dahili değil | Gömme |
| Max replikaları | 9 (Kurumsal) | - | 9 (Kurumsal) |
| Altyapı karmaşıklığı | Orta | Orta | Yüksek |
| Ücret | Daha düşük (SAN gerekmez) | Daha yüksek (SAN gerekli) | En yüksek |
5.2 Sürekli Bağlantı Çözümünüzü Seçin
Depolama altyapınızla başlayın: Mevcut paylaşımlı depolama alanınız yoksa, Kullanılabilirlik Grupları (Availability Groups) hem yüksek kullanılabilirlik (HA) hem de felaket kurtarma (DR) için doğal ve en uygun maliyetli seçenektir. Zaten bir SAN ortamı kullanıyorsanız ve örnek düzeyinde arıza durumunda yedeklemeye ihtiyacınız varsa, FCI daha basit bir seçenektir; ancak ileride siteler arası DR gereksiniminiz olursa, daha sonra AG eklemeyi planlayın.
AG + FCI kombinasyonunu yalnızca her iki koruma katmanına da gerçekten ihtiyacınız olduğunda ve artan karmaşıklığı yönetmek için operasyonel olgunluğa sahip olduğunuzda seçin. Unutulmaması gereken en önemli kısıtlama, FCI tarafından barındırılan AG kopyalarının otomatik AG yük devretmesini desteklememesidir; bu nedenle bu topoloji, kullanılabilirlik grubu düzeyinde yük devretmeler için manuel müdahale gerektirir.
Günümüzdeki çoğu sıfırdan kurulum için Always On Availability Groups önerilen başlangıç noktasıdır: hem yüksek kullanılabilirliği (HA) hem de felaket kurtarmayı (DR) kapsar, paylaşımlı depolama gerektirmez ve okunabilir ikincil sunucuları destekler; bu özellikler tek başına FCI tarafından karşılanamaz.
6. En İyi Uygulamalar SQL Server Always On Solutions
6.1 Planlama ve Tasarım
- Always On çözümü seçmeden önce RTO ve RPO gereksinimlerini tanımlayın; bu hedefler, senkron veya asenkron taahhüt modunun uygun olup olmadığını ve otomatik arıza durumunda devralmanın mümkün olup olmadığını doğrudan belirler.
- Yük devretme durumunda, en yüksek yük senaryoları da dahil olmak üzere, birincil sunucunun tüm iş yükünü karşılayabilecek şekilde ikincil kopyaların boyutunu ayarlayın.
- AG dağıtımları için, yazma gecikmesi etkisini en aza indirmek amacıyla senkron kopyaları aynı veri merkezine veya düşük gecikmeli ağa yerleştirin. Asenkron modu coğrafi olarak uzak felaket kurtarma kopyaları için ayırın.
- Oy sayısının tek olduğu bir çoğunluk sistemi tasarlayın. İki düğümlü kümeler için, bölünmüş beyin senaryolarını önlemek amacıyla üçüncü bir oy olarak dosya paylaşımı veya bulut tanığı ekleyin.
- Çoklu alt ağ dağıtımları için ağ topolojinizi dikkatlice planlayın. Her alt ağın kendi dinleyici IP adresine ihtiyacı vardır ve istemcilerin bağlantı dizelerinde MultiSubnetFailover=True ayarının bulunması gerekir.
6.2 Uygulama Yönergeleri
- Tutarlı kullanın SQL Server Tüm kopyalarda sürüm, baskı ve kümülatif güncelleme seviyeleri. Karışık yama seviyeleri, arıza durumunda beklenmedik davranışlara neden olabilir.
- Küme kalp atışı trafiği için, uygulama trafiğinden ayrı olarak, özel ağ arayüzleri yapılandırın.
- Veritabanının ilk senkronizasyonu için otomatik veri başlatmayı etkinleştirin. SQL Server 2016 ve sonrası sürümlerde, çoğu senaryoda yedeklerin ikincil kopyalara manuel olarak kopyalanması ihtiyacını ortadan kaldırır.
- AG + FCI topolojileri için, her FCI düğüm yapılandırma değişikliğinden sonra, hiçbir WSFC düğümünün aynı kullanılabilirlik grubunun iki kopyasına ev sahipliği yapamayacağından emin olun.
- Her zaman kullan SQL Server Kullanılabilirlik grubu yük devretmelerini yönetmek için Management Studio veya Transact-SQL kullanın; asla Yük Devretme Kümesi Yöneticisini doğrudan kullanmayın, çünkü bu yönetici kullanılabilirlik grubu senkronizasyon durumundan haberdar değildir ve uzun süreli kesintilere veya veri kaybına neden olabilir.
6.3 İzleme ve Bakım
- Kullanılabilirlik grubu kontrol panelini kullanarak senkronizasyon sağlığını, gönderme kuyruğunu ve yineleme kuyruğunu düzenli olarak izleyin. SQL Server Yönetim Stüdyosu veya Dinamik Yönetim Görünümleri (DMV'ler). İkincil sunucudaki artan yeniden işlem kuyruğu, arıza durumunda kurtarma işlemini geciktirecek bir G/Ç darboğazına işaret eder.
- Birincil sunucudaki bütünlük kontrollerini ikincil sunuculara aktarmak için ikincil sunucularda DBCC CHECKDB komutunu çalıştırın. Daha fazla bilgi için ilgili kılavuzumuza bakın. DBCC CHECKDB kılavuzu Ayrıntılar için.
- Uygula SQL Server Kademeli yükseltmeler kullanan yamalar: önce ikincil kopyalara yama uygulanır, ardından yama uygulanmış ikincil kopyaya planlı manuel bir geçiş yapılır ve son olarak birincil kopyaya yama uygulanır. Bu, kesinti süresini tek bir geçiş süresiyle sınırlandırır.
- Üretim dışı ortamlarda arıza durumunda otomatik geçişi düzenli olarak test edin. Daha önce hiç test edilmemiş otomatik arıza durumunda geçiş, güvenilir bir kurtarma stratejisi değildir.
- Kullanılabilirlik grubu sağlık durumu değişiklikleri, çoğaltma rolü geçişleri ve senkronizasyon hataları için uyarıları aşağıdaki komutları kullanarak yapılandırın. SQL Server Aracı veya özel bir izleme aracı gibi SQL Server performans izleyicisi.
7. SSS
S: nedir SQL Server Sürekli Açık mı?
A: SQL Server Always On, Microsoft'un 2018 yılında tanıttığı yüksek kullanılabilirlik ve felaket kurtarma platformudur. SQL Server 2012. Donanım, yazılım veya site arızaları durumunda otomatik arıza durumunda devralma, veri yedekliliği ve veritabanlarına sürekli erişim sağlayan iki teknolojiyi kapsar: Always On Availability Groups ve Always On Failover Cluster Instances.
S: Always On Kullanılabilirlik Grupları ile Yük Devretme Kümesi Örnekleri arasındaki fark nedir?
A: Kullanılabilirlik Grupları (Availability Groups) veritabanı düzeyinde çalışır, log gönderimi yoluyla verileri bağımsız ikincil kopyalara çoğaltır ve paylaşımlı depolama gerektirmez. Yük Devretme Kümesi Örnekleri (Failover Cluster Instances) örnek düzeyinde çalışır, tüm düğümler tarafından erişilebilen paylaşımlı depolama gerektirir ve tüm veritabanlarını bir birim olarak birlikte devreder. AG okunabilir ikincil kopyaları ve yerleşik felaket kurtarma (DR) özelliğini destekler; FCI desteklemez.
S: Always On Kullanılabilirlik Grupları için paylaşımlı depolama alanına ihtiyacım var mı?
A: Hayır. Her AG kopyası, veritabanlarının kendi bağımsız kopyasını yerel depolama alanında tutar. Paylaşımlı depolama yalnızca AG kopyalarını barındırmak için Yük Devretme Kümesi Örnekleri kullanıyorsanız gereklidir.
S: Always On özelliğini kullanabilir miyim? SQL Server Standart Sürüm mü?
A: SQL Server Standart Sürüm, aşağıdaki sürümlerden itibaren Temel Kullanılabilirlik Gruplarını destekler: SQL Server 2016 sürümü, ancak önemli sınırlamalarla: AG başına bir veritabanı, en fazla iki kopya ve okunabilir ikincil destek yok. FCI, bu kısıtlamalar olmadan Standart Sürümde mevcuttur. Always On işlevselliğinin tamamı için Kurumsal Sürüm gereklidir.
S: Bir kullanılabilirlik grubunda en fazla kaç kopya bulunabilir?
A: SQL Server Enterprise Edition, en fazla dokuz kopyayı destekler: bir birincil ve sekiz ikincil. Dağıtılmış kullanılabilirlik grupları, bunu iki ayrı kullanılabilirlik grubu üzerinden 18 kopyaya kadar genişletebilir.
S: FCI'da barındırılan replikalar otomatik AG yük devretme özelliğini kullanabilir mi?
A: Hayır. Bir kullanılabilirlik kopyası bir Yük Devretme Kümesi Örneğinde barındırıldığında, bu kopya için otomatik kullanılabilirlik grubu yük devretmesi desteklenmez. FCI'da barındırılan kopyaları içeren tüm AG yük devretmeleri manuel müdahale gerektirir.
S: Senkron ve asenkron commit modları arasındaki fark nedir?
A: Senkron taahhüt modu, birincil sunucunun ikincil sunucunun günlük kayıtlarını güçlendirmesini beklemesini gerektirir ve bu da ek yazma gecikmesi pahasına sıfır veri kaybı (RPO = 0) sağlar. Asenkron taahhüt modu, birincil sunucunun beklemeden taahhüt etmesine olanak tanır, bu da gecikmeyi azaltır ancak ikincil sunucu tüm günlük kayıtlarını almadan önce birincil sunucu arızalanırsa veri kaybı riskini artırır. Yerel yüksek kullanılabilirlik (HA) kopyaları için senkron, uzak felaket kurtarma (DR) kopyaları için asenkron modu kullanın.
S: Ne kadar sürer? SQL Server Always On yedekleme seçeneği?
A: Senkron AG replikası için otomatik yük devretme işlemi normal koşullar altında genellikle 30 saniyeden kısa sürede tamamlanır. FCI yük devretme işlemi, veritabanı kurtarma süresine bağlı olarak genellikle 20-60 saniye sürer. Gerçek süre, iş yüküne, veritabanı boyutuna ve WSFC'de yapılandırılan sağlık kontrolü zaman aşımı ayarlarına bağlıdır.
S: Yedekleme işlemi sırasında istemci bağlantılarına ne olur?
A: Yük devretme gerçekleştiğinde mevcut bağlantılar kesilir. Kullanılabilirlik grubu dinleyicisini kullanan ve bağlantı yeniden deneme mantığı içeren uygulamalar, yük devretme tamamlandıktan sonra otomatik olarak yeni birincil sunucuya yeniden bağlanır. Bağlantı dizelerine MultiSubnetFailover=True eklemek, çoklu alt ağ dağıtımlarında yeniden bağlantı hızını artırır.
S: Nasıl başvuru yaparım? SQL Server Sürekli açık bir ortamda minimum kesinti süresiyle yamalar nasıl uygulanır?
A: Kademeli yükseltmeler kullanın: önce ikincil kopyaları yamalayın, ardından yamalanmış ikincil kopyaya planlı manuel bir geçiş gerçekleştirin ve son olarak eski birincil kopyayı yamalayın. Bu, kesinti süresini tek bir planlı geçişin süresiyle sınırlandırır; bu da genellikle bir dakikadan azdır.
S: Always On Kullanılabilirlik Gruplarını Yük Devretme Kümesi Örnekleriyle birleştirebilir miyim?
A: Evet. Hem örnek düzeyinde hem de veritabanı düzeyinde arıza koruması sağlamak için AG kopyalarını FCI örneklerinde barındırabilirsiniz. Her FCI, tek bir AG kopyası olarak sayılır. Bu topoloji, olası herhangi bir FCI arızasından sonra hiçbir düğümün aynı AG'nin iki kopyasını barındırmamasını sağlamak için dikkatli bir WSFC düğüm planlaması gerektirir.
S: Always On ortamında veritabanım bozulursa ne yapmalıyım?
A: Öncelikle, bozulmanın tüm replikalarda mı yoksa yalnızca birincil replikada mı olduğunu kontrol edin. Sağlıklı bir ikincil replika varsa, hemen ona geçiş yapın. Tüm replikalarda bozulma varsa, temiz bir yedeklemeden geri yükleyin. Bozulmayı erken yakalamak için ikincil replikalarda düzenli olarak DBCC CHECKDB komutunu çalıştırın. Yedeklemeler de etkilenmişse, özel bir çözüm kullanın. SQL Server veri kurtarma aracı Son çare olarak hasarlı MDF dosyalarından veri çıkarma girişiminde bulunulabilir.
S: Always On Kullanılabilirlik Grupları, eski sistemlerle karşılaştırıldığında nasıl bir özellik taşıyor? SQL Server HA çözümleri?
A: AG, aşağıdaki gibi daha eski teknolojilerin yerini almaktadır: günlük nakliyesi hem de kopyaGünlük gönderimi manuel arıza durumunda devralma gerektirir ve otomatik rol geçişi yoktur; çoğaltma, yüksek kullanılabilirlik yerine veri dağıtımı için tasarlanmıştır. AG, otomatik arıza durumunda devralma, senkronize taahhütle sıfır veri kaybı ve okunabilir ikincil sunucular sunar; bu özellikler bu teknolojilerin sunamadığı yeteneklerdir.
8. Sonuç
SQL Server Always On, yüksek kullanılabilirlik ve felaket kurtarma için esnek, kurumsal düzeyde bir platform sağlar. Always On Kullanılabilirlik Grupları, çoğu modern dağıtım için doğru seçimdir: paylaşımlı depolama ihtiyacını ortadan kaldırır, okunabilir ikincil sunucuları destekler ve tek bir yapılandırmada hem yerel yüksek kullanılabilirliği hem de siteler arası felaket kurtarmayı yönetir. Yük Devretme Kümesi Örnekleri, örnek düzeyinde yük devretme ve mevcut paylaşımlı depolama altyapısının birincil gereksinimler olduğu durumlarda sağlam bir seçenek olmaya devam eder. Her iki teknolojinin birleştirilmesi, daha büyük altyapı yatırımı ve operasyonel karmaşıklık pahasına, mevcut en derin korumayı sağlar.
Hangi çözümü seçerseniz seçin, temel prensipler aynıdır: Öncelikle RTO ve RPO gereksinimlerinizi belirleyin, topolojinizi bu hedeflere göre tasarlayın ve arıza durumunda yedeklemeyi düzenli olarak test edin. İyi uygulanmış ve kapsamlı bir şekilde test edilmiş bir Always On çözümü, üretim arızaları meydana geldiğinde öngörülebilir bir şekilde kurtarma sağlayacaktır.
Yazar Hakkında
Yuan Sheng 10 yılı aşkın deneyime sahip kıdemli bir veritabanı yöneticisidir (DBA) SQL Server ortamlar ve kurumsal veritabanı yönetimi alanında uzmanlaşmıştır. Finansal hizmetler, sağlık ve üretim sektörlerindeki yüzlerce veritabanı kurtarma senaryosunu başarıyla çözmüştür.
Yuan şu konuda uzmanlaşmıştır: SQL Server Veritabanı kurtarma, yüksek erişilebilirlik çözümleri ve performans optimizasyonu alanlarında kapsamlı uygulamalı deneyime sahiptir. Terabaytlarca veri tabanını yönetme, Always On Kullanılabilirlik Grupları uygulama ve kritik öneme sahip iş sistemleri için otomatik yedekleme ve kurtarma stratejileri geliştirme konularında kapsamlı uygulamalı deneyime sahiptir.
Yuan, teknik uzmanlığı ve pratik yaklaşımıyla, veritabanı yöneticilerinin ve BT profesyonellerinin karmaşık sorunları çözmelerine yardımcı olan kapsamlı kılavuzlar oluşturmaya odaklanıyor. SQL Server Zorlukları verimli bir şekilde çözer. En son gelişmelerle güncel kalır. SQL Server Microsoft'un gelişen veritabanı teknolojilerini ve sürümlerini takip ederek, önerilerinin gerçek dünyadaki en iyi uygulamaları yansıttığından emin olmak için kurtarma senaryolarını düzenli olarak test ediyor.
hakkında sorularınız var SQL Server Kurtarma veya ek veritabanı sorun giderme kılavuzuna mı ihtiyacınız var? Yuan memnuniyetle karşılar geri bildirim ve öneriler Bu teknik kaynakların iyileştirilmesi için.