Aracılığıyla paylaş

Yük Devretme ve Yük Devretme Modları (Her Zaman Açık Kullanılabilirlik Grupları)

Şunlar için geçerlidir: SQL Server

Bu makalede, SQL Server AlwaysOn kullanılabilirlik grupları için yük devretme ve yük devretme modları açıklanmaktadır.

Genel Bakış

Kullanılabilirlik grubu bağlamında, kullanılabilirlik replikalarının birincil ve ikincil rolleri, genellikle yük devretme olarak bilinen bir işlemde değiştirilebilir. Üç yük devretme biçimi vardır: otomatik yük devretme (veri kaybı olmadan), planlı el ile yük devretme (veri kaybı olmadan) ve zorlamalı el ile yük devretme (olası veri kaybıyla), genellikle zorlamalı yük devretmeolarak adlandırılır. Hem otomatik hem de planlı manuel yük devretme tüm verilerinizi korur. Kullanılabilirlik grubu, kullanılabilirlik kopyası seviyesinde devredilir. Diğer bir ifadeyle, bir kullanılabilirlik grubu ikincil çoğaltmalarından birine (geçerli yük devretme hedefi) yük devreder.

Uyarı

Veritabanı Düzeyinde Sistem Durumu Algılama yapılandırılmadığı sürece, veritabanı düzeyinde veri dosyasının kaybı, veritabanının silinmesi veya işlem günlüğünün bozulması nedeniyle veritabanı şüpheli duruma gelmesi gibi sorunlar, kullanılabilirlik grubunun yük devretmesine neden olmaz.

Yük devretme sırasında yük devretme hedefi birincil rolü devralır, veritabanlarını kurtarır ve bunları yeni birincil veritabanları olarak çevrimiçi duruma getirir. Eski birincil çoğaltma örneği kullanılabilir olduğunda, ikincil role geçer. Veritabanları ise ikincil veritabanları haline gelir. Potansiyel olarak, bu roller birden çok hataya yanıt olarak veya yönetim amacıyla ileri geri (veya farklı bir yük devretme hedefine) geçiş yapabilir.

Belirli bir kullanılabilirlik çoğaltmasının desteklediği yük devretme biçimleri, yük devretme modu özelliği tarafından belirtilir. Belirli bir kullanılabilirlik replikası için olası yük devretme modları, replikanın kullanılabilirlik moduna bağlı olarak aşağıdaki gibidir:

  • Eşzamanlı taahhüt replikaları iki ayarı destekler: otomatik veya manuel. "Otomatik" ayarı hem otomatik yük devretmeyi hem de manuel yük devretmeyi destekler. Veri kaybını önlemek için, otomatik yük devretme ve planlı yük devretme, yük devretme hedefinin sağlıklı bir eşitleme durumuna sahip zaman uyumlu işlem yapan bir ikincil çoğaltma olmasını gerektirir (bu, yük devretme hedefinde yer alan her ikincil veritabanının ilgili birincil veritabanıyla eşitlendiğini gösterir). Bir ikincil kopya, bu koşulların her ikisini de karşılamadığında yalnızca zorunlu yük devretmeyi destekler. Zorlamalı yük devretme, çözümlenme durumundaki çoğaltmalarda da desteklenir.

  • Zaman uyumsuz işleme çoğaltmaları yalnızca el ile yük devretme modunu destekler. Ayrıca, hiçbir zaman eşitlenmedikleri için yalnızca zorlamalı yük devretmeyi desteklerler.

Uyarı

Yük devretme işleminden sonra, birincil veritabanlarına erişmesi gereken istemci uygulamalarının yeni ana çoğaltmaya bağlanması gerekir. Eğer yeni ikincil kopya, salt okunur erişime izin verecek şekilde yapılandırılmışsa, salt okunur istemci uygulamaları buna bağlanabilir. İstemcilerin bir kullanılabilirlik grubuna nasıl bağlanacakları hakkında bilgi için bkz. Kullanılabilirlik Grubu Dinleyicileri, İstemci Bağlantısı ve Uygulama Yük Devretme (SQL Server).

SQL Server 2025 değişiklikleri

SQL Server 2025 aşağıdaki değişiklikleri tanıtır:

Kalıcı sağlık sorunları için hızlı yük devretme

Always On kullanılabilirlik grubu ortamında, Windows Yük Devretme Kümesi (WSFC) kullanılabilirlik grubunun ve çoğaltmalarının sağlığını izler. Birincil kopyada bir sağlık sorunu algılandığında, WSFC düzeltici eylemler dizisini tetikler. Varsayılan olarak, WSFC mevcut çoğaltmada kullanılabilirlik grubu kaynağını yeniden başlatır. WSFC kaynağı yeniden çevrimiçi yapamazsa, WSFC kullanılabilirlik grubu kaynağını başka bir çoğaltmaya devredemez. Bu düzeltici eylemler dizisi geçici hatalar için etkili olsa da, geçici olmayan hatalar için yük devretmede gecikmelere neden olabilir.

WSFC'nin yük devretme davranışı RestartThreshold değeri ile kontrol edilir. Varsayılan olarak, RestartThreshold her zaman açık bir kullanılabilirlik grubu için 1 olarak ayarlanmıştır; bu, WSFC'nin geçerli düğümdeki kaynağı yük devretme işlemi gerçekleşmeden önce yeniden başlatmaya çalıştığı anlamına gelir.

SQL Server 2025'den (17.x) başlayarak Always On kullanılabilirlik grubu için değerini 0 olarak ayarlayabilirsiniz RestartThreshold . Bu, WSFC'ye kalıcı bir sistem durumu sorunu algılandığında kullanılabilirlik grubu kaynağının yükünü hemen devretmesini söyler. Bu, kapalı kalma süresini en aza indirmek ve kullanılabilirlik grubunun iyi durumdaki bir çoğaltmada her zaman kullanılabilir olduğundan emin olmak istediğiniz senaryolar için kullanışlıdır.

