Aracılığıyla paylaş

Etkin coğrafi çoğaltma

Applies to:Azure SQL Database

Bu makalede, Azure SQL Database için birincil veritabanından okunabilir ikincil veritabanına sürekli olarak veri çoğaltmanıza olanak tanıyan etkin coğrafi çoğaltma özelliğine genel bir bakış sağlanır. Okunabilir ikincil veritabanı, birincil veritabanıyla aynı Azure bölgede veya daha yaygın olarak farklı bir bölgede olabilir. Bu tür okunabilir ikincil veritabanı, geo-yedek veya geo-replika olarak da bilinir.

Etkin coğrafi çoğaltma veritabanı başına yapılandırılır. Bir veritabanı grubunun yükünü devretmek için veya uygulamanız kararlı bir bağlantı uç noktası gerektiriyorsa yük devretme gruplarını göz önünde bulundurun.

Etkin coğrafi çoğaltmaya sahip bir SQL veritabanını da taşıyabilirsiniz.

Genel bakış

Etkin coğrafi çoğaltma, bir iş sürekliliği çözümü olarak tasarlanmıştır. Etkin coğrafi çoğaltma, bölgesel bir olağanüstü durum veya büyük ölçekli bir kesinti olduğunda tek tek veritabanlarında hızlı olağanüstü durum kurtarma gerçekleştirmenizi sağlar. Coğrafi çoğaltma ayarlandıktan sonra, farklı bir Azure bölgesindeki coğrafi ikincil ortama coğrafi yük devretme işlemi başlatabilirsiniz. Coğrafi yük devretme, uygulama tarafından otomatik olarak veya kullanıcı tarafından manuel olarak başlatılır.

Aşağıdaki diyagramda, Etkin coğrafi çoğaltma kullanan coğrafi olarak yedekli bir bulut uygulamasının tipik yapılandırması gösterilmektedir.

Etkin coğrafi çoğaltma diyagramı.

Birincil veritabanınız herhangi bir nedenle başarısız olursa, ikincil veritabanlarınızdan herhangi birine coğrafi yük devretme başlatabilirsiniz. İkincil birincil role yükseltildiğinde, diğer tüm ikincil öğeler otomatik olarak yeni birincil role bağlanır.

Aşağıdaki yöntemlerden herhangi birini kullanarak coğrafi çoğaltmayı yönetebilir ve coğrafi geri yüklemeyi başlatabilirsiniz:

Etkin coğrafi çoğaltma, birincil çoğaltmada oluşturulan işlem günlüğünü tüm coğrafi çoğaltmalara zaman uyumsuz olarak çoğaltmak için Always On kullanılabilirlik grubu teknolojisini kullanır. Herhangi bir noktada ikincil veritabanı birincil veritabanının biraz gerisinde kalsa da, ikincil veritabanındaki verilerin işlem açısından tutarlı olması garanti edilir. Başka bir deyişle, kaydedilmemiş işlemler tarafından yapılan değişiklikler görünmez.

Not

Etkin coğrafi çoğaltma, veritabanı işlem günlüğünü birincil çoğaltmadan ikincil çoğaltmalara aktararak değişiklikleri çoğaltır. Transactional replication, abonelerde DML (INSERT, UPDATE, DELETE) komutlarını yürüterek değişiklikleri çoğaltan işlemle ilgisizdir.

Coğrafi çoğaltma bölgesel yedeklilik sağlar. Bölgesel yedeklilik, uygulamaların doğal afetler, yıkıcı insan hataları veya kötü amaçlı eylemlerden kaynaklanan Azure bölgenin tamamının veya bir bölgenin bölümlerinin kalıcı kaybından hızla kurtulmasını sağlar. Coğrafi çoğaltma için RPO (Geri Dönüş Noktası Hedefi), Azure SQL Database'de İş Sürekliliği başlığı altında bulunabilir.

Aşağıdaki şekilde, Batı ABD 2 bölgesinde birincil ve Doğu ABD bölgesinde coğrafi ikincil ile yapılandırılmış etkin coğrafi çoğaltma örneği gösterilmektedir.

SQL DB coğrafi çoğaltma ilişkisi gösteren Azure portalının ekran görüntüsü.

