Aracılığıyla paylaş

Birleştirme çoğaltması çakışmaları nasıl algılar ve çözer?

Birleştirme çoğaltması birden çok düğümün otonom veri değişiklikleri yapmasına olanak tanır, bu nedenle bir düğümde yapılan değişikliğin başka bir düğümdeki aynı verilerde yapılan değişiklikle çakışabileceği durumlar vardır. Diğer durumlarda Birleştirme Aracısı kısıtlama ihlali gibi bir hatayla karşılaşır ve belirli bir düğümde yapılan bir değişikliği başka bir düğüme yayamaz. Bu makalede çakışma türleri, çakışmaların nasıl algılandığı ve çözümlenebileceği ve algılama ile çözümü etkileyen faktörler açıklanmaktadır.

Çakışmaları algılama ve çözme

Birleştirme Aracısı, sistem tablosunun sütununu lineageMSmerge_contents kullanarak çakışmaları algılar; bir makale için sütun düzeyinde izleme etkinleştirildiyse, COLV1 sütun da kullanılır. Bu sütunlar, bir satır veya sütunun ne zaman eklendiği veya güncelleştirildiği ve birleştirme çoğaltma topolojisindeki hangi düğümlerin satır veya sütunda değişiklik yaptığı hakkında meta veriler içerir. Bu meta verileri görüntülemek için sp_showrowreplicainfo sistem saklı yordamını kullanabilirsiniz.

Birleştirme Aracısı eşitleme sırasında uygulanacak değişiklikleri numaralandırdıkça, Yayımcı ve Abone'deki her satırın meta verilerini karşılaştırır. Birleştirme Aracısı, topolojide bir satır veya sütunun birden fazla düğümde değişip değişmediğini belirlemek için bu meta verileri kullanır ve bu da olası bir çakışmayı gösterir. Çakışma algılandıktan sonra, Birleştirme Aracısı bir çakışma ile makale için belirtilen çakışma çözümleyicisini başlatır ve çakışmayı kazananı belirlemek için çözümleyiciyi kullanır. Kazanan satır Yayımcı ve Abone'ye uygulanır ve kaybeden satırdaki veriler çakışma tablosuna yazılır.

Makale için etkileşimli çakışma çözümü seçmediğiniz sürece çakışmalar Birleştirme Aracısı tarafından otomatik olarak ve hemen çözülür. Daha fazla bilgi için bkz. Microsoft Çoğaltma Etkileşimli Çakışma Çözümleyicisi. Birleştirme çoğaltması Çakışma Görüntüleyicisi'ni kullanarak çakışmanın kazanan satırını el ile değiştirirseniz, Birleştirme Aracısı sonraki eşitleme sırasında satırın kazanan sürümünü kaybeden sunucuya uygular.

Çözülen çakışmaları kaydet

Birleştirme Aracısı çakışma çözümleyicisindeki mantığa göre çakışmayı çözümledikten sonra çakışma verilerini çakışma türüne göre günlüğe kaydeder:

  • UPDATE ve INSERT çakışmaları için, satırın kaybeden sürümünü conflict_<PublicationName>_<ArticleName> şeklinde adlandırılan makaleye ait çakışma tablosuna yazar. Çakışma türü gibi genel çakışma bilgileri tablosuna MSmerge_conflicts_infoyazılır.

  • DELETE çakışmaları için, satırın kayıp sürümünü MSmerge_conflicts_info tablosuna yazar. Bir güncellemenin karşısında bir silme işlemi kaybettiğinde, kaybeden satır için veri yoktur (çünkü bu bir silme işlemiydi), bu nedenle conflict_<PublicationName>_<ArticleName> üzerine hiçbir şey yazılmaz.

Her makalenin çakışma tabloları, parametresi sp_addmergepublicationiçin @conflict_logging belirtilen değere bağlı olarak yayın veritabanında, abonelik veritabanında veya her ikisinde de (varsayılan) oluşturulur. Her bir çakışma tablosu, origin_datasource_id sütununun eklenmesiyle temel aldığı makaleyle aynı yapıya sahiptir. Birleştirme Aracısı, yayın için sp_addmergepublication'in @conflict_retention parametresi kullanılarak belirtilen çakışma saklama süresinden daha eski olan çakışma tablosundaki verileri siler (varsayılan değer 14 gündür).

Çoğaltma, çakışma verilerini görüntülemek için Çoğaltma Çakışma Görüntüleyicisi'ni ve saklı yordamları (sp_helpmergearticleconflicts, sp_helpmergeconflictrowsve sp_helpmergedeleteconflictrows) sağlar. Daha fazla bilgi için bkz . Birleştirme Çoğaltması için çakışma çözümü.

Çakışma çözümünü etkileyen faktörler

