Udostępnij za pośrednictwem

Replikacja scalania nie obsługuje topologii z scentralizowanymi subskrybentami

Ten artykuł pomaga obejść problem polegający na tym, że replikacja scalania nie obsługuje scentralizowanych topologii subskrybentów.

Oryginalna wersja produktu: SQL Server 2012, SQL Server 2008, SQL Server 2005
Oryginalny numer KB: 2750005

Podsumowanie

Replikacja scalania nie obsługuje scentralizowanych topologii subskrybentów. Pojedyncza baza danych subskrybenta scalania może subskrybować tylko jedną publikację typu scalenie. W związku z tym żadna scentralizowana topologia subskrybenta nie jest obsługiwana w replikacji scalania.

Uwaga / Notatka

To ograniczenie dotyczy wszystkich aktualnie obsługiwanych wersji programu SQL Server, ale nie dotyczy subskrybentów programu Microsoft SQL Server Compact.

Rozwiązanie

Aby obejść ten problem, rozważ następujące alternatywy dotyczące używania centralnej topologii subskrybenta i replikacji scalania:

  • Zaimplementuj pojedynczą centralną publikację scalającą, która ma sparametryzowane filtry wierszy, w których partycje danych zapewniają dane dla poszczególnych baz danych subskrybentów.
  • Użyj replikacji transakcyjnej zamiast replikacji scalania w celu zaimplementowania centralnej topologii subskrybenta

Uwaga / Notatka

Aby uzyskać więcej informacji na temat implementowania topologii centralnych subskrybentów i integrowania danych z wielu witryn, zobacz sekcję Odwołania.

Więcej informacji

W modelu subskrybenta centralnego baza danych subskrybentów synchronizuje się z co najmniej dwoma źródłami publikowania. W tym scenariuszu źródła publikowania składają się z jednej z następujących kombinacji:

  • Co najmniej dwie publikacje wewnątrz tej samej bazy danych wydawcy w tym samym wystąpieniu serwera publikowania.
  • Co najmniej dwie publikacje w co najmniej dwóch bazach danych wydawców w tym samym wystąpieniu serwera publikowania.
  • Co najmniej dwie publikacje w co najmniej dwóch bazach danych wydawców w różnych wystąpieniach serwera publikowania.

Replikacja scalania nie obsługuje centralnego modelu subskrybenta. Agenci scalania nie zostali zaprojektowani ani przetestowani do pracy w tym scenariuszu. Jedyną obsługiwaną topologią jest topologia, w której każda baza danych subskrybentów synchronizuje się z pojedynczą publikacją scalaną. Rozważ następujące kwestie:

Uwaga / Notatka

Dotyczy to wszystkich wersji programu Microsoft SQL Server.

  • Scalanie metadanych replikacji bazy danych subskrybentów jest przechowywane w jednym zestawie tabel metadanych. Jeśli kilka subskrypcji zostanie utworzonych w tej samej bazie danych, metadane wszystkich subskrypcji będą przechowywane w tym samym zestawie tabel systemowych.
  • Metadane replikacji są współużytkowane przez wielu agentów scalania.
  • Scalanie agentów synchronizuje informacje o publikacji i subskrypcji między skonfigurowanymi partnerami synchronizacji. W związku z tym każda synchronizacja przekazuje również niepowiązane metadane z bazy danych subskrybentów do bazy danych wydawcy. Następnie dodatkowe synchronizacje dystrybuują te metadane do innych niepowiązanych węzłów w topologii.
  • Gdy agenci scalania synchronizują swoje subskrypcje w tym samym czasie równolegle. interakcja między agentami scalania może mieć wpływ na sposób obsługi zmian. Na przykład może mieć wpływ na grupowanie generacji w partiach w poszczególnych fazach przekazywania każdej synchronizacji.

W przypadku zaimplementowania centralnego modelu subskrybenta scalania mogą wystąpić problemy. Przykłady problemów, które mogą wystąpić podczas implementowania centralnego modelu subskrybenta scalania, obejmują następujące elementy:

  • Spójność metadanych replikacji scalania jest naruszona po usunięciu publikacji, a następnie ponownie utworzona na tym samym serwerze wydawcy i bazie danych o tej samej nazwie. W tym scenariuszu agenci scalania mogą nie być synchronizowani później. Na przykład może zostać wyświetlony co najmniej jeden z następujących komunikatów o błędach:

    • Nie można wstawić zduplikowanego wiersza klucza w obiekcie dbo.sysmergepartitioninfo z unikatowym indeksem uc1sysmergepartitioninfo.

    • Ta publikacja różni się od publikacji, do której początkowo utworzono subskrypcję. Oryginalna publikacja mogła zostać usunięta i zastąpiona nową publikacją o tej samej nazwie. Na subskrybentu usuń subskrypcję i utwórz ją ponownie dla nowej publikacji.

    • Proces scalania wykrył niezgodność podczas oceniania wyrażenia weryfikacji partycji subskrybenta. Problem można rozwiązać przez ponowne inicjowanie subskrypcji.

    • Nie można pobrać informacji o subskrypcji dla subskrybenta z "Wydawcy". Subskrypcja publikacji "publikacja" jest nieprawidłowa lub nie została poprawnie skonfigurowana.

  • Spójność metadanych replikacji scalania może zostać naruszona po usunięciu subskrypcji, a następnie ponownie utworzona w centralnej bazie danych subskrybentów.

  • Spójność metadanych replikacji scalania może zostać naruszona, jeśli subskrypcje w centralnej bazie danych subskrybentów są skonfigurowane do używania różnych wartości dla ich sparametryzowanych filtrów wierszy. Obejmuje to użycie różnych wartości parametru host_name w różnych subskrypcjach. Ponadto podejrzewamy, że mieszanie filtrów na podstawie host_name i suser_sname przyczynia się do tego problemu.

  • Nieoczekiwane konflikty podczas rozwiązywania konfliktów mogą spowodować potencjalną utratę danych. Ten problem może wystąpić, gdy agenci scalania są uruchamiani równolegle w centralnym subskrybentu.

  • Rozległe blokowanie występuje w przypadku równoległego uruchamiania agentów scalania. Ten problem może wystąpić podczas rozpoczęcia fazy przekazywania lub pobierania synchronizacji. Ten problem może również wystąpić, gdy dane zmiany są odczytywane lub zapisywane. Ten problem z wydajnością może być kaskadowy w topologii, w zależności od obiektów, które są zaangażowane w blokowanie.

Uwaga / Notatka

Te problemy mogą nie wystąpić natychmiast po skonfigurowaniu lub zmianie topologii. Te problemy mogą wystąpić nieoczekiwanie i sporadycznie później. Zakres problemów może zależeć od czasu zdarzeń. Na przykład w przypadku synchronizacji poszczególnych agentów scalania w odniesieniu do siebie, ważność problemu może mieć wpływ na zdarzenie powodujące problem oraz ilość danych przekazanych lub pobranych.

Źródła