Olağanüstü durum kurtarmanın yanı sıra, aşağıdaki senaryolarda etkin coğrafi çoğaltma kullanılabilir:

  • Veritabanı geçişi: Veritabanını en düşük kapalı kalma süresiyle bir sunucudan diğerine geçirmek için etkin coğrafi çoğaltmayı kullanabilirsiniz.
  • Uygulama yükseltmeleri: Uygulama yükseltmeleri sırasında geri dönüş kopyası olarak ek bir yedek kopya oluşturabilirsiniz.

Tam iş sürekliliği sağlamak için veritabanı bölgesel yedekliliği eklemek çözümün yalnızca bir parçasıdır. Yıkıcı bir hatadan sonra bir uygulamayı (hizmeti) uçtan uca kurtarmak, hizmeti ve bağımlı hizmetleri oluşturan tüm bileşenlerin kurtarılmasını gerektirir. Bu bileşenlere örnek olarak istemci yazılımı (örneğin, özel JavaScript içeren bir tarayıcı), web ön uçları, depolama ve DNS verilebilir. Tüm bileşenlerin aynı hatalara dayanıklı olması ve uygulamanızın kurtarma süresi hedefi (RTO) içinde kullanılabilir hale gelmesi kritik önem taşır. Bu nedenle, tüm bağımlı hizmetleri tanımlamanız ve bunların sağladığı garantileri ve özellikleri anlamanız gerekir. Ardından, bağlı olduğu hizmetlerin yük devretmesi sırasında hizmetinizin çalıştığından emin olmak için yeterli adımları atmalısınız. Olağanüstü durum kurtarma çözümleri tasarlama hakkında daha fazla bilgi için bkz. Azure SQL Database kullanarak genel olarak kullanılabilir hizmetleri tasarlama.

Terminoloji ve özellikler

  • Otomatik zaman uyumsuz çoğaltma: Yalnızca var olan bir veritabanı için coğrafi ikincil kopya oluşturabilirsiniz. Coğrafi ikincil, birincil veritabanına sahip sunucunun dışında herhangi bir mantıksal sunucuda oluşturulabilir. Coğrafi ikincil çoğaltma oluşturulduktan sonra birincil veritabanının verileriyle doldurulur. Bu işlem, tohumlama olarak bilinir. Bir coğrafi ikincil oluşturulduktan ve başlatıldıktan sonra, birincil veritabanındaki güncelleştirmeler otomatik ve asenkron olarak coğrafi ikincil kopyaya çoğaltılır. Zaman uyumsuz replikasyon, işlemlerin çoğaltılmadan önce birincil veritabanında onaylandığı anlamına gelir.

  • Okunabilir coğrafi ikincil çoğaltmalar: Bir uygulama, birincil veritabanına erişmek için kullanılan aynı veya farklı güvenlik sorumlularını kullanarak salt okunur sorgular yürütmek için coğrafi ikincil çoğaltmaya erişebilir. Daha fazla bilgi için bkz. Salt okunur sorgu iş yüklerini boşaltmak için salt okunur çoğaltmaları kullanma.

Önemli