Belirgin bir ödünleşim vardır.

  • 1 olarak ayarlandığında RestartThreshold , kullanılabilirlik grubunuz geçici hatalara daha dayanıklıdır ve daha hızlı çevrimiçi olur. Ancak, kalıcı hatalar için yük devretme süresi ve kesinti süresi daha uzun olabilir.
  • RestartThreshold 0 olarak ayarlandığında, kullanılabilirlik grubunuz geçici hatalara daha az tolerans gösterir, bu nedenle gereksiz yük devretmelere yol açabilir. Ancak, kalıcı hatalar için yük devretme ve kapalı kalma süresi daha kısa olabilir.

Her Zaman Açık kullanılabilirlik grubu kaynağını ayarlamak için Yük Devretme Kümesi Yöneticisi'ni RestartThreshold veya PowerShell'i kullanabilirsiniz.

Örneğin, RestartThreshold adlı kullanılabilirlik grubunu 0 olarak ayarlamak için ag1, aşağıdaki komutu kullanın:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Aşağıdaki komutu çalıştırarak geçerli RestartThreshold ayarınızı doğrulayabilirsiniz:

Get-ClusterResource -Name "ag1" | Format-List *

Eşzamansız sayfa isteği yönlendirme iyileştirmesi

Bir kullanılabilirlik grubu yük devredildiğinde, her çoğaltmanın senkronize edilecek ortak bir kurtarma noktası bulması zorunludur. Kurtarma noktası, değişiklikleri göndermeye devam edebilmesi için kullanılabilirlik grubunu kararlı tutar. Yinelemeyi geri alma , bu eşitleme işleminin bir parçasıdır. İkincil çoğaltmanın ortak kurtarma noktasına ulaşmak için işlemleri geri alması gerektiğinde yinelemeyi geri alma işlemi gerçekleşir. Yinelemeyi geri alma işlemi en yaygın olarak ile FAILOVER_ALLOW_DATA_LOSSzaman uyumsuz bir çoğaltmaya olağanüstü durum kurtarma (DR) yük devretmesi sırasında görülür.

Bazı durumlarda, dr yük devretmesi ile ikincil çoğaltma birincile geçerken, yeni birincilden (yeni ikincil) ağ gecikme süresine sahiptir ve bu da yeni ikincilde yinelemeyi geri alma işlemini yavaşlatır.

Sql Server 2025 (17.x), bu senaryo için yineleme geri alma işlemini geliştirmek amacıyla eşitleme mekanizmasına yönelik bir güncelleştirme getirir; böylece kullanılabilirlik grubu artık sayfa isteklerini zaman uyumsuz ve toplu olarak gerçekleştirir.

Aşağıdakileri göz önünde bulundurun:

  • Eşitleme mekanizmasının geliştirilmesi varsayılan olarak etkindir. İyileştirmeyi devre dışı bırakmak ve varsayılan davranışa geri dönmek için, şu anda ikincil olan veya gelecekte ikincil olabilecek bir kullanılabilirlik grubundaki tüm çoğaltmalarda izleme bayrağı 12348'i etkinleştirin.
  • AG çoğaltmalarında ağ gecikmesi yoksa, bu geliştirme yinelemeyi geri almayı iyileştirmeyebilir.

Veritabanları bir hatadan sonra durumu çözümlemeye geçer

Nadir durumlarda, bir kullanılabilirlik grubunun bir veya daha fazla veritabanı geçici bir WSFC çekirdek kaybı nedeniyle kısa bir süre çevrimdışı kaldıktan sonra (örneğin, geçici ağ bağlantısının kesilmesi veya küme düğümlerinin çoğunluğunun yeniden başlatılması) Eşitlenmiyor durumunda kalabilir. SQL Server 2025'te (17.x) kullanıma sunulan kullanılabilirlik grubu kurtarma mantığının güncelleştirmesi, bu tür küme çekirdeği kaybına iç toleransı artırır ve kullanılabilirlik grubu yeniden çevrimiçi olduktan sonra kullanılabilirlik grubu veritabanlarının Eşitlenmiyor durumunda takılmasını önler.

Terimler ve Tanımlar

Otomatik devre değişikliği
Birincil çoğaltma kaybında otomatik olarak gerçekleşen bir yük devretme. Otomatik yük devretme, yalnızca geçerli birincil ve bir ikincil çoğaltmanın her ikisi de yük devretme modunun OTOMATİK olarak ayarlanmış olduğu ve ikincil çoğaltmanın şu anda eşitlenmiş olduğu durumda desteklenir. Birincil ve ikincil replikanın yük devretme modu MANUEL ise, otomatik yük devretme gerçekleşemez.

Planlı manuel yük devretme (veri kaybı olmaksızın)
Planlı el ile yük devretme veya el ile yük devretme, genellikle yönetim amacıyla veritabanı yöneticisi tarafından başlatılan bir yük devretmedir. Planlı el ile yük devretme yalnızca birincil ve ikincil çoğaltmalar eşzamanlı işleme modu için yapılandırılmışsa ve her ikisi de şu anda eşitlenmişse (EŞİTLENMİŞ durumunda) desteklenir. Hedef ikincil çoğaltma eşitlendiğinde, birincil çoğaltma başarısızlığa uğramış olsa bile, ikincil veritabanları yük devretme için hazır olduğu için manuel yük devretme (veri kaybı olmadan) mümkündür. Veritabanı yöneticisi el ile yük devretme başlatır.

Zorunlu geçiş (olası veri kaybıyla)
Hiçbir ikincil çoğaltma, birincil çoğaltma ile EŞİTLENMEDİĞİNDE veya birincil çoğaltma çalışmıyorsa ve ikincil çoğaltma yük devretmeye hazır değilse, veritabanı yöneticisi tarafından başlatılabilecek bir yük devretme. Zorlamalı yük devretme, olası veri kaybı risklerine yol açabilir ve yalnızca olağanüstü durum kurtarma için kesinlikle tavsiye edilir. Zorlamalı yük devretme işlemi, yalnızca el ile başlatılabileceği için zorlamalı el ile yük devretme işlemi olarak da bilinir. Bu, zaman uyumsuz işlem kullanılabilirlik modunda desteklenen tek yük devretme şeklidir.

