Always On kullanılabilirlik grubunun (SQL Server) el ile zorla yük devretmesini gerçekleştirme

Şunlar için geçerlidir: SQL Server

Bu makalede, SQL Server'da SQL Server Management Studio, Transact-SQL veya PowerShell kullanarak Always On kullanılabilirlik grubunda zorlamalı yük devretmenin (olası veri kaybıyla) nasıl gerçekleştirildiği açıklanmaktadır. Zorlamalı yük devretme, kesinlikle olağanüstü durum kurtarma için tasarlanmış elle yük devretmenin bir biçimidir, ve planlı bir elle yük devretme mümkün olmadığında kullanılır. Eşitlenmemiş bir ikincil çoğaltmaya yük devretmeye zorlarsanız, veri kaybı yaşanabilir. Bu nedenle, yalnızca hizmeti kullanılabilirlik grubuna hemen geri yüklemeniz gerekiyorsa ve veri kaybı riskini göze alıyorsanız yük devretmeyi zorla yapmanızı kesinlikle öneririz.

Zorunlu bir yük devretmeden sonra, kullanılabilirlik grubunun devredildiği hedef yeni birincil replika haline gelir. Kalan ikincil kopyalardaki ikincil veritabanları askıya alınır ve manuel olarak devam ettirilmelidir. Eski birincil çoğaltma kullanılabilir olduğunda, ikincil role geçer ve bu da eski birincil veritabanlarının ikincil veritabanları haline gelmesine ve duruma geçmesine SUSPENDED neden olur. Belirli bir ikincil veritabanına devam etmeden önce, kaybolan verileri kurtarabilirsiniz. Ancak, herhangi bir ikincil veritabanı askıya alındığında, belirli bir birincil veritabanındaki işlem günlüğü kesilmesinin gecikeceğini unutmayın.

Önemli

birincil veritabanıyla veri eşitleme, ikincil veritabanı sürdürülene kadar gerçekleşmez. İkincil veritabanını yeniden başlatma hakkında bilgi için, bu makalenin devamında yer alan İzleme: Zorunlu Yük Devretmeden Sonra Temel Görevler bölümüne bakın.

Aşağıdaki acil durumlarda zorlamalı yük devretme gerçekleştirmek zorunludur:

• WSFC kümesinde çekirdek zorunlu tutulduktan sonra (zorunlu çekirdek), her kullanılabilirlik grubunda (olası veri kaybıyla) yük devretmeye zorlamanız gerekir. WSFC küme değerlerinin gerçek durumu kaybolmuş olabilir, bu yüzden zorunlu yük devretme gerekli olabilir. Ancak, çekirdek zorlamadan önce birincil çoğaltma olan çoğaltmayı barındıran sunucu örneğinde veya çekirdek zorlamadan önce eşitlenmiş olan ikincil bir çoğaltmaya yük devretmeyi zorlayabiliyorsanız, veri kaybını önleyebilirsiniz. Daha fazla bilgi için, bu makalenin devamında yer alan Korum Zorlandıktan Sonra Veri Kaybını Önlemenin Olası Yolları bölümüne bakın.

  Önemli

  Doğal yollarla yeniden çoğunluk sağlanırsa, yüksek kullanılabilirlik replikaları normal kurtarma işlemi yürütür. Quorum yeniden kazanıldıktan sonra birincil çoğaltma hala kullanılamıyorsa, eşitlenmiş bir ikincil çoğaltmaya planlı bir şekilde manuel yük devretme gerçekleştirebilirsiniz.

  Çoğunluğu zorlama hakkında bilgi için bkz. Zorlanmış Çoğunluk (SQL Server) aracılığıyla WSFC Olağanüstü Durum Kurtarma. Çoğunluk zorlandıktan sonra yük devretmeyi zorlamanın neden gerekli olduğu hakkında bilgi için bkz. Yük Devretme ve Yük Devretme Modları (Her Zaman Açık Kullanılabilirlik Grupları).

• WSFC kümesinin sağlıklı bir yedeği olduğu durumda birincil çoğaltma kullanılamaz hale gelirse, rolü SECONDARY veya RESOLVING durumundaki herhangi bir çoğaltmaya zorla yük devredebilirsiniz (olası veri kaybıyla). Mümkünse, birincil çoğaltma kaybolduğunda eşzamanlı taahhüt edilmiş ve senkronize olan bir ikincil çoğaltmaya zorla yük devret.

  İpucu

  WSFC kümesinin iyi durumda bir çakşırı (quorum) olduğunda, eşitlenmiş bir ikincil çoğaltmada zorla yük devretme komutu verirseniz, çoğaltma aslında planlanmış manuel bir yük devretme gerçekleştirir.