Birleştirme Aracısı'nın algılediği çakışmayı nasıl çözeceğini etkileyen iki faktör vardır:

  • Aboneliğin türü: istemci veya sunucu (aboneliğin çekme aboneliği mi yoksa anında iletme aboneliği mi olduğu çakışma çözümünü etkilemez).

  • Kullanılan çakışma izleme türü: satır düzeyi, sütun düzeyi veya mantıksal kayıt düzeyi.

Abonelik türleri

Bir abonelik oluşturduğunuzda, bunun bir gönderme veya çekme aboneliği olup olmadığını belirtmeye ek olarak, bunun bir istemci mi yoksa sunucu aboneliği mi olduğunu belirtirsiniz; abonelik oluşturulduktan sonra tür değiştirilemez (SQL Server'ın önceki sürümlerinde istemci ve sunucu aboneliklerine sırasıyla yerel ve genel abonelikler olarak başvuruldu).

Atanmış öncelik değerine (0,00 ile 99,99) sahip aboneliğe sunucu aboneliği adı verilir; Publisher'ın öncelik değerini kullanan bir abonelik, istemci aboneliği olarak adlandırılır. Ayrıca, sunucu abonelikleri olan aboneler verileri diğer Abonelere yeniden yayımlayabilir. Aşağıdaki tabloda, her abone türünün temel farklılıkları ve kullanımları özetlemektedir.

Türü Öncelik değeri Kullanılmış
Sunucu Kullanıcı tarafından atanan Farklı Abonelerin farklı önceliklere sahip olmasını istediğinizde.
Müşteri 0,00, ancak veri değişiklikleri eşitlemeden sonra Publisher'ın öncelik değerini varsayar Tüm Abonelerin aynı önceliğe sahip olması ve çakışmada kazananın, Yayımcı ile birleştirilecek olan ilk Abone olmasını istediğinizde.

İstemci aboneliğinde satır değiştirilirse, abonelik eşitlenene kadar değişikliğe öncelik atanmaz. Eşitleme sırasında Aboneden yapılan değişikliklere Yayımcı'nın önceliği atanır ve sonraki eşitlemeler için bu önceliği korur. Bir anlamda, Yayımcı değişikliğin sahipliğini üstlenir. Bu davranış, ilk Abonenin Yayımcı ile senkronize olmasına izin vererek, belirli bir satır veya sütun için diğer Abonelerle gelecekteki çakışmaları kazanmasını sağlar.

Sunucu aboneliğindeki bir satırı değiştirdiğinizde, abonelik önceliği değişikliğin meta verilerinde depolanır. Bu öncelik değeri, diğer Abonelerdeki değişikliklerle birleştirildiğinde, değiştirilen satırla birlikte ilerler. Bu, daha yüksek öncelikli bir abonelik tarafından yapılan bir değişikliğin daha düşük önceliğe sahip bir abonelik tarafından yapılan sonraki bir değişiklikte kaybedilmez.

Abonelik, Publisher'dan daha yüksek bir açık öncelik değerine sahip olamaz. Birleştirme çoğaltması topolojisindeki en üst düzey Publisher her zaman 100.00 açık bir öncelik değerine sahiptir. Bu yayına yönelik tüm aboneliklerin öncelik değeri bu değerden küçük olmalıdır. Yeniden yayım topolojisinde:

  • Abone verileri yeniden yayımlarsa, aboneliğin abonenin üzerindeki Yayımcı'dan daha düşük bir öncelik değerine sahip bir sunucu aboneliği olması gerekir.

  • Abone verileri yeniden yayımlamıyorsa (yeniden yayımlama ağacının yaprak düzeyinde olduğundan), aboneliğin bir istemci aboneliği olması gerekir.

Sunucu abonelikleri ve öncelikleri hakkında daha fazla bilgi için bkz. Abonelik türüne ve atanan önceliklere göre birleştirme çakışması çözümü örneği.

Gecikmeli çakışma bildirimi

Gecikmeli çakışma bildirimi, farklı çakışma önceliklerine sahip sunucu aboneliklerinde oluşabilir. Daha düşük öncelikli bir Abone ile Yayımcı arasında çakışmayan değişikliklerin değiş tokuş edildiği ve bu değişikliklerin daha yüksek öncelikli bir Abonenin Yayımcı ile eşitlenmesi sırasında çakışmalara neden olduğu aşağıdaki senaryoyu göz önünde bulundurun:

  1. Publisher ve LowPrioritySub adlı düşük öncelikli abone, çakışma olmadan çeşitli eşitlemeler üzerinde değişiklik değiştirir.

  2. HighPrioritySub adlı yüksek öncelikli bir Abone, bir süredir Yayımcı ile eşzamanlanmamıştır, ve LowPrioritySub Abonesi'nin yaptığı aynı satırlarda değişiklik yapmıştır.

  3. HighPrioritySub Abonesi, Publisher ile eşitlenir ve LowPrioritySub Abonesi'ne göre daha yüksek önceliğe sahip olduğu için, kendi değişiklikleriyle LowPrioritySub Abonesi arasındaki çakışmaları kazanır. Yayımcı artık HighPrioritySub Abonesi tarafından yapılan değişiklikleri içerir.

  4. LowPrioritySub Abonesi daha sonra Publisher ile birleştirilir ve HighPrioritySub Abonesi ile çakışmalar nedeniyle çok sayıda değişiklik indirir.

Düşük öncelikli Abone, artık çakışma kaybedeni olan aynı satırlarda değişiklik yaptığında bu durum sorunlu hale gelebilir. Bu, bu Abone tarafından yapılan tüm değişikliklerin kaybolmasına neden olabilir. Bu sorunun olası bir çözümü, iş mantığı aksini belirtmediği sürece tüm Abonelerin aynı önceliğe sahip olduğundan emin olmaktır.

İzleme düzeyi

Veri değişikliğinin çakışma olarak nitelenip nitelenmemesi, bir makale için ayarladığınız çakışma izleme türüne bağlıdır: satır düzeyi, sütun düzeyi veya mantıksal kayıt düzeyi. Mantıksal kayıt düzeyi izleme hakkında daha fazla bilgi için bkz. Gelişmiş Birleştirme Çoğaltma Çakışması - Mantıksal Kayıtta Çözümleme.

Satır düzeyinde çakışmalar tanındığında, karşılık gelen satırlarda yapılan değişiklikler, değişikliklerin aynı sütunda yapılıp yapılmadığına bakılmaksızın çakışma olarak değerlendirilir. Örneğin, Yayımcı satırının adres sütununda bir değişiklik yapıldığını ve ilgili Abone satırının telefon numarası sütununda (aynı tabloda) ikinci bir değişiklik yapıldığını varsayalım. Satır düzeyi izlemede, aynı satırda değişiklikler yapıldığından çakışma algılanır. Sütun düzeyinde izleme ile, aynı satırdaki farklı sütunlarda değişiklik yapıldığından çakışma algılanmadı.

Satır düzeyi ve sütun düzeyinde izleme için çakışmanın çözümü aynıdır: Çakışmayı kazanandan gelen veriler tüm veri satırının üzerine yazılır (mantıksal kayıt düzeyi izleme için çözüm makale özelliğine logical_record_level_conflict_resolutionbağlıdır).

Uygulama semantiği genellikle hangi izleme seçeneğinin kullanılacağını belirler. Örneğin, adres ve telefon numarası gibi genel olarak aynı anda girilen müşteri verilerini güncelleştiriyorsanız satır düzeyi izleme seçilmelidir. Bu durumda sütun düzeyi izleme seçilirse, bir konumdaki müşteri adresinde ve başka bir konumdaki müşteri telefon numarasında yapılan değişiklikler çakışma olarak algılanmazdı: veriler eşitlemede birleştirilir ve hata yanıtsız kalır. Diğer durumlarda, farklı sitelerdeki sütunları tek tek güncelleştirmek en mantıklı seçenek olabilir. Örneğin, iki sitenin müşteri üzerinde gelir düzeyi ve toplam kredi kartı satın alma tutarı gibi farklı istatistik bilgilerine erişimi olabilir. Sütun düzeyinde izlemenin seçilmesi, her iki sitenin de gereksiz çakışmalar oluşturmadan farklı sütunlar için istatistiksel verileri girebilmesini sağlar.

Uyarı

Uygulamanız sütun düzeyinde izleme gerektirmiyorsa, genellikle daha iyi eşitleme performansına neden olduğundan satır düzeyi izleme (varsayılan) kullanmanız önerilir. Satır izleme kullanılıyorsa, temel tablo en fazla 1.024 sütun içerebilir, ancak en fazla 246 sütunun yayımlanması için makaledeki sütunlar filtrelenmelidir. Sütun izleme kullanılıyorsa, temel tablo en fazla 246 sütun içerebilir.

Çakışma türleri

Çakışmaların çoğu güncelleştirmelerle ilgili olsa da (bir düğümdeki bir güncelleştirme, bir güncelleştirme veya başka bir düğümdeki bir silme işlemiyle çakışıyor), başka çakışma türleri de var. Bu bölümde ele alınan her çakışma türü, karşıya yükleme aşamasında veya birleştirme işleminin indirme aşamasında gerçekleşebilir. Karşıya yükleme işleme, belirli bir birleştirme oturumunda gerçekleştirilen değişikliklerin ilk mutabakatıdır ve Birleştirme Aracısı'nın Aboneden Publisher'a kadar değişiklikleri çoğaltma aşamasıdır. Bu işlem sırasında algılanan çakışmalar yükleme çakışmaları olarak adlandırılır. İndirme işlemi, değişiklikleri Yayımcıdan Aboneye taşımayı içerir ve karşıya yükleme işleminden sonra gerçekleşir. İşlemenin bu aşamasındaki çakışmalar indirme çakışmaları olarak adlandırılır.

Çakışma türleri hakkında daha fazla bilgi için bkz. MSmerge_conflicts_info, özellikle conflict_type ve reason_code sütunları.

Güncelleme çakışmaları

Birleştirme Aracısı, bir düğümdeki bir satıra (veya sütuna veya mantıksal kayda) yapılan bir güncelleme, başka bir düğümdeki aynı satıra yapılan başka bir güncelleme ile çakıştığında güncelleme-güncelleme çakışmalarını algılar. Bu durumda varsayılan çözümleyicinin davranışı, satırın kazanan sürümünü kaybeden düğüme göndermek ve kaybeden satır sürümünü makale çakışma tablosuna kaydetmektir.

Güncelleştirme-silme çakışmaları

Birleştirme Aracısı, bir düğümdeki veri güncelleştirmesinin başka bir düğümdeki silme işlemiyle çakışması olduğunda güncelleştirme-silme çakışmalarını algılar. Bu durumda, Birleştirme Aracısı bir satırı güncelleştirir; ancak, Birleştirme Aracısı hedefte bu satırı ararken, silindiği için satırı bulamıyor. Kazanan, satırı güncelleştiren düğümse, kaybeden düğümdeki silme atılır ve Birleştirme Aracısı yeni güncelleştirilen satırı çakışma kaybedenine gönderir. Birleştirme Aracısı, satırın kayıp sürümü hakkındaki bilgileri tabloya MSmerge_conflicts_info kaydeder.

Başarısız değişikliklerden kaynaklanan çakışmalar

Birleştirme Aracısı belirli bir değişikliği uygulayamayınca bu çakışmaları tetikler. Bunun nedeni genellikle Yayımcı ile Abone arasındaki kısıtlama tanımlarındaki fark ve kısıtlamada (NFR) özelliğinin NOT FOR REPLICATION kullanılmasıdır. Örnekler şunları içerir:

  • Abone tarafı kısıtlaması NFR olarak işaretlenmediğinde ortaya çıkabilecek abonede yabancı anahtar çakışması.

  • Yayımcı ve Aboneler arasındaki kısıtlamalar arasındaki farklar ve kısıtlamalar NFR olarak işaretlenmez.

  • Abonede bağımlı nesnelerin kullanılamama durumu. Örneğin, bir görünümü yayımlarsanız ancak bu görünümün bağımlı olduğu tabloyu yayımlamazsanız, Abone'de bu görünümden eklemeye çalışırsanız bir hata oluşur.

  • Birincil anahtar ve yabancı anahtar kısıtlamalarıyla eşleşmeyen bir yayın için birleştirme filtreleme mantığı. SQL Server ilişkisel altyapısı bir kısıtlamayı yerine getirmeye çalıştığında ancak Birleştirme Aracısı makaleler arasındaki birleştirme filtresi tanımını kabul ettiğinde çakışmalar oluşabilir. Tablo düzeyindeki kısıtlamalar nedeniyle Birleştirme Aracısı, değişikliği hedef düğümde uygulayamaz ve bu da çakışmaya neden olur.

  • Benzersiz dizin veya benzersiz kısıtlama ihlalleri veya birincil anahtar ihlalleri nedeniyle çakışmalar, makale için kimlik sütunları tanımlandığında ve otomatik kimlik yönetimi kullanılmadıysa oluşabilir. İki Abonenin yeni eklenen bir satır için aynı kimlik değerini kullanması durumunda bu sorun olabilir. Kimlik aralığı yönetimi hakkında daha fazla bilgi için bkz Kimlik Sütunlarını Çoğaltma.

  • Birleştirme Aracısı'nın hedef tabloya satır eklemesini engelleyen tetikleyici mantığından kaynaklanan çakışmalar. Abonede tanımlanan bir güncelleştirme tetikleyicisini göz önünde bulundurun; tetikleyici NFR olarak işaretlenmez ve mantığının içine bir ROLLBACK içerir. Bir hata oluşursa, tetikleyici işlemin bir ROLLBACK kısmını gönderir ve bu da Birleştirme Aracısı'nın başarısız bir değişiklik çakışmasını algılamasını sağlar.

İlgili içerik

  • Last updated on