Coğrafi çoğaltmayı kullanarak birincil çoğaltmayla aynı bölgede ikincil çoğaltmalar oluşturabilirsiniz. Aynı bölgedeki okuma ölçeği genişletme senaryolarını karşılamak için bu ikincilleri kullanabilirsiniz. Ancak, aynı bölgedeki ikincil replica, yıkıcı hatalara veya büyük ölçekli kesintilere karşı ek dayanıklılık sağlamaz ve bu nedenle olağanüstü durum kurtarma amacıyla uygun bir failover hedefi değildir. Ayrıca kullanılabilirlik alanı yalıtımını garanti etmez. Kullanılabilirlik alanı yalıtımı elde etmek için İş Açısından Kritik veya Premium hizmet katmanları alanlar arası yedekli yapılandırmayı veya Genel Amaçlı hizmet katmanı alanlar arası yedekli yapılandırmayı kullanın.

  • Yük devretme (veri kaybı yok): Yük devretme (veri kaybı olmadan) başlatıldığında, birincil ve coğrafi ikincil veritabanlarının rolleri değiştirilmeden önce tam veri eşitleme adımı tamamlanır. Bu, veri kaybı olmamasını sağlar. Yük devretme süresi, coğrafi ikincil sunucuya eşitlenmesi gereken birincil işlem günlüğünün boyutuna bağlıdır. Aşağıdaki senaryolar için yük devretme tasarlanmıştır:

    • Veri kaybı kabul edilemez olduğunda üretimde DR tatbikatları gerçekleştirin.
    • Veritabanını farklı bir bölgeye taşıma
    • Kesinti azaltıldıktan sonra veritabanını birincil bölgeye döndür (yeniden çalışma olarak bilinir).

  • Zorlamalı yük devretme (olası veri kaybı):Zorlamalı yük devretme, birincil ile eşitlemeyi beklemeden coğrafi ikincil rolü hemen birincil role değiştirir. Birincil üzerinde işlenen ancak henüz ikincilye çoğaltılmayan tüm işlemler kaybolur. Bu işlem, birincil erişilebilir olmadığında kesintiler sırasında bir kurtarma yöntemi olarak tasarlanmıştır, ancak veritabanı kullanılabilirliğinin hızla geri yüklenmesi gerekir. Özgün birincil sunucu yeniden çevrimiçi olduğunda, otomatik olarak yeniden bağlanır, birincilden alınan güncel verilerle yeniden yapılandırılır ve yeni coğrafi ikincil sunucu haline gelir.

Önemli

Yük devretme veya zorlamalı yük devretme işleminden sonra, yeni birincil sunucu artık farklı bir mantıksal sunucu üzerinde bulunduğu için bağlantı uç noktası değişir.

  • Birden çok okunabilir coğrafi ikincil: Birincil için en fazla dört coğrafi ikincil oluşturulabilir. Yalnızca bir ikincil varsa ve başarısız olursa, uygulama yeni bir ikincil oluşturulana kadar daha yüksek risk altında kalmaktadır. Birden çok ikincil öğe varsa, ikincillerden biri başarısız olsa bile uygulama korunur. Salt okunur iş yüklerinin ölçeğini genişletmek için ek ikinciller de kullanılabilir.

İpucu

Küresel olarak dağıtılmış bir uygulama oluşturmak için aktif coğrafi çoğaltma kullanıyorsanız ve dörtten fazla bölgedeki verilere salt okunur erişim sağlamanız gerekiyorsa, ek coğrafi çoğaltmalar oluşturmak üzere bir ikincilin ikincilini (zincirleme olarak bilinen bir işlem) oluşturabilirsiniz. Zincirli coğrafi replikalardaki çoğaltma gecikmesi, doğrudan birincile bağlı coğrafi replikalardan daha yüksek olabilir. Zincirlenmiş coğrafi çoğaltma topolojilerinin ayarlanması yalnızca program aracılığıyla desteklenir, Azure portaldan desteklenmez.

  • Elastik havuzdaki veritabanlarının coğrafi çoğaltması: Her coğrafi ikincil veritabanı, tek bir veritabanı veya elastik havuzdaki bir veritabanı olabilir. Her coğrafi ikincil veritabanı için elastik havuz seçimi ayrıdır ve topolojideki (birincil veya ikincil) başka bir çoğaltmanın yapılandırmasına bağlı değildir. Her elastik havuz tek bir mantıksal sunucuda yer alır. Mantıksal sunucudaki veritabanı adlarının benzersiz olması gerektiğinden, aynı birincil veritabanının birden fazla coğrafi ikincil kopyası, hiçbir zaman bir elastik havuzu paylaşamaz.

  • Kullanıcı tarafından denetlenen coğrafi yük devretme ve yeniden çalışma: İlk dengeli dağıtımı tamamlamış bir coğrafi ikincil, uygulama veya kullanıcı tarafından herhangi bir zamanda açıkça birincil role (yük devredildi) geçirilebilir. Birincil erişilemez olduğunda meydana gelen bir kesinti sırasında, coğrafi ikincili hemen yeni birincil olarak terfi ettiren yalnızca zorunlu yük devretme kullanılabilir. Kesinti giderildiğinde, sistem kurtarılan birincili otomatik olarak coğrafi yedek yapar ve yeni birincil ile eşzamanlı hale getirir. Coğrafi çoğaltmanın zaman uyumsuz yapısı nedeniyle, birincil işlem coğrafi ikincil bir işleme çoğaltılmadan önce başarısız olursa, zorlamalı yük devretme işlemleri sırasında son işlemler kaybolabilir. Birden çok coğrafi ikincil içeren bir birincil devredildiğinde, sistem çoğaltma ilişkilerini otomatik olarak yeniden yapılandırarak kalan coğrafi ikincilleri kullanıcı müdahalesi gerektirmeden yeni yükseltilen birincile bağlar. Coğrafi yük devretmeye neden olan kesinti azaltıldıktan sonra birincil kaynağın özgün bölgesine döndürülmesi istenebilir. Bunu gerçekleştirmek için elle yük devretme yapın.

  • Bekleme çoğaltması: İkincil çoğaltmanız yalnızca olağanüstü durum kurtarma (DR) için kullanılıyorsa ve okuma veya yazma iş yükleri yoksa, lisanslama maliyetlerinden tasarruf etmek için çoğaltmayı bekleme olarak belirleyebilirsiniz.