Yük devretmeyi zorlamaya yönelik önkoşullar ve öneriler hakkında daha fazla bilgi edinmek ve felaket bir hatadan kurtulmak için zorunlu yük devretme kullanan örnek bir senaryo için, bu makalenin ilerleyen kısımlarında yer alan Örnek senaryo: Felaket bir hatadan kurtulmak için zorunlu yük devretme kullanma.

Sınırlamalar

• Zorlamalı yük devretme gerçekleştirilemeyeceği tek zaman, Windows Server Yük Devretme Kümelemesi (WSFC) kümesinin çoğunluğa sahip olmadığı durumlardır.

• Kullanılabilirlik grubunun zorla yük devretmesi sırasında veri kaybı mümkündür. Ayrıca, zorlamalı yük devretme başlattığınızda birincil çoğaltma çalışıyorsa, istemciler eski birincil veritabanlarına bağlı olmaya devam edebilir. Bu nedenle, yalnızca birincil çoğaltma artık çalışmıyorsa ve kullanılabilirlik grubundaki veritabanlarına erişimi geri yüklemek için veri kaybetme riskiyle karşı karşıyaysanız yük devretmeye zorlamanızı kesinlikle öneririz.

• İkincil bir veritabanı REVERTING veya INITIALIZING durumundayken, yük devretmenin zorlanması, veritabanının birincil veritabanı olarak başlatılamamasına neden olabilir. Eğer veritabanı INITIALIZING durumundaysa, eksik günlük kayıtlarını bir veritabanı yedeğinden uygulamanız veya veritabanını baştan tamamen geri yüklemeniz gerekir. Veritabanı REVERTING durumundaysa, veritabanını yedeklerden tamamen geri yüklemeniz gerekir.

• Yük devretme komutu, yük devretme hedefi komutu kabul ettikçe hemen döndürür. Ancak, kullanılabilirlik grubunun yük devretmesi tamamlandıktan sonra veritabanı kurtarma zaman uyumsuz olarak gerçekleşir.

• Kullanılabilirlik grubundaki veritabanları arasında tutarlılık, yük devretme sırasında korunmayabilir.

  Uyarı

  Veritabanları arası ve dağıtılmış işlemler için destek, SQL Server ve işletim sistemi sürümlerine göre farklılık gösterir. Daha fazla bilgi için bkz. İşlemler - kullanılabilirlik grupları ve veritabanı yansıtma.

Önkoşullar

• WSFC kümesinin çoğunluğu vardır. Kümede çoğunluk yoksa bkz. Zorla Çoğunluk (SQL Server) aracılığıyla WSFC Olağanüstü Durum Kurtarma.

• Rolü SECONDARY veya RESOLVING durumunda olan bir çoğaltmayı barındıran bir sunucu örneğine bağlanabilmeniz gerekir.

Öneriler

• Birincil çoğaltma halen çalışıyor iken yük devretmeyi mecbur bırakmayın.

• Mümkünse, yük devretmeyi yalnızca ikincil veritabanları NOT SYNCHRONIZED, SYNCHRONIZED veya SYNCHRONIZING durumunda olan bir yük devretme hedefine zorlayabilirsiniz. İkincil veritabanı INITIALIZING veya REVERTING durumundayken yük devretmenin etkileri hakkında bilgi için bu makalede daha önceki kısımda yer alan Sınırlamalar bölümüne bakın.

• Genellikle, birincil veritabanına kıyasla belirli bir ikincil veritabanının gecikme süresi, farklı zaman uyumsuz işlem iletilen ikincil çoğaltmalarda benzer olmalıdır. Ancak yük devretmeyi zorlarken veri kaybı önemli bir sorun olabilir. Bu nedenle, farklı ikincil çoğaltmalardaki veritabanlarının kopyalarının göreli gecikme süresini belirlemek için zaman ayırın. Belirli bir ikincil veritabanının hangi kopyasının en az gecikme süresine sahip olduğunu belirlemek için günlük sonu LSN'lerini karşılaştırın. Günlük sonu LSN'nin daha yüksek olması, daha az gecikme süresi anlamına gelir.

  İpucu

  Günlük sonu LSN'lerini karşılaştırmak için, sırayla her çevrimiçi ikincil çoğaltmaya bağlanın ve her yerel ikincil veritabanının değerini sorgulamak amacıyla sys.dm_hadr_database_replica_states'i sorgulayın. Ardından, her veritabanının farklı kopyalarının günlük sonu LSN'lerini karşılaştırın. Farklı veritabanlarının farklı ikincil çoğaltmalarda en yüksek LSN'leri olabilir. Bu durumda, en uygun yük devretme hedefi, farklı veritabanlarındaki verilere verdiğiniz göreli öneme bağlıdır. Diğer bir ifadeyle, bu veritabanlarından hangisinde olası veri kaybını en aza indirmek istersiniz?

