Transaktionsreplikation sendet nicht alle Befehle

Ich habe eine Transaktionsreplikationstopologie wie folgt:

NY Publication Database Der gleiche Server enthält den Distributor

NY - Abonnent
LON - Abonnent
HK - Abonnent

Wir verwenden die Einweg-Transaktionsreplikation nach Moorstandard. Alle Maschinen SQL 2008 R2

Der Snapshot wird problemlos auf alle Abonnenten angewendet und beginnt dann, wie erwartet, Befehle zu verteilen, aber nur an einen Abonnenten (London) bleiben eine ganze Reihe von 2000 bis 4 Millionen Befehlen einfach "hängen". Sie können die Befehle in msrepl_commands sehen, Sie können die Transaktionen in msrepl_transaction sehen. Der Replikationsmonitor zeigt an, dass xxxxx nicht zugestellte Befehle vorhanden sind. Alle Befehle werden ohne Probleme an die anderen 2 Teilnehmer übermittelt.

Das Problem ist, dass sie einfach dort bleiben. Der Replikationsmonitor sagt, dass nichts repliziert werden muss und nichts passiert. Sie bleiben einfach dort, wo sie sind. Der einzige Weg, den ich gefunden habe, ist es, das Abonnement abzureißen und neu zu initialisieren!?!

Ich bin mir bewusst, dass es zwischen NY und Lon Netzwerk-Blips gibt, und ich kann in msrepl_errors sehen, dass es einige Kommunikationsfehler gibt. Ich würde jedoch erwarten, dass die Replikation sie wieder aufnimmt. Der Distributionsagent läuft einwandfrei.

Wie komme ich um dieses Problem herum und zwinge SQL Server, diese Befehle aufzunehmen und bereitzustellen.

Untersuchen Sie die Ausgabe von sp_helpsubscriptionerrors. Ein Problem, das ich gesehen habe, ist mit DDL-Befehlen; Sie werden bei der Replikation unterschiedlich behandelt. Wenn also manuelle Schemaänderungen am Publisher vorgenommen werden, können sie manchmal fehlschlagen. Es kann auch vorkommen, dass bestimmte DML-Befehle auf dem Teilnehmer aufgrund von Transaktionsinkonsistenzen fehlschlagen. In diesem Fall können Sie das Distributionsagentenprofil "Continue On Data Consistency Errors" verwenden, bei dem doppelte Schlüssel und andere Fehler ignoriert werden.

Latenz kann das Problem verursachen (laut MS sind Latenz und Durchsatz die wichtigsten Faktoren bei der Transaktionsreplikation). Sie können das mit verfolgen sp_posttracertoken. Sowohl der Log Reader als auch der Distribution Agent verfügen über Parameter, die angepasst werden können, um dies auszugleichen. Versuchen Sie, diese Werte zu senken, insbesondere im Log Reader.

Distributionsagent (von MSDN ):

MaxDeliveredTransactions Ist die maximale Anzahl von Push- oder Pull-Transaktionen, die in einer Synchronisation auf Abonnenten angewendet werden. Ein Wert von 0 gibt an, dass das Maximum eine unendliche Anzahl von Transaktionen ist. Andere Werte können von Abonnenten verwendet werden, um die Dauer einer Synchronisierung zu verkürzen, die von einem Publisher abgerufen wird.

CommitBatchThreshold Gibt die Anzahl der Replikationsbefehle an, die an den Abonnenten ausgegeben werden sollen, bevor eine COMMIT-Anweisung ausgegeben wird. Der Standardwert ist 1000.

Log Reader Agent (von MSDN ):

MaxCmdsInTran Gibt die maximale Anzahl von Anweisungen an, die in einer Transaktion gruppiert sind, während der Protokollleser Befehle in die Verteilungsdatenbank schreibt. Mit diesem Parameter können der Log Reader Agent und der Distribution Agent große Transaktionen (bestehend aus vielen Befehlen) auf dem Publisher in mehrere kleinere Transaktionen aufteilen, wenn sie auf den Abonnenten angewendet werden. Durch die Angabe dieses Parameters können Konflikte auf dem Distributor und die Latenz zwischen Publisher und Subscriber verringert werden. Da die ursprüngliche Transaktion in kleineren Einheiten angewendet wird, kann der Abonnent vor dem Ende der ursprünglichen Transaktion auf Zeilen einer großen logischen Publisher-Transaktion zugreifen, wodurch die strikte Transaktionsatomarität verletzt wird. Der Standardwert ist 0, wodurch die Transaktionsgrenzen des Publishers erhalten bleiben.