Coğrafi yük devretme işlemine hazırlık

Coğrafi yük devretme sonrasında uygulamanızın yeni birincil sunucuya hemen erişebildiğinden emin olmak için, ikincil sunucunuz için kimlik doğrulaması ve ağ erişiminin düzgün yapılandırıldığını doğrulayın. Ayrıntılar için bkz. Coğrafi geri yükleme veya yük devretme için Azure SQL Database güvenliğini yapılandırma ve yönetme. Ayrıca, ikincil veritabanındaki yedekleme bekletme ilkesinin birincil veritabanındakiyle eşleşdiğini doğrulayın. Bu ayar veritabanının bir parçası değildir ve birincil ayardan çoğaltılamaz. Coğrafi ikincil varsayılan olarak yedi günlük varsayılan PITR saklama süresiyle yapılandırılır. Daha fazla bilgi için bkz. Azure SQL Database'da otomatik yedeklemeler.

Önemli

Veritabanınız bir yük devretme grubunun üyesiyse, coğrafi kopyalama yük devretme komutunu kullanarak yük devretmeyi başlatmanız mümkün değildir. Grup için yük devretme komutunu kullanın. Tek bir veritabanına yük devretmeniz gerekiyorsa, önce veritabanını yük devretme grubundan kaldırmanız gerekir. Bkz. Failover gruplarına genel bakış ve en iyi uygulamalar (Azure SQL Database) için ayrıntılar.

Coğrafi ikincil bölge konfigürasyonu

Hem birincil hem de coğrafi ikincilin aynı hizmet katmanına sahip olması gereklidir. Ayrıca, coğrafi ikincil veritabanının, ana veritabanı ile aynı yedekleme depolama yedekliliği, işlem katmanı (sağlanan veya sunucusuz) ve işlem boyutu (DTU veya sanal çekirdekler) ile yapılandırılması şiddetle tavsiye edilir. Birincil sistem yoğun bir yazma iş yüküyle karşılaşıyorsa, daha düşük işlem boyutuna sahip bir coğrafi ikincil iş yükünü sürdüremeyebilir. Bu, coğrafi ikincilde çoğaltma gecikmesine neden olur ve sonunda coğrafi ikincilin kullanılamamasına neden olabilir. Aktif coğrafi çoğaltma, ikincillerin öne yetişmesine izin vermek için gerekirse birincil sistemin işlem günlüğünün hızını kısıtlar.

Dengesiz bir coğrafi ikincil yapılandırmanın bir diğer sonucu da yük devretmeden sonra yeni birincilin işlem kapasitesinin yetersiz olması nedeniyle uygulama performansının düşmesidir. Bu durumda, veritabanının ölçeğini yeterli kaynaklara sahip olacak şekilde büyütmek gerekir; bu da önemli zaman alabilir ve ölçek artırma işleminin sonunda yüksek kullanılabilirlik yük devretmesi gerektirir ve bu da uygulama iş yüklerini kesintiye uğratabilir.

İpucu

Coğrafi çoğaltma ile gecikme hakkında ayrıntılı sorun giderme yönergeleri için bkz. Coğrafi çoğaltma yineleme gecikmesi sorunlarını giderme.