• İstemciler özgün birincil birincil ağa bağlanabiliyorsa, zorunlu yük devretme, bölünmüş beyin davranışı riski doğuruyor. Yük devretmeyi zorlamadan önce, istemcilerin özgün birincil çoğaltmaya erişmesini engellemenizi kesinlikle öneririz. Aksi takdirde, yük devretme zorunlu kılındıktan sonra özgün birincil veritabanları ve geçerli birincil veritabanları, diğerinden bağımsız olarak güncellenebilir.

Nitelikli çoğunluk zorlandıktan sonra veri kaybını önlemenin olası yolları

Quorum kaybolduktan sonra belirli hata koşullarında veri kaybını aşağıdaki şekilde önleyebilirsiniz:

• Özgün birincil çoğaltma çevrimiçiyse

  Yeter sayı kaybolursa ve WSFC yeter sayıyı zorlamak, bir kullanılabilirlik grubunun birincil replikasını barındıran küme düğümünü geri yüklüyorsa, bu kullanılabilirlik grubu için veri kaybını önleyebilirsiniz. Ana kopyaya bağlanın ve zorunlu yük devretme (FAILOVER_ALLOW_DATA_LOSS) gerçekleştirin. Bu, birincil çoğaltmayı yeniden çevrim içi hale getirir. Zorlamalı yük devretmeyi orijinal birincil kopyaya gerçekleştirdiğiniz için veri kaybı olmaz.

• Bir eşzamanlı zaman uyumlu işleme ikincil çoğaltması etkinleştiğinde

  Yeter sayı kaybolursa ve WSFC yeter sayısını zorlamak, bir kullanılabilirlik grubu için eşitlenmiş ikincil çoğaltmayı barındıran bir küme düğümünü geri yüklerse, bu kullanılabilirlik grubunda veri kaybını önleyebileceksiniz. Geri yüklenen node quorum kaybolduğu sırada çalışır durumdaysa, belirli bir veritabanında veri kaybı olup olmadığını sütununu sorgulayarak belirleyebilirsiniz. Bunun için sys.dm_hadr_database_replica_cluster_states dinamik yönetim görünümünü kullanabilirsiniz. Örneğin, adlı sql108w2k8r22bir sunucu örneği için aşağıdaki sorguyu çalıştırın:

  SELECT *
  FROM sys.dm_hadr_database_replica_cluster_states
  WHERE replica_id = (
      SELECT replica_id
      FROM sys.availability_replicas
      WHERE replica_server_name = 'sql108w2k8r22'
  );
  

  Dikkat

  Geri yüklenen düğüm yeter sayısı kaybolduğu sırada çalışmıyorsa, is_failover_ready ana kopya çevrimdışı olduğunda kümenin mevcut durumunu yansıtmayabilir. Bu nedenle, is_failover_ready değeri yalnızca hata anında konak düğüm mevcutsa uygundur. Daha fazla bilgi için "Çekirdek Zorlandıktan Sonra Zorunlu Yük Devretme Neden Gereklidir" konusuna Yük Devretme ve Yük Devretme Modları (Always On Kullanılabilirlik Grupları)'nda bakın.

  ise is_failover_ready = 1, veritabanı kümede eşitlenmiş olarak işaretlenir ve yük devretme için hazırdır. Bir ikincil çoğaltmada, her veritabanı üzerinde is_failover_ready = 1 varsa, veri kaybı olmadan zorlamalı yük devretme (FORCE_FAILOVER_ALLOW_DATA_LOSS) gerçekleştirebilirsiniz. Senkronize edilmiş ikincil çoğaltma, tüm veriler sağlam bir şekilde, yeni birincil çoğaltma olarak birincil rolde çevrimiçi olur.

  Eğer is_failover_ready = 0, veritabanı kümede eşitlenmiş olarak işaretlenmez ve planlı bir manuel yük devretme için hazır değildir. Konak ikincil çoğaltmasına yük devretmeye zorlarsanız, bu veritabanındaki veriler kaybolur.

  Uyarı

  İkincil kopyaya yük devretmeye zorladığınızda, veri kaybının miktarı yük devretme hedefinin birincil kopyanın ne kadar gerisinde kaldığına bağlıdır. Ne yazık ki, WSFC kümesinde çoğunluk olmadığında veya çoğunluk zorlandığında, olası veri kaybı miktarını değerlendiremezsiniz. Ancak, WSFC kümesi iyi durumda bir kvorumu yeniden kazandığında, olası veri kaybını izlemeye başlayabileceğinizi unutmayın. Daha fazla bilgi için Devretme ve Devretme Modları (Her Zaman Açık Kullanılabilirlik Grupları) bölümündeki "Olası Veri Kaybını İzleme" bölümüne bakın.