Otomatik yük devretme ayarı

Belirli bir kullanılabilirlik grubu içinde, varsa otomatik yük devretme ile zaman uyumlu işleme modu için yapılandırılmış bir çift kullanılabilirlik çoğaltması (geçerli birincil çoğaltma dahil). Otomatik yük devretme ayarlaması yalnızca ikincil çoğaltma şu anda birincil çoğaltmayla senkronize ise geçerlilik kazanır.

Zaman uyumlu işleme yük devretme kümesi

Belirli bir kullanılabilirlik grubu içinde, eşzamanlı taahhüt modu için yapılandırılmış iki veya üç kullanılabilirlik çoğaltmasından oluşan bir küme (mevcut birincil çoğaltma dahil) varsa. Eşzamanlı taahhüt yük devretme kümesi, yalnızca ikincil çoğaltmalar el ile yük devretme modu için yapılandırıldıysa ve birincil çoğaltmayla şu anda en az bir ikincil çoğaltma eşzamanlı hale getirilmişse etkin olur.

Yük devretme kümesinin tamamı

Belirli bir kullanılabilirlik grubu içinde, kullanılabilirlik modundan ve yük devretme modundan bağımsız olarak işletim durumu şu anda çevrimiçi olan tüm kullanılabilirlik çoğaltmalarının kümelenmesi. Şu anda birincil çoğaltmayla eşzamanlanmış ikincil çoğaltma olmadığında, yük devretme kümesinin tamamı önem kazanır.

Yük Devretmeye Genel Bakış

Aşağıdaki tabloda, farklı kullanılabilirlik ve yük devretme modları altında hangi yük devretme biçimlerinin desteklendiği özetlenmektedir. Her eşleştirme için etkin kullanılabilirlik durumu ve yük devretme durumu, birincil çoğaltmanın modlarının ve bir veya daha fazla ikincil çoğaltmanın modlarının kesişimi ile belirlenir.

Yedekleme formu Zaman uyumsuz kaydetme modu Eşzamanlı taahhüt moduyla el ile yük devretme modu Eşzamanlı işlem modu ile otomatik yük devretme modu
Otomatik devre değişikliği Hayı Hayı Evet
Planlı manuel yük devretme Hayı Evet Evet
Zorlamalı yük devretme Evet Evet Evet1

1 Eşitlenmiş ikincil bir çoğaltmada zorunlu yük devretme komutu verirseniz, ikincil çoğaltma elle yük devretme işlemiyle aynı şekilde davranır.

Veritabanının yük devretme sırasında kullanılamama süresi, yük devretme türüne ve nedenine bağlıdır.

Önemli

Kapsanan veritabanları dışında yük devretme sonrasında istemci bağlantılarını desteklemek için, eski birincil veritabanlarından herhangi birinde tanımlanan oturum açma bilgileri ve işler yeni birincil veritabanında el ile yeniden oluşturulmalıdır. Daha fazla bilgi için bkz. Kullanılabilirlik Grubu Veritabanları (SQL Server) için Oturum Açma ve İş Yönetimi.

Yük Devretme Kümeleri

Belirli bir kullanılabilirlik grubu için mümkün olan yük devretme biçimleri, yük devretme kümeleri açısından anlaşılabilir. Yük devretme kümesi, aşağıdaki gibi belirli bir yük devretme biçimini destekleyen birincil çoğaltma ve ikincil çoğaltmalardan oluşur:

  • Otomatik yük devretme kümesi (isteğe bağlı): Belirli bir kullanılabilirlik grubu içinde, varsa otomatik yük devretme ile zaman uyumlu işleme modu için yapılandırılmış bir çift kullanılabilirlik çoğaltması (geçerli birincil çoğaltma dahil). Otomatik yük devretme ayarlaması yalnızca ikincil çoğaltma şu anda birincil çoğaltmayla senkronize ise geçerlilik kazanır.

  • Zaman uyumlu işleme yük devretme kümesi (isteğe bağlı): Belirli bir kullanılabilirlik grubunda, varsa zaman uyumlu işleme modu için yapılandırılmış iki veya üç kullanılabilirlik çoğaltması (geçerli birincil çoğaltma dahil) kümesi. Eşzamanlı taahhüt yük devretme kümesi, yalnızca ikincil çoğaltmalar el ile yük devretme modu için yapılandırıldıysa ve birincil çoğaltmayla şu anda en az bir ikincil çoğaltma eşzamanlı hale getirilmişse etkin olur.

  • Yük devretme kümesinin tamamı: Belirli bir kullanılabilirlik grubu içinde, kullanılabilirlik modundan ve yük devretme modundan bağımsız olarak hâlihazırda çevrimiçi olan tüm kullanılabilirlik kopyalarının kümesi. Şu anda birincil çoğaltmayla eşzamanlanmış ikincil çoğaltma olmadığında, yük devretme kümesinin tamamı önem kazanır.

Bir kullanılabilirlik çoğaltmasını otomatik yük devretme ile zaman uyumlu işleme olarak yapılandırdığınızda, kullanılabilirlik çoğaltması otomatik yük devretme kümesinin bir parçası olur. Ancak kümenin etkili olup olmaması, mevcut birincil duruma bağlıdır. Belirli bir zamanda gerçekten mümkün olan yük devretme biçimleri, şu anda geçerli olan yük devretme kümelerine bağlıdır.

Örneğin, dört replika içeren bir kusursuzluk grubunu aşağıdaki gibi düşünün:

Replika Kullanılabilirlik Modu ve Yük Devretme Modu Ayarları
A Otomatik yük devretme ile eş zamanlı taahhüt
B Otomatik yük devretme ile eş zamanlı taahhüt
C Yalnızca planlı el ile yük devretme ile eşzamanlı işlem yapma
D Zaman uyumsuz taahhüt (sadece zorunlu yük devretme ile)