Coğrafi ikincil sunucuyu farklı bir konfigürasyonla oluşturmaya karar verirseniz, birincil sunucuda zaman içinde kayıt G/Ç hızını izlemeniz gerekir. Bu, çoğaltma yükünü sürdürmek için gereken coğrafi ikincil değerin en düşük işlem boyutunu tahminen bilmenizi sağlar. Örneğin, birincil veritabanınız P6 (1000 DTU) ise ve log G/Ç seviyesi %50 devam ediyorsa, coğrafi ikincil veritabanı en az P4 (500 DTU) olmalıdır. Geçmiş günlük G/Ç verilerini almak için sys.resource_stats görünümünü kullanın. Kısa vadeli ani artışları daha iyi yansıtan daha yüksek ayrıntı düzeyine sahip son günlük G/Ç verilerini almak için sys.dm_db_resource_stats görünümünü kullanın.

İpucu

İşlem günlüğü G/Ç kısıtlama işlemi aşağıdaki senaryolarda gerçekleşebilir:

  • Coğrafi ikincil, birincilden daha düşük bir işlem boyutundaysa. HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO sys.dm_exec_requests vesys.dm_os_wait_stats veritabanı görünümlerinde bekleme türünü arayın.
  • Azaltma işlemi, işlem boyutuyla ilgili olmayan nedenlerden, örneğin toplu ekleme, SELECT INTO ve dizin derlemeleri için ağır iş yükleri gibi durumlarda da oluşabilir. Farklı günlük girdi/çıktı azaltma türleri için bekleme tipleri hakkında daha fazla bilgi için bkz. İşlem günlüğü hızı idaresi.

Varsayılan olarak, coğrafi ikincil yedekleme depolama yedekliliği birincil veritabanıyla aynıdır. Farklı bir yedek depolama yedekliliği ile coğrafi-ikincil yapılandırmayı tercih edebilirsiniz. Yedeklemeler her zaman birincil veritabanında alınır. İkincil, farklı bir yedekleme depolama yedekliliğiyle yapılandırıldıysa, coğrafi yük devretmenin ardından, coğrafi ikincil birincil konumuna yükseltildiğinde, yeni yedeklemeler, yeni birincil (önceki ikincil) üzerinde seçilen depolama türüne (RA-GRS, ZRS, LRS) göre depolanacak ve faturalandırılacaktır.

Yedekleme kopyası ile maliyetlerden tasarruf edin

İkincil çoğaltmanız sadece olağanüstü durum kurtarma (DR) amacıyla kullanılıyorsa ve herhangi bir okuma ya da yazma iş yükü yoksa, yeni bir etkin coğrafi çoğaltma ilişkisi yapılandırırken veritabanını bekleme konumuna alarak lisanslama maliyetlerinden tasarruf edebilirsiniz.

Daha fazla bilgi edinmek için lisanssız yedek kopyayı gözden geçirin.

Abonelikler arası coğrafi çoğaltma

  • her iki abonelik de aynı Microsoft Entra kiracıda olduğu sürece abonelikler arasında Etkin coğrafi çoğaltma ayarlamak için Azure portalını kullanabilirsiniz.

  • Birincil veya ikincil mantıksal sunucuda Microsoft Entra-only kimlik doğrulaması Azure SQL etkinleştirildiğinde ve oluşturma işlemi bir Microsoft Entra ID kullanıcısı tarafından denendiğinde, aynı veya farklı Microsoft Entra kiracındaki bir mantıksal sunucuda abonelikler arası coğrafi ikincil oluşturma desteklenmez.

Yöntemler ve adım adım yönergeler için bkz. Tutorial: Etkin coğrafi çoğaltmayı ve yük devretmeyi yapılandırma (Azure SQL Database).

Özel uç noktalar

Özel uç nokta üzerinden birincil sunucuya bağlanırken T-SQL kullanarak coğrafi ikincil ekleme desteklenmez.

Özel uç nokta yapılandırıldıysa ancak genel ağ erişimine izin veriliyorsa, birincil sunucuya genel IP adresinden bağlanıldığında coğrafi ikincil ekleme desteklenir.

İkinci bir coğrafi konum eklendiğinde, genel ağ erişimi reddedilebilir.

Kimlik bilgilerini ve güvenlik duvarı kurallarını eşitlenmiş durumda tutma