İzinler

ALTER AVAILABILITY GROUP Kullanılabilirlik grubu, izin, CONTROL AVAILABILITY GROUPALTER ANY AVAILABILITY GROUP izin veya CONTROL SERVER izin üzerinde izin gerektirir.

SQL Server Management Studio'yu kullanma

1. Nesne Gezgini'nde, yük devretmesi gereken kullanılabilirlik grubundaki rolü SECONDARY veya RESOLVING durumunda olan bir çoğaltmayı barındıran bir sunucu örneğine bağlanın ve sunucu ağacını genişletin.

2. Always On Yüksek Kullanılabilirlik düğümünü ve Kullanılabilirlik Grupları düğümünü genişletin.

3. Yük devredilecek kullanılabilirlik grubuna sağ tıklayın ve Yük Devretme komutunu seçin.

4. Bu, Hata Durumunda Devretme Kullanılabilirlik Grubu Sihirbazı'nı başlatır. Daha fazla bilgi için bkz. SQL Server Management Studio'da Yük Devretme Kullanılabilirlik Grubu Sihirbazı'nı kullanma.

5. Bir kullanılabilirlik grubunu yük devretmeye zorladıktan sonra, gerekli izleme adımlarını tamamlayın. Daha fazla bilgi için bu makalenin ilerleyen kısımlarında İzleme: Zorunlu Yük Devretmeden Sonra Temel Görevler bölümüne göz atın.

Transact-SQL kullanma

1. Yük devretmesi gereken bir çoğaltmanın SECONDARY veya RESOLVING durumunda olduğu kullanılabilirlik grubuna ev sahipliği yapan bir sunucu örneğine bağlanın.

2. ALTER AVAILABILITY GROUP deyimini aşağıdaki gibi kullanın; burada group_name kullanılabilirlik grubunun adıdır:

   ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS.

   Aşağıdaki örnek, AccountsAG kullanılabilirlik grubunun yerel ikincil çoğaltmaya yük devretmesini zorlar.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Bir kullanılabilirlik grubunu yük devretmeye zorladıktan sonra, gerekli izleme adımlarını tamamlayın. Daha fazla bilgi için, bu makalede daha sonra zorunlu yük devretme sonrasında yapılması gereken temel görevler bölümüne bakın.

PowerShell kullanma

1. Dizini, yük devretmesi gereken kullanılabilirlik grubundaki, rolü SECONDARY veya RESOLVING durumunda olan bir çoğaltmayı barındıran bir sunucu örneğine değiştirin.

2. Switch-SqlAvailabilityGroup cmdlet'ini AllowDataLoss parametresiyle aşağıdaki şekillerden birinde kullanın:

   • -AllowDataLoss

     Varsayılan olarak -AllowDataLoss parametresi, Switch-SqlAvailabilityGroup'in yük devretmeyi zorlamanın kaydedilmemiş işlemlerin kaybına yol açabileceği konusunda sizi uyarmasına ve onay isteği istemesine neden olur. Devam etmek için girin Y; işlemi iptal etmek için girin N.

     Aşağıdaki örnek; MyAg adlı sunucu örneğindeki ikincil replika üzerine, kullanılabilirlik grubunun SecondaryServer\InstanceName zorlamalı yük devretmesini (olası veri kaybıyla) gerçekleştirir. Bu işlemi onaylamanız istenir.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss-Force

     Zorlamalı yük devretmeyi onay olmadan başlatmak için hem -AllowDataLoss hem de -Force parametrelerini belirtin. Bu, komutu bir betikte eklemek ve kullanıcı etkileşimi olmadan çalıştırmak istiyorsanız kullanışlıdır. Ancak, -Force seçeneğini dikkatli kullanın, çünkü zorlamalı yük devretme, kullanılabilirlik grubuna katılan veritabanlarından veri kaybına yol açabilir.

     Aşağıdaki örnek, kullanılabilirlik grubu MyAg'ün olası veri kaybıyla, SecondaryServer\InstanceName adlı sunucu örneğine zorlamalı yük devretmesini gerçekleştirir. -Force seçeneği bu işlemin onayını gizler.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   Uyarı

   Bir cmdlet'in söz dizimini görüntülemek için SQL Server PowerShell ortamında Get-Help cmdlet'ini kullanın. Daha fazla bilgi için bkz. SQL Server PowerShell Yardım Alma.