Her ikincil çoğaltmanın yük devretme davranışı, hangi kullanılabilirlik çoğaltmasının şu anda birincil çoğaltma olduğuna bağlıdır. Temel olarak, belirli bir ikincil çoğaltma için, yük devretme davranışı mevcut birincil çoğaltmaya göre en kötü senaryodur. Aşağıdaki şekilde, ikincil çoğaltmaların yük devretme davranışının geçerli birincil çoğaltmaya bağlı olarak nasıl değiştiği ve zaman uyumsuz işleme modu (yalnızca zorlamalı yük devretme ile) veya zaman uyumlu işleme modu (otomatik yük devretme ile veya olmadan) için yapılandırılıp yapılandırılmadığı gösterilmektedir.

Birincil çoğaltma yapılandırması yük devretmeyi nasıl etkiler?

Otomatik Sisteme Geçiş

Otomatik aktarma, birincil çoğaltma kullanılamaz duruma geldikten sonra uygun bir ikincil çoğaltmanın otomatik olarak birincil role geçmesine neden olur. Otomatik yük devretme, birincil çoğaltmayı barındıran WSFC düğümü, ikincil çoğaltmayı barındıran düğüme yakın olduğunda en uygun yöntemdir. Bunun nedeni, veri eşitlemenin bilgisayarlar arasındaki düşük ileti gecikme süresiyle en iyi şekilde çalışması ve istemci bağlantılarının yerel kalabilmesidir.

Bu bölümde:

Otomatik Yük Devretme için Gerekli Koşullar

Otomatik yük devretme yalnızca aşağıdaki koşullar altında gerçekleşir:

  • Otomatik yük devretme seti var. Bu küme, hem zaman uyumlu işleme modu için yapılandırılmış hem de otomatik yük devretme olarak ayarlanmış bir birincil çoğaltma ve ( otomatik yük devretme hedefi olan) ikincil çoğaltmadan oluşur. Birincil kopya MANUAL yük devretme olarak ayarlanırsa, ikincil kopya OTOMATİK yük devretme olarak ayarlansa bile otomatik yük devretme gerçekleşemez.

    Daha fazla bilgi için bkz . Kullanılabilirlik Modları (AlwaysOn Kullanılabilirlik Grupları).

  • Otomatik yük devretme hedefinin iyi durumda bir eşitleme durumu vardır (bu, yük devretme hedefi üzerindeki her ikincil veritabanının ilgili birincil veritabanıyla eşitlendiğini gösterir).

    Tavsiye

    Always On Kullanılabilirlik Grupları, otomatik yük devretme kümeleri içerisindeki çoğaltmaların durumunu etkin bir şekilde izler. Çoğaltmalardan biri başarısız olursa, kullanılabilirlik grubunun sistem durumu KRİtİk olarak ayarlanır. İkincil çoğaltma başarısız olursa, otomatik yük devretme hedefi mevcut olmadığından otomatik yük devretme gerçekleştirmek mümkün değildir. Birincil repika başarısız olursa, kullanılabilirlik grubu ikincil repikaya otomatik devredilir. Önceki birincil çoğaltma çevrimiçi olana kadar otomatik yük devretme hedefi bulunmaz. Her iki durumda da, olası bir ardışık arıza durumunda kullanılabilirliği sağlamak için, otomatik yük devretme hedefi olarak farklı bir ikincil replika yapılandırmanızı öneririz.

    Daha fazla bilgi için bkz Always On İlkelerini Kullanarak Kullanılabilirlik Grubunun (SQL Server) Sistem Durumunu Görüntüleme ve Kullanılabilirlik Eşinin (SQL Server) Yük Devretme Modunu Değiştirme.

  • Windows Server Yük Devretme Kümelemesi (WSFC) kümesi quorum'a sahiptir. Daha fazla bilgi için bkz. WSFC Çoğunluk Modları ve Oylama Konfigürasyonu (SQL Server).

  • Birincil kopya kullanılamaz hale geldi ve esnek yük devretme ilkeniz tarafından tanımlanan yük devretme koşul düzeyleri karşılandı. Yük devretme koşulu düzeyleri hakkında bilgi için bkz. Kullanılabilirlik Grubunun (SQL Server) Otomatik Yük Devretmesi için Esnek Yük Devretme İlkesi.

Otomatik Yük Devretme Nasıl Çalışır?

Otomatik geçiş aşağıdaki eylem dizisini başlatır:

  1. Geçerli birincil çoğaltmayı barındıran sunucu örneği hala çalışıyorsa, birincil veritabanlarının durumunu KESİlDİ olarak değiştirir ve tüm istemcilerin bağlantısını keser.

  2. Hedef ikincil çoğaltmada kurtarma kuyruklarında bekleyen günlük kayıtları varsa, ikincil çoğaltma, ikincil veritabanlarını iletme işlemini tamamlamak için kalan günlük kayıtlarını uygular.

    Uyarı

    Belirli bir veritabanına kaydı uygulamak için gereken süre, sistemin hızına, son iş yüküne ve kurtarma kuyruğundaki kayıt miktarına bağlıdır.

  3. Eski ikincil çoğaltma birincil role geçiş gerçekleştirir. Onun veritabanları birincil veritabanları haline gelir. Yeni birincil replik, kaydedilmemiş işlemleri (kurtarmanın geri alma aşaması) olabildiğince hızlı bir şekilde geriye alır. Kilitler, bu kaydedilmemiş işlemleri yalıtarak istemciler veritabanını kullanırken geri alma işleminin arka planda gerçekleşmesini sağlar. Bu işlem, kaydedilmiş işlemleri geri almaz.

    Belirli bir ikincil veritabanı bağlanana kadar kısa bir süre NOT_SYNCHRONIZED olarak işaretlenir. Geri alma işlemi başlamadan önce, ikincil veritabanları yeni birincil veritabanlarına bağlanabilir ve hızla SENKRONİZE duruma geçebilir. En iyi durum, yük devretmeden sonra ikincil rolde kalan üçüncü bir senkron-commit replikası içindir.

  4. Daha sonra, eski birincil replikayı barındıran sunucu örneği yeniden başlatıldığında, artık birincil rolün başka bir kullanılabilirlik replikasına ait olduğunu algılar. Eski birincil replikasyon ikincil role geçiş yapar ve veritabanları ikincil veritabanlarına dönüşür. Yeni ikincil çoğaltma, geçerli birincil çoğaltmaya bağlanır ve veritabanını geçerli birincil veritabanlarının durumuna en kısa sürede günceller. Yeni ikincil yedek veritabanlarını tekrar senkronize ettiğinde, ters yönde yeniden yük devretme mümkündür.