Veritabanına bağlanmak için genel ağ erişimini kullanırken, coğrafi olarak çoğaltılan veritabanları için veritabanı düzeyinde IP güvenlik duvarı kurallarını kullanmanızı öneririz. Bu kurallar veritabanıyla çoğaltılır ve bu da tüm coğrafi ikincillerin birincil ile aynı IP güvenlik duvarı kurallarına sahip olmasını sağlar. Bu yaklaşım, müşterilerin birincil ve ikincil veritabanlarını barındıran sunucularda güvenlik duvarı kurallarını el ile yapılandırma ve koruma gereksinimini ortadan kaldırır. Benzer şekilde, veri erişimi için bağımsız veritabanı kullanıcılarının kullanılması hem birincil hem de ikincil veritabanlarının her zaman aynı kimlik doğrulama kimlik bilgilerine sahip olmasını sağlar. Bu şekilde, coğrafi yük devretmeden sonra kimlik bilgisi uyuşmazlıklarından dolayı herhangi bir kesinti olmaz. Oturum açma bilgilerini ve kullanıcıları (bağımsız kullanıcılar yerine) kullanıyorsanız, ikincil veritabanınızda aynı oturum açma bilgilerinin mevcut olduğundan emin olmak için ek adımlar uygulamanız gerekir. Yapılandırma ayrıntıları için bkz. Coğrafi geri yükleme veya yük devretme için Azure SQL Database güvenliğini yapılandırma ve yönetme.

Birincil veritabanını ölçeklendirme

Coğrafi ikincil öğelerin bağlantısını kesmeden birincil veritabanının ölçeğini artırabilir veya farklı bir işlem boyutuna (aynı hizmet katmanı içinde) azaltabilirsiniz. Ölçeği büyütürken, önce coğrafi ikincil ölçeği artırmanızı ve ardından birincil ölçeği artırmanızı öneririz. Ölçeği azaltırken işlemi tersine çevirin: Önce birincil örneğin ölçeğini azaltıp ardından ikincil örneğin ölçeğini azaltın.

Yük devretme grupları hakkında bilgi almak için bir yük devretme grubundaki çoğaltmayı ölçeklendirme bölümünü inceleyin.

Kritik veri kaybını önleme

Geniş alan ağlarının yüksek gecikme süresi nedeniyle, coğrafi çoğaltma zaman uyumsuz bir çoğaltma mekanizması kullanır. Eşzamansız replikasyon, birincil sistem arızalandığında veri kaybı olasılığını kaçınılmaz hale getirir. Kritik işlemleri veri kaybına karşı korumak için uygulama geliştiricisi, işlemi işledikten hemen sonra sp_wait_for_database_copy_sync saklı yordamını çağırabilir. Çağrılan sp_wait_for_database_copy_sync, son işlenen işlem ikincil veritabanının işlem günlüğüne iletilip sağlamlaştırılana kadar, çağıran iş parçacığını duraklatır. Ayrıca, iletilen işlemlerin ikincil sistemde yeniden oynatılması (yeniden yapılması) için bekler. sp_wait_for_database_copy_sync Sistem saklı yordamının kapsamı belirli bir coğrafi çoğaltma bağlantısına göre belirlenmiştir. Birincil veritabanına bağlantı hakları olan tüm kullanıcılar bu yordamı çağırabilir.

Not

sp_wait_for_database_copy_sync belirli işlemler için coğrafi yük devretme (geo-failover) sonrasında veri kaybını önler, ancak okuma erişimi için tam eşitlemeyi garanti etmez. Prosedür sp_wait_for_database_copy_sync çağrısının neden olduğu gecikme önemli olabilir ve çağrı sırasında birincil sunucuda henüz iletilmemiş işlem günlüğünün boyutuna bağlıdır.

Coğrafi çoğaltma gecikmesini izleme

RPO'ya ilişkin gecikmeyi izlemek için, birincil veritabanında replication_lag_sec sütununu kullanarak sys.dm_geo_replication_link_status üzerindeki verileri inceleyin. Birincilde taahhüt edilen işlemler ile ikincildeki işlem günlüğüne katılaştırılan işlemler arasındaki gecikmeyi saniye cinsinden gösterir. Örneğin, gecikme süresi bir saniye ise, birincil şu anda bir hizmet kesintisinden etkilenirse ve coğrafi yük devretme başlatılırsa, son saniyede tamamlanan işlemler kaybolur.