3. Bir kullanılabilirlik grubunu yük devretmeye zorladıktan sonra, gerekli izleme adımlarını tamamlayın. Daha fazla bilgi için bu makalenin ilerleyen kısımlarında İzleme: Zorunlu Yük Devretmeden Sonra Temel Görevler bölümüne göz atın.

SQL Server PowerShell sağlayıcısını ayarlama ve kullanma

• SQL Server PowerShell Sağlayıcısı

Devamı: Zorunlu yük devretmeden sonra yapılması gereken temel görevler

1. Zorlamalı yük devretmeden sonra, yük devreddiğiniz ikincil çoğaltma yeni birincil çoğaltma olur. Ancak, bu kullanılabilirlik çoğaltmasını istemciler için erişilebilir hale getirmek için WSFC çoğunluğunu yeniden yapılandırmanız veya kullanılabilirlik grubunun kullanılabilirlik modu ayarlarını aşağıdaki şekilde düzenlemeniz gerekebilir.

   • Otomatik yük devretme kümesinin dışında yük devreddiyseniz: WSFC düğümlerinin quorum oylarını yeni kullanılabilirlik grubu yapılandırmanızı yansıtacak şekilde ayarlayın. Hedef ikincil çoğaltmayı barındıran WSFC düğümünde WSFC çekirdek oyu yoksa, WSFC çekirdeğini zorlamanız gerekebilir.

     Otomatik yük devretme kümesi, yalnızca iki kullanılabilirlik çoğaltması (önceki birincil çoğaltma dahil) otomatik yük devretme ile zaman uyumlu işleme modu için yapılandırılmışsa vardır.

     Oy çoğunluğunu ayarlamak için

     • Küme Çoğunluk Düğüm Ağırlığı Ayarlarını Görüntüle
     • Küme Çekirdeği Düğüm Sıklık Ayarlarını Yapılandırma
     • WSFC Kümesini Çoğunluk Olmadan Başlatmaya Zorla

   • Eşzamanlı işlemler yük devretme setinin dışına çıktıysanız: Yeni birincil replikada ve kalan ikincil replikalarda kullanılabilirlik modunu ve yük devretme modunu, istediğiniz eşzamanlı işlemler ve otomatik yük devretme yapılandırmasını yansıtacak şekilde ayarlamanızı öneririz.

     Uyarı

     Zaman uyumlu işleme yük devretme kümesi yalnızca geçerli birincil çoğaltma zaman uyumlu işleme modu için yapılandırılmışsa var olur.

     Kullanılabilirlik modunu ve yük devretme modunu değiştirmek için

     • AlwaysOn kullanılabilirlik grubu içindeki bir çoğaltmanın kullanılabilirlik modunu değiştirme
     • AlwaysOn kullanılabilirlik grubu içindeki bir çoğaltma için yük devretme modunu değiştirme