Otomatik Yük Devretmeyi Yapılandırmak için

Kullanılabilirlik çoğaltması herhangi bir noktada otomatik yük devretmeyi destekleyecek şekilde yapılandırılabilir.

Otomatik yük devretmeyi yapılandırmak için

  1. İkincil çoğaltmanın eşzamanlı-taahhüt kullanılabilirlik modunu kullanacak şekilde yapılandırıldığından emin olun. Daha fazla bilgi için bkz. Bir Kullanılabilirlik Replikasının Kullanılabilirlik Modunu Değiştirme (SQL Server).

  2. Yük devretme modunu otomatik moda ayarlayın. Daha fazla bilgi için bkz. Kullanılabilirlik Çoğaltmasının (SQL Server) Yük Devretme Modunu Değiştirme.

  3. İsteğe bağlı olarak, otomatik yük devretmenin oluşmasına neden olabilecek hata türlerini belirtmek için kullanılabilirlik grubunun esnek yük devretme ilkesini değiştirin. Daha fazla bilgi için bkz. Otomatik Yük Devretme Koşullarını Denetlemek için Esnek Yük Devretme İlkesini Yapılandırma (Her Zaman Açık Kullanılabilirlik Grupları) ve Yük Devretme Kümesi Örnekleri için Yük Devretme İlkesi.

Planlı Manuel Yük Devretme (Veri Kaybı Olmadan)

Manuel yük devretme, veritabanı yöneticisinin hedef ikincil çoğaltmayı barındıran sunucu örneğinde manuel yük devretme komutu vermesinin ardından senkronize ikincil çoğaltmanın birincil role geçmesine neden olur. El ile yük devretmeyi desteklemek için, ikincil çoğaltma ve geçerli birincil çoğaltmanın her ikisi de varsa zaman uyumlu işleme modu için yapılandırılmalıdır. Her ikincil veritabanı, kullanılabilirlik kopyası üzerinde kullanılabilirlik grubuna katılmalı ve ilgili birincil veritabanıyla senkronize edilmelidir (yani, ikincil kopya senkronize edilmelidir). Bu, eski bir birincil veritabanında işlenen her işlemin yeni birincil veritabanında da işlendiğini garanti eder. Bu nedenle, yeni birincil veritabanları eski birincil veritabanlarıyla aynıdır.

Aşağıdaki şekilde planlı yük devretme aşamaları gösterilmektedir:

  1. Yük devretmeden önce, birincil çoğaltma üzerinde Node01sunucu örneği tarafından barındırılır.

  2. Veritabanı yöneticisi planlı bir yük devretme başlatır. Yük devretme hedefi, Node02 üzerindeki sunucu örneği tarafından barındırılan çalışabilirlik çoğaltmasıdır.

  3. Yük devretme hedefi (Node02 üzerinde), yeni birincil kopya olur. Bu planlı bir yük devretme olduğundan, önceki birincil replik, yük devretme sırasında ikincil role geçer ve veritabanlarını hemen ikincil veritabanları olarak çevrimiçi hale getirir.

Planlı el ile yük devretme çizimi

Bu bölümde:

El ile Yük Devretme için Gereken Koşullar

El ile yük devretmeyi desteklemek için geçerli birincil çoğaltmanın zaman uyumlu işleme moduna ayarlanması ve ikincil çoğaltmanın şu şekilde olması gerekir:

  • Eşzamanlı onay modu için yapılandırıldı.

  • Şu anda birincil çoğaltmayla eşitlenmiş durumda.

Bir kullanılabilirlik grubuna manuel olarak yük devretmek için, yeni birincil çoğaltma olacak ikincil çoğaltmaya bağlı olmanız gerekmektedir.

Planlı Manuel Yük Devretme İşlemi Nasıl Çalışır?

Hedef ikincil çoğaltmada başlatılması gereken planlı manuel yük devretme, aşağıdaki eylemler dizisini başlatır:

  1. Özgün birincil veritabanlarında yeni kullanıcı işlemlerinin gerçekleşmediğinden emin olmak için WSFC kümesi, birincil çoğaltmaya çevrimdışı olmak için bir istek gönderir.

  2. Herhangi bir ikincil veritabanının kurtarma kuyruğunda bekleyen bir günlük varsa, ikincil çoğaltma, o ikincil veritabanının ileriye dönük işlenmesini tamamlar. Gereken süre, sistemin hızına, son iş yüküne ve kurtarma kuyruğunda bekleyen günlük miktarına bağlıdır. Kurtarma kuyruğunun geçerli boyutunu öğrenmek için Kurtarma Kuyruğu performans sayacını kullanın. Daha fazla bilgi için bkz. SQL Server, Veritabanı Çoğaltması.

    Uyarı

    Yük devretme süresi, kurtarma kuyruğunun boyutu sınırlanarak düzenlenebilir. Ancak bu, ikincil çoğaltmanın yetişebilmesi için birincil çoğaltmanın yavaşlamasına neden olabilir.

  3. İkincil çoğaltma yeni birincil çoğaltmaya, eski birincil çoğaltma ise yeni ikincil çoğaltmaya dönüşür.

  4. Yeni birincil replika, tamamlanmamış işlemleri geri alır ve veritabanlarını birincil veritabanları olarak çevrimiçi duruma getirir. Tüm ikincil veritabanları, yeni birincil veritabanlarına bağlanana ve yeniden eşitlenene kadar kısaca EŞITLENMİYOR olarak işaretlenir. Bu işlem, kaydedilmiş işlemleri geri almaz.

  5. Eski birincil çoğaltma yeniden çevrimiçi olduğunda, ikincil rolü alır ve eski birincil veritabanı ikincil veritabanı olur. Yeni ikincil replikalar, yeni ikincil veritabanlarını ilgili birincil veritabanlarıyla hızla yeniden senkronize eder.

    Uyarı

    Yeni ikincil çoğaltma, veritabanlarını yeniden eşitlediğinde yük devretme yine mümkündür, ancak bu kez ters yönde gerçekleşir.