Coğrafi ikincil veritabanında sağlamlaştırılmış birincil veritabanındaki değişikliklerle ilgili gecikmeyi ölçmek için, coğrafi ikincildeki zamanı birincil veritabanındaki aynı değerle karşılaştırın last_commit .

İpucu

Birincil üzerinde replication_lag_secNULL ise, bu, birincilin şu anda coğrafi ikincilin ne kadar geride olduğunu bilmediği anlamına gelir. Bu genellikle işlem yeniden başlatıldıktan sonra gerçekleşir ve geçici bir koşul olmalıdır. replication_lag_sec uzun süre boyunca NULL döndürüyorsa uyarı göndermeyi göz önünde bulundurun. Coğrafi ikincil sunucunun bağlantı hatası nedeniyle birincil ile iletişim kuramadığını gösterebilir.

Ayrıca coğrafi ikincil ve birincil zaman arasındaki last_commit farkın büyük olmasına neden olabilecek koşullar da vardır. Örneğin, uzun bir süre değişiklik yapılmadıktan sonra birincilde commit işlemi yapıldığında, fark hızla sıfıra dönmeden önce büyük bir değere sıçrar. Bu iki değer arasındaki fark uzun süre büyük kalırsa bir uyarı göndermeyi göz önünde bulundurun.

Etkin coğrafi çoğaltmayı program aracılığıyla yönetme

Etkin coğrafi çoğaltma T-SQL, Azure PowerShell ve REST API kullanılarak program aracılığıyla da yönetilebilir. Aşağıdaki tablolarda kullanılabilir komutlar kümesi açıklanmaktadır. Etkin coğrafi çoğaltma, Azure SQL Database REST API ve Azure PowerShell cmdlet'leri dahil olmak üzere yönetim için bir dizi Azure Resource Manager API içerir. Bu API'ler Azure rol tabanlı erişim denetimi (Azure RBAC) ile çalışma desteği sağlar. Erişim rollerini uygulama hakkında daha fazla bilgi için bkz. Azure rol tabanlı erişim denetimi (Azure RBAC).

Önemli

Bu T-SQL komutları yalnızca etkin coğrafi çoğaltma için geçerlidir ve yük devretme grupları için geçerli değildir.

Komut Açıklama
ALTER DATABASE (Veritabanını Değiştir) Var olan bir veritabanı için ikincil veritabanı oluşturmak ve veri çoğaltmasını başlatmak için ADD SECONDARY ON SERVER argümanını kullanın.
ALTER DATABASE (Veritabanını Değiştir) Yük devretmeyi başlatmak için ikincil veritabanını birincil olarak değiştirmek için FAILOVER veya FORCE_FAILOVER_ALLOW_DATA_LOSS kullanın.
ALTER DATABASE (Veritabanını Değiştir) SQL Veritabanı ile belirtilen ikincil veritabanı arasındaki veri çoğaltmasını sonlandırmak için kullanın REMOVE SECONDARY ON SERVER .
sys.geo_replication_links Bir sunucudaki her veritabanı için tüm mevcut çoğaltma bağlantıları hakkında bilgi döndürür.
sys.dm_geo_replication_link_status Son çoğaltma zamanını, son çoğaltma gecikmesini ve belirli bir veritabanı için çoğaltma bağlantısı hakkındaki diğer bilgileri alır.
sys.dm_operation_status Çoğaltma bağlantılarına yapılan değişiklikler de dahil olmak üzere tüm veritabanı işlemlerinin durumunu gösterir.
sys.sp_wait_for_database_copy_sync Uygulamanın, tüm işlenen işlemler coğrafi yedek işlem günlüğünde kalıcı hale getirildikten sonra beklemesine neden olur.

Sorun giderme

Coğrafi çoğaltma gecikmesi sorunlarını giderme hakkında daha fazla bilgi için bkz. Coğrafi çoğaltma gecikmesi sorunlarını giderme.

İlgili içerik

Etkin coğrafi çoğaltmayı yapılandırma:

Diğer iş sürekliliği içeriği:

  • Last updated on