2. Zorlamalı yük devretme işleminden sonra tüm ikincil veritabanları askıya alınır. Bu, eski birincil çoğaltma yeniden çevrimiçi olduktan ve artık ikincil bir çoğaltma olduğunu keşfettikten sonra eski birincil veritabanlarını içerir. Her ikincil çoğaltmada durdurulan her veritabanını manuel olarak tek tek devam ettirmeniz gerekir.

   İkincil veritabanı devam ettirildiğinde, ilgili birincil veritabanıyla veri eşitlemesi başlatılıyor. İkincil veritabanı, yeni birincil veritabanında hiçbir zaman işlenmeyen günlük kayıtlarını geri alır. Bu nedenle, yük devretme sonrası birincil veritabanlarında olası veri kaybından endişeleniyorsanız, zaman uyumlu işleme ikincil veritabanlarından birinde askıya alınan veritabanlarında bir veritabanı anlık görüntüsü oluşturmayı denemeniz gerekir.

   Önemli

   İkincil veritabanlarından herhangi biri askıya alındığında, birincil veritabanındaki işlem günlüğü kesilmesi gecikir. Ayrıca, zaman uyumlu gerçekleştirilmiş ikincil çoğaltmanın eşitleme sağlığı durumu, herhangi bir yerel veritabanı askıda kaldığı sürece HEALTHY olarak geçiş yapamaz.

   Veritabanı anlık görüntüsü oluşturmak için

   • Veritabanı anlık görüntüsü oluşturma (Transact-SQL)

   Kullanılabilirlik veritabanını sürdürmek için

   • Kullanılabilirlik Veritabanını Sürdürme (SQL Server)

   Dikkat

   Tüm ikincil veritabanlarını devam ettirdikten sonra, gruba yeniden yük devretmeyi denemeden önce, sonraki yük devretme hedefinde yer alan tüm ikincil veritabanlarının SYNCHRONIZING duruma girmesini bekleyin. Henüz SYNCHRONIZING durumu gerçekleşmemiş olan bir veritabanı varsa, bu veritabanının birincil veritabanı olarak çevrimiçi olması engellenir ve veritabanı için veri eşitlemesini yeniden sağlamak için işlem günlüklerinin geri yüklenmesi, tam veritabanı yedeğinin geri yüklenmesi veya önceki birincil çoğaltmaya yük devretme gerekebilir.

3. Başarısız olan bir kullanılabilirlik çoğaltması mevcut çoğaltmaya geri dönmüyorsa veya yeni birincil veritabanında işlem günlüğü kesilmesini geciktirmek için çok geç dönebilir ve bu nedenle günlük dosyalarınızda disk alanınızın tükenmesini önlemek istiyorsanız, başarısız çoğaltmayı kullanılabilirlik grubundan kaldırmayı göz önünde bulundurun.

   İkincil bir çoğaltmayı kaldır

   • Bir İkincil Çoğaltmayı Bir Kullanılabilirlik Grubundan (SQL Server) Kaldırma

4. İlk zorlamalı yük devretmeden sonra bir veya daha fazla ek zorlamalı yük devretme işlemi gerçekleştiriyorsanız, serideki her ek zorlamalı yük devretme işleminden sonra bir günlük yedekleme yapın. Bunun nedeni hakkında bilgi için, "Yük Devretmeyi Zorlama Riskleri" bölümüne Yük Devretme ve Yük Devretme Modları (Her Zaman Açık Kullanılabilirlik Grupları) "Zorlamalı El ile Yük Devretme (Olası Veri Kaybıyla)" bölümünde bakın.

   Günlük yedeklemesi gerçekleştirmek için

   • İşlem günlüğünü yedekleme

Örnek senaryo: Yıkıcı bir hatadan kurtulmak için zorunlu yük devretme kullanımı

Birincil çoğaltma başarısız olursa ve eşitlenmiş ikincil çoğaltma yoksa, kullanılabilirlik grubunun yük devretmeye zorlanması uygun bir yanıt olabilir. Yük devretmeyi zorla gerçekleştirmenin uygunluğu, (1) birincil çoğaltmanın, hizmet düzeyi sözleşmenizin (SLA) toleransından daha uzun süre çevrimdışı kalacağını bekleyip beklemediğinize ve (2) birincil veritabanlarının hızlı bir şekilde kullanılabilir olmasını sağlamak için olası veri kaybı riskini göze almak isteyip istemediğinize bağlıdır. Bir kullanılabilirlik grubunun zorlu yük devretme gerektirdiğine karar verirseniz, gerçek zorlu yük devretme, çok adımlı bir işlemin sadece bir adımıdır.

Yıkıcı bir hatadan kurtulmak için zorlamalı yük devretme yoluyla gereken adımları açıklamak amacıyla, bu makalede bir felaket kurtarma senaryosu sunulmaktadır. Örnek senaryo, orijinal topolojisi, birincil çoğaltma dahil olmak üzere üç eşzamanlı işlem kullanılabilirlik çoğaltmasını barındıran bir ana veri merkezinden ve iki eşzamansız işlem ikincil çoğaltmalarını barındıran bir uzak veri merkezinden oluşan bir kullanılabilirlik grubunu dikkate alır. Aşağıdaki şekilde, bu örnek kullanılabilirlik grubunun özgün topolojisi gösterilmektedir. Kullanılabilirlik grubu, ana veri merkezinde üç düğüme (Düğüm 01, Düğüm 02 ve Düğüm 03) ve uzak veri merkezindeki iki düğüme (Düğüm 04 ve Düğüm 05) sahip çok alt ağlı bir WSFC kümesi tarafından barındırılır.