Yük devretmeden sonra istemcilerin mevcut birincil veritabanına yeniden bağlanması gerekir. Daha fazla bilgi için Kullanılabilirlik Grubu Dinleyicileri, İstemci Bağlantısı ve Uygulama Yük Devretme (SQL Server) bölümüne bakın.

Yükseltmeler Sırasında Kullanılabilirliği Koruma

Kullanılabilirlik gruplarınızın veritabanı yöneticisi, donanım veya yazılımı yükselttiğinizde veritabanı kullanılabilirliğini korumak için el ile yük devretmeleri kullanabilir. Yazılım yükseltmeleri için bir kullanılabilirlik grubundan yararlanmak amacıyla, hedef ikincil çoğaltmayı barındıran sunucu örneği ve/veya bilgisayar düğümü, ilgili yükseltmeleri önceden almış olmalıdır. Daha fazla bilgi için bkz: Always On Kullanılabilirlik Grubu Çoğaltma Örneklerini Yükseltme.

Zorlamalı Kesinti Sonrası Geçiş (Olası Veri Kaybıyla)

Kullanılabilirlik grubunun zorla yük devretmesi (veri kaybına yol açabilir), ikincil çoğaltmayı sıcak standby sunucu olarak kullanmanıza olanak tanıyan bir olağanüstü durum kurtarma yöntemidir. Yük devretmeyi zorlamak olası veri kaybı riskleri taşıdığı için dikkatli ve sınırlı bir şekilde kullanılmalıdır. Yalnızca kullanılabilirlik veritabanlarınıza hizmeti hemen geri yüklemeniz gerekiyorsa ve veri kaybetme riskini göze alıyorsanız failover'u zorlamanızı öneririz. Yük devretmeyi zorlamaya yönelik önkoşullar ve öneriler hakkında daha fazla bilgi edinmek ve yıkıcı bir hatadan kurtarmak için zorlamalı yük devretme kullanan örnek bir senaryo için bkz. Kullanılabilirlik Grubunun (SQL Server) El ile Zorlamalı Yük Devretmesini Gerçekleştirme.

Uyarı

Yük devretmeyi zorlamak için WSFC kümesinin çoğunluğa sahip olması gerekir. Çoğunluğu yapılandırma ve çoğunluğu zorlama hakkında bilgi için bkz. Windows Server Yük Devretme Kümelemesi (WSFC) ile SQL Server.

Bu bölümde:

Zorlamalı Yük Devretme Nasıl Çalışır?

Yük devretmeyi zorlamak, ana rolün İKİNCİL veya ÇÖZÜMLEME durumunda olan bir hedef kopyaya geçişini tetikler. Yük devretme hedefi yeni birincil replika olur ve veritabanlarının kopyalarını istemcilere hemen sunmaya başlar. Önceki birincil replika kullanılabilir olduğunda, ikincil rolüne geçer ve veritabanları ikincil veritabanlarına dönüşür.

Tüm ikincil veritabanları (önceden birincil olan veritabanları dahil, kullanılabilir hale geldiğinde) ASKIYA ALINMIŞTIR. Askıya alınan ikincil veritabanının önceki veri eşitleme durumuna bağlı olarak, bu birincil veritabanı için eksik kaydedilmiş verileri kurtarmak için uygun olabilir. Salt okunur erişim için yapılandırılmış ikincil bir çoğaltmada, eksik verileri manuel olarak tespit etmek için ikincil veritabanlarını sorgulayabilirsiniz. Ardından, gerekli değişiklikleri yapmak için yeni birincil veritabanlarında Transact-SQL deyimleri yayımlayabilirsiniz.

Yük Devretmeye Zorlama Riskleri

Yük devretmeyi zorlamanın veri kaybına neden olabileceğini anlamak önemlidir. Hedef çoğaltma birincil çoğaltmayla iletişim kuramadığından ve bu nedenle veritabanlarının eşitlendiğini garanti etmediğinden veri kaybı mümkündür. Yük devretmeyi zorlamak yeni bir kurtarma dalı başlatır. Özgün birincil veritabanları ve ikincil veritabanları farklı kurtarma çatallarında olduğundan, her biri artık diğer veritabanının içermediği verileri içerir: her özgün birincil veritabanı, gönderme kuyruğundan önceki ikincil veritabanına (gönderilmemiş günlük) henüz gönderilmemiş değişiklikleri içerir; eski ikincil veritabanları, yük devretme zorlandıktan sonra gerçekleşen değişiklikleri içerir.

Birincil çoğaltma başarısız olduğunda ve bu yüzden yük devretme zorunlu hale gelirse, olası veri kaybı, hatadan önce işlem günlüklerinin ikincil çoğaltmaya gönderilip gönderilmediğine bağlıdır. Asenkron işlem modunda, birikmiş gönderilmemiş günlük her zaman mümkündür. Eşzamanlı taahhüt modunda, bu yalnızca ikincil veritabanları eşitlenene kadar mümkündür.

Aşağıdaki tabloda, failover gerçekleştirdiğiniz replika üzerindeki belirli bir veritabanı için veri kaybı olasılığı özetlenmektedir.

İkincil Replikanın kullanılabilirlik modu Veritabanı eşitlenmiş mi? Veri kaybı mümkün mü?
Zaman uyumlu işleme Evet Hayı
Zaman uyumlu işleme Hayı Evet
Asenkron taahhüt Hayı Evet