Ana veri merkezi beklenmedik bir şekilde kapatılır. Üç mevcut çoğaltma çevrimdışı olur ve veritabanları kullanılamaz hale gelir. Aşağıdaki şekilde, bu hatanın kullanılabilirlik grubunun topolojisi üzerindeki etkisi gösterilmektedir.

Veritabanı yöneticisi (DBA), mümkün olan en iyi yanıtın, kullanılabilirlik grubunun zaman uyumsuz iletişim sağlayan uzak ikincil kopyalarından birine yük devretmeye zorlamak olduğunu belirler. Bu örnek, kullanılabilirlik grubunun uzak bir çoğaltmaya yük devretmesini zorladığınızda ve sonunda kullanılabilirlik grubunu özgün topolojisine geri döndürdüğünüzde uygulanan tipik adımları gösterir.

Burada sunulan hata yanıtı aşağıdaki iki aşamadan oluşur:

• Ana veri merkezinin yıkıcı hatasına yanıt verme
• Kullanılabilirlik grubunu özgün topolojisine döndürme

Ana veri merkezinin yıkıcı hatasına yanıt verme

Aşağıdaki şekilde, ana veri merkezinde yıkıcı bir hataya yanıt olarak uzak veri merkezinde gerçekleştirilen eylemler dizisi gösterilmektedir.

Bu şekildeki adımlar aşağıdaki adımları gösterir:

Adım	Eylem	Bağlantılar
1.	DBA veya ağ yöneticisi, WSFC kümesinin sağlıklı bir çoğunluğa sahip olmasını sağlar. Bu örnekte çoğunluğun zorlanması gerekir.	WSFC Çoğunluk Modları ve Oylama Yapılandırması (SQL Server) Zorunlu Çoğunluk Aracılığıyla WSFC Felaket Kurtarma (SQL Server)
2.	DBA, en az gecikme süresiyle (Node 04'te) sunucu örneğine bağlanır ve manuel bir failover zorlaması gerçekleştirir. Zorlamalı yük devretme, bu ikincil çoğaltmayı birincil role geçirir ve geri kalan ikincil çoğaltma üzerindeki (Düğüm 05'te) ikincil veritabanlarını askıya alır.	sys.dm_hadr_database_replica_states ( end_of_log_lsn sütununu sorgula. Daha fazla bilgi için bu makalenin önceki bölümlerinde yer alan Öneriler'e bakın.)
3.	DBA, kalan ikincil çoğaltmadaki ikincil veritabanlarının her birini el ile devam ettirir.	Kullanılabilirlik Veritabanını Sürdürme (SQL Server)

Kullanılabilirlik grubunu özgün topolojisine döndürme

Aşağıdaki şekilde, ana veri merkezi yeniden çevrimiçi olduktan ve WSFC düğümleri WSFC kümesiyle iletişimi yeniden kurduktan sonra kullanılabilirlik grubunu özgün topolojisine döndüren eylemler dizisi gösterilmektedir.

Önemli

WSFC kümesi kuorumu zorlanırsa, çevrimdışı düğümler yeniden başlatıldığında, aşağıdaki koşulların her ikisi de mevcutsa yeni bir kuorum oluşturabilirler: (a) zorunlu kuorum kümesindeki düğümler arasında ağ bağlantısı yoksa ve (b) yeniden başlatılan düğümler, küme düğümlerinin çoğunluğunu oluşturuyorsa. Bu durum, kullanılabilirlik grubunun her veri merkezinde birer tane olmak üzere iki bağımsız birincil çoğaltmaya sahip olacağı "bölünmüş beyin" durumuna neden olur. Azınlık quorum kümesi oluşturmaya zorlamadan önce bkz. Zorunlu Quorum (SQL Server) aracılığıyla WSFC Felaket Kurtarma.

Bu şekildeki adımlar aşağıdaki adımları gösterir:

Adım	Eylem	Bağlantılar
1.	Ana veri merkezindeki düğümler yeniden çevrimiçi olur ve WSFC kümesiyle iletişimi yeniden kurar. Kullanılabilirlik çoğaltmaları, askıya alınmış veritabanlarıyla ikincil çoğaltmalar olarak çevrimiçi olur ve DBA'nın bu veritabanlarının her birini yakında el ile devam ettirmesi gerekir.	Kullanılabilirlik Veritabanını Sürdürme (SQL Server) İpucu: Yük devretme sonrası birincil veritabanlarında olası veri kaybından endişe ediyorsanız, eşzamanlı-işlem ikincil veritabanlarından birinde askıya alınan veritabanlarında bir veritabanı anlık görüntüsü oluşturmaya çalışmalısınız. İkincil veritabanlarından herhangi biri askıya alınırken birincil veritabanında işlem günlüğü kesme işleminin geciktirildiğini unutmayın. Ayrıca, zaman uyumlu-işlem ikincil kopyasının senkronizasyon durumu, herhangi bir yerel veritabanı askıda kaldığı sürece HEALTHY'ya geçiş yapamaz.
2.	Veritabanları yeniden çalıştırıldığında, DBA yeni birincil çoğaltmayı geçici olarak zaman uyumlu işlem moduna değiştirir. Bu iki adımdan oluşur: 1. Bir çevrimdışı kullanılabilirlik replikasını zaman uyumsuz işlem yapma moduna değiştirin. 2. Yeni birincil çoğaltmayı zaman uyumlu işleme moduna değiştirin. Not: Bu adım, yeniden başlatılan eşzamanlı taahhütlü ikincil veritabanlarının SYNCHRONIZED hale gelmesini sağlar.	AlwaysOn kullanılabilirlik grubu içindeki bir çoğaltmanın kullanılabilirlik modunu değiştirme
3.	Node 03'te eşzamanlı-taahhüt ikincil çoğaltması (özgün birincil çoğaltma) eşitleme durumuna girdiğinde, DBA bu çoğaltmayı tekrar birincil yapmak için planlı bir el ile yük devretme gerçekleştirir. Node 04 üzerindeki replika, ikincil replika olmaya döner.	sys.dm_hadr_database_replica_states Kullanılabilirlik Grubunun (SQL Server) Sistem Durumunu Görüntülemek için Always On İlkelerini Kullanma Always On kullanılabilirlik grubunun (SQL Server) el ile planlı yük devretmesini gerçekleştirme
4.	DBA, yeni birincil çoğaltmaya bağlanır ve şu işlemleri gerçekleştirir: 1. Önceki birincil replikayı (uzak merkezde) asenkron-commit moduna geri alır. 2. Ana veri merkezindeki asenkron işleme ikincil çoğaltmasını senkron işleme moduna geri değiştirir.	Bir Always On kullanılabilirlik grubu içindeki çoğaltmanın kullanılabilirlik modunu değiştirme

İlgili görevler

Nisap oylarını ayarlama

• Küme Çoğunluk Düğüm Ağırlığı Ayarlarını Görüntüle
• Küme Çekirdeği Düğüm Sıklık Ayarlarını Yapılandırma
• WSFC Kümesini Çoğunluk Olmadan Başlatmaya Zorla

Planlı manuel yük devretme

• Always On kullanılabilirlik grubunun (SQL Server) el ile planlı yük devretmesini gerçekleştirme
• Yük Devretme Kullanılabilirlik Grubu Sihirbazı'nı (SQL Server Management Studio) kullanma

Troubleshoot

• Always On Kullanılabilirlik Grupları Yapılandırmasının Sorunlarını Giderme (SQL Server)
• Başarısız Add-File İşleminin Sorunlarını Giderme (Her Zaman Açık Kullanılabilirlik Grupları)

İlgili içerik

• SQL Server Always On Team Bloglarını : Resmi SQL Server Always On Team Blog
• CSS SQL Server Mühendisleri Blogları
• Yüksek Kullanılabilirlik ve Olağanüstü Durum Kurtarma için Microsoft SQL Server Always On Çözümleri Kılavuzu
• Always On kullanılabilirlik grubu nedir?
• Always On kullanılabilirlik grubu için kullanılabilirlik modları arasındaki farklar
• Yük Devretme ve Yük Devretme Modları (Her Zaman Açık Kullanılabilirlik Grupları)
• Always On kullanılabilirlik grubundaki çoğaltmalara istemci bağlantısı türleri
• Always On kullanılabilirlik gruplarını izleme araçları
• SQL Server ile Windows Server Yük Devretme Kümelemesi