İkincil veritabanları yalnızca iki geri yükleme dalını izler, bu nedenle birden fazla zorlamalı yük devretme gerçekleştirirseniz, önceki zorlamalı yük devretme ile veri eşitlemesini başlatan herhangi bir ikincil veritabanı devam edemeyebilir. Bu durumda, sürdürülemez tüm ikincil veritabanlarının kullanılabilirlik grubundan kaldırılması, zaman içinde doğru noktaya geri yüklenmesi ve kullanılabilirlik grubuna yeniden katılması gerekir. Bu senaryoda durum 103 olan 1408 hatası gözlemlenebilir (Hata: 1408, Önem Derecesi: 16, Durum: 103). Geri yükleme işlemi birden fazla kurtarma dalı arasında çalışmaz, bu nedenle, birden fazla zorunlu yük devretme gerçekleştirdikten sonra bir günlük yedekleme yaptığınızdan emin olun.

Neden Çoğunluk Zorla Sağlandıktan Sonra Zorunlu Yük Devretme Gerekiyor?

WSFC kümesinde çoğunluk zorlandıktan sonra (zorunlu çoğunluk), her kullanılabilirlik grubunda (olası veri kaybıyla) zorunlu bir yük devretme işlemi gerçekleştirmeniz gerekir. WSFC küme değerlerinin gerçek durumu kaybolmuş olabileceğinden zorlamalı yük devretme gereklidir. Zorlanmış çekirdeğe ihtiyaç duyulduktan sonra, yeniden yapılandırılmış WSFC kümesinde eşitlenmemiş bir ikincil çoğaltmanın eşitlenmiş gibi görünebilmesi olasılığından dolayı normal yük devretmelerin önlenmesi gerekir.

Örneğin, üç düğümde kullanılabilirlik grubunu barındıran bir WSFC kümesi düşünün: Düğüm A birincil çoğaltmayı, Düğüm B ve Düğüm C ise ikincil çoğaltmayı barındırıyor. Yerel ikincil kopya EŞİTLENMİŞken, C düğümünün WSFC kümesiyle bağlantısı kesilir. Ancak Düğüm A ve Düğüm B sağlam bir çoğunluk oluşturur ve kullanılabilirlik grubu çevrimiçi kalmaya devam eder. Düğüm A'da, birincil kopya güncellemeleri kabul etmeye devam ederken, Düğüm B'deki ikincil kopya, birincil kopyayla eşitlenmeye devam eder. Node C'deki ikincil çoğaltma senkronize olmamış hale gelir ve birincil çoğaltmanın gerisinde giderek daha fazla kalır. Ancak, Node C'nin bağlantısı kesildiğinden, çoğaltma yanlış bir şekilde SENKRONİZE durumda kalır.

Çoğunluk kaybedilip Node A'ya zorlanırsa, WSFC kümesindeki kullanılabilirlik grubunun eşitleme durumu, Node C'deki ikincil çoğaltmada EŞİTLENMEMİŞ olarak gösterildiğinde doğru olmalıdır. Ancak Düğüm C'de oy çoğunluğu zorlanırsa, kullanılabilirlik grubunun eşitlenmesi yanlış olur. Kümedeki eşitleme durumu, Node C'nin bağlantısının kesildiği zamanlardaki haline geri döndürülecek ve Node C'deki ikincil kopya yanlış olarak EŞİTLENDİ şeklinde gösterilecektir. Planlı el ile yük devretme işlemleri verilerin güvenliğini garanti ettiğinden, çoğunluk zorlandıktan sonra bir kullanılabilirlik grubunu tekrar çevrimiçi duruma getirmek için izin verilmez.

Olası Veri Kaybını İzleme

WSFC kümesinin sağlıklı bir yeter sayısı olduğunda, veritabanlarında mevcut veri kaybı potansiyelini tahmin edebilirsiniz. Belirli bir ikincil çoğaltma için geçerli veri kaybı olasılığı, yerel ikincil veritabanlarının ilgili birincil veritabanlarının ne kadar gerisinde kaldığına bağlıdır. Gecikme süresi zaman içinde değiştiğinden, eşitlenmemiş ikincil veritabanlarınız için olası veri kaybını düzenli aralıklarla izlemenizi öneririz. İzleme gecikmesi, her birincil veritabanı ve ikincil veritabanları için Son İşleme LSN'sini ve Son İşleme Zamanı'nı aşağıdaki gibi karşılaştırmayı içerir:

  1. Ana replikaya bağlanın.

  2. sys.dm_hadr_database_replica_states dinamik yönetim görünümünün last_commit_lsn(son işlenen işlemin LSN'sini) ve last_commit_time (son işlemenin zamanı) sütunlarını sorgular.

  3. Her birincil veritabanı ve ikincil veritabanları için döndürülen değerleri karşılaştırın. Son İşleme LSN'leri arasındaki fark gecikme miktarını gösterir.

  4. Bir veritabanındaki veya veritabanı kümesindeki gecikme miktarı belirli bir süre için istediğiniz maksimum gecikme süresini aştığında uyarı tetikleyebilirsiniz. Örneğin, sorgu her birincil veritabanında dakikada bir yürütülen bir iş tarafından çalıştırılabilir. Birincil veritabanının last_commit_time ile ikincil veritabanları arasındaki fark, işin son yürütülmesinden bu yana kurtarma noktası hedefini (örneğin, 5 dakika) aştıysa, iş bir uyarı oluşturabilir.

Önemli

WSFC kümesinde çoğunluk olmadığında veya çoğunluk zorlandığında, last_commit_lsn ve last_commit_time NULL olur. Verilerin çoğunluk zorlandıktan sonra kaybolmasını nasıl önleyebileceğiniz hakkında bilgi için, Kullanılabilirlik Grubunda (SQL Server) Zorla El ile Yük Devretme Gerçekleştirme başlığı altındaki "Çoğunluk Zorlandıktan Sonra Veri Kaybını Önlemenin Olası Yolları" konusuna bakın.

Olası Veri Kaybını Yönetme

Yük devretme işlemi zorlandıktan sonra tüm ikincil veritabanları askıya alınır. Bu, eski birincil veritabanlarını içerir; eski birincil kopya yeniden çevrimiçi olduğunda ve artık ikincil bir kopya olduğunu keşfettiğinde. Her ikincil çoğaltmada durdurulan her veritabanını manuel olarak tek tek devam ettirmeniz gerekir.

Eski birincil çoğaltma kullanılabilir olduğunda, veritabanlarının hasarsız olduğunu varsayarak olası veri kaybını yönetmeye çalışabilirsiniz. Olası veri kaybını yönetmek için kullanılabilen yaklaşım, özgün birincil çoğaltmanın yeni birincil çoğaltmaya bağlanıp bağlanmadığına bağlıdır. Özgün birincil çoğaltmanın yeni birincil örneğe erişebildiğini varsayarsak, yeniden bağlanma otomatik ve saydam bir şekilde gerçekleşir.

Özgün ana kopya yeniden bağlandı

Genellikle, bir hatadan sonra, ilk birincil kopya yeniden başlatıldığında hızla partnerine yeniden bağlanır. Yeniden bağlanıldığında, orijinal birincil çoğaltma ikincil çoğaltma olur. Veritabanları ikincil veritabanları haline gelir ve SUSPENDED durumuna girer. Devam etmediğiniz sürece yeni ikincil veritabanları geri alınmayacaktır.

Ancak, askıya alınan veritabanlarına erişilemez, bu nedenle belirli bir veritabanını sürdürürseniz hangi verilerin kaybedileceğini değerlendirmek için bunları inceleyemezsiniz. Bu nedenle, ikincil veritabanını sürdürme veya kaldırma kararı, aşağıdaki gibi herhangi bir veri kaybını kabul edip etmeyeceğinize bağlıdır:

  • Veri kaybı kabul edilemezse, veritabanlarını kurtarmak için kullanılabilirlik grubundan kaldırmanız gerekir.

    Veritabanı yöneticisi artık eski birincil veritabanlarını kurtarabilir ve kaybolacak verileri kurtarmayı dener. Ancak, eski bir birincil veritabanı çevrimiçi olduğunda, veritabanı geçerli birincil veritabanından farklıdır, bu nedenle veritabanı yöneticisinin veritabanlarının daha fazla ayrışmasını önlemek ve istemci yük devretme sorunlarını önlemek için kaldırılan veritabanını veya geçerli birincil veritabanını istemciler için erişilemez duruma getirmesi gerekir.

  • Veri kaybı iş hedefleriniz için kabul edilebilirse ikincil veritabanlarını sürdürebilirsiniz.

    Yeni bir ikincil veritabanının yeniden başlatılması, veritabanını eşitlemenin ilk adımı olarak geri döndürülmesine neden olur. Hata anında gönderme kuyruğunda bekleyen günlük kayıtları varsa, işlenmeleri durumunda bile ilgili işlemler kaybolur.

Orijinal Çalışan Replika Yeniden Bağlanmadı

Orijinal birincil çoğaltmanın ağ üzerinden yeni birincil çoğaltmaya tekrar bağlanmasını geçici olarak engelleyebilirseniz, orijinal birincil veritabanlarını inceleyerek devam ettirilmesi durumunda hangi verilerin kaybolacağını değerlendirebilirsiniz.

  • Olası veri kaybı kabul edilebilirse

    Özgün birincil çoğaltmanın yeni birincil çoğaltmaya yeniden bağlanmasına izin verin. Yeniden bağlanma, yeni ikincil veritabanlarının askıya alınmasına neden olur. Veritabanında veri eşitlemeyi başlatmak için onu devam ettirmeniz yeterlidir. Yeni ikincil çoğaltma, o veritabanı için özgün kurtarma çatalını bırakır ve eski ikincil çoğaltmaya hiç gönderilmemiş veya alınmamış işlemleri kaybeder.

  • Veri kaybı kabul edilemezse

    Özgün birincil veritabanı, askıya alınan veritabanını sürdürürseniz kaybolacak kritik veriler içeriyorsa, özgün birincil veritabanındaki verileri kullanılabilirlik grubundan kaldırarak koruyabilirsiniz. Bu, veritabanının RESTOREING durumuna girmesine neden olur. Bu noktada, kaldırılan veritabanı günlüğünün kuyruğunu yedeklemeyi denemenizi öneririz. Ardından, özgün birincil veritabanından kurtarmak istediğiniz verileri dışarı aktarıp geçerli birincil veritabanına aktararak geçerli birincil veritabanını (eski ikincil veritabanı) güncelleştirebilirsiniz. Güncelleştirilmiş birincil veritabanının tam veritabanı yedeğini mümkün olan en kısa sürede almanızı öneririz.

    Ardından, yeni ikincil replika sunucu örneğinde, askıya alınan ikincil veritabanını silip, bu yedeklemeyi ve ihtiyaç halinde en az bir sonraki günlük yedeğini NORECOVERY ile RESTORE kullanarak geri yükleyerek yeni bir ikincil veritabanı oluşturabilirsiniz. İlgili ikincil veritabanları devam ettirilene kadar mevcut birincil veritabanlarının ek günlük yedeklemelerini geciktirmenizi öneririz.

Uyarı

İkincil veritabanlarından herhangi biri askıya alındığında, birincil veritabanındaki işlem günlüğü kesilmesi gecikir. Ayrıca, herhangi bir yerel veritabanı askıya alınmış durumda kaldığı sürece, senkron işlem taahhüdüne sahip ikincil replikasının eşitleme durumu SAĞLIKLI'ya geçemez.

İlgili içerik

Yük devretme davranışını yapılandırın

Yük devretme işlemini manuel olarak gerçekleştirme

WSFC Çekirdek Yapılandırmasını Yapılandırma

  • Last updated on