Peer-Replikation in SQL Server 2005/08-to-Peer

Question

Hat jemand Erfahrung hatte Peer-Replikation-to-Peer Verwendung von SQL Server 2005 oder 2008?

Insbesondere, ich bin daran interessiert, ob andere Optionen / Alternativen wo betrachtet und warum P2P-Replikation schließlich gewählt wurde.

Wenn Sie verwendet haben P2P-Replikation:

Haben Sie während der Synchronisation keine Probleme auftreten, und wurde es einfach zu überwachen?

Wie einfach war / ist es Konfliktlösung zu tun?

Müssen Sie Schemaänderungen vornehmen (d ersetzen Identitätsspalten, usw.)?

Alternativ, wenn Sie P2P-Replikation betrachtet und gingen mit einer anderen Option, warum hast du es ausschließen?

Answer 1

(Disclaimer: Ich bin ein Entwickler, kein DBA)

Wir SQL Server 2005 Mergereplikation eingerichtet haben, zwischen zwei Aktiv / Aktiv-geographisch getrennten Knoten für Elastizität in einem Altsystem zu replizieren.

Ich weiß nicht, ob es ist leicht zu überwachen; außerhalb meiner Zuständigkeit.

Es schafft Trigger auf jedem Tisch die Publish / Subscribe-Mechanismus zu tun, von denen jeder seine eigene gespeicherte Prozedur aufruft.

In unserem Fall war es einrichten Identitäten verwenden 1-1bn in Knoten 0, 1 Mrd-2 Mrd. in Knoten 1 Identität Kollisionen zu vermeiden (und nicht zu verwenden, um einen zusammengesetzten Schlüssel von NodeId + EntityID für jede Tabelle oder Tasten ändern sein GUIDs, zum Beispiel).

Ich denke, die Replikationslatenz um 15s (zwischen London und New York über eine dedizierte Bandbreite).

Es ist ein großer Schmerz mit zu arbeiten:

• Es dauerte eine sehr jährlich gezahlt Auftragnehmer es einzurichten (gewährt, ein Teil davon war aufgrund der Legacy-Natur des DB-Design)
• Es fehlt jemand im Haus mit dem Know-how zu unterstützen (die in-house DBA wir ca. 6 Monate gedauert hatte, es zu lernen, und da auf bewegt hat)
• Schema-Updates sind jetzt painful . Von dem, was ich verstehe:
  • Bestimmte Updates müssen nur auf einem Knoten ausgeführt werden; Replikation dann kümmert sich um herauszufinden, was auf dem anderen Knoten zu tun (n)
  • Bestimmte Updates müssen auf beiden Knoten durchgeführt werden
  • Daten-Updates müssen auf einem Knoten ausgeführt werden, nur (glaube ich)
  • Alle Updates nehmen jetzt deutlich auszuführen mehr - aus dem Bruchteil einer Sekunde dauert es einen DDL Wechsel Skript ausführen zu ~ 30 Minuten
• Ich weiß nicht sicher, aber ich denke, dass der Bandbreitenbedarf für die Replikation sehr hoch ist (in der MBit / s-Bereich)
• Sie führt viele „Rauschen“ Objekte (3 sprocs pro Tisch, 3 Trigger pro Tabelle) in die DB, so dass es unbequem das Element im Objekt-Explorer zu finden, die man will, arbeiten.
• Wir werden nie einen dritten Knoten für dieses System aufgebaut, basiert weitgehend auf die empfundene Schwierigkeit und fügte hinzu, Schmerz es bei der Bereitstellung Zeit einführen würde.
• Es fehlt auch jetzt eine Staging-Umgebung, die Produktion widerspiegelt, weil es zu schmerzhaft ist einzurichten.
• Anekdotische. Der DBA das Setup häufig die Tatsache verfluchen würde tun, dass es ein „MS v1“ war er gezwungen wurde, mit zu arbeiten
• Undeutlich erinnert. Die DBA benötigten mehr Priorität Support-Tickets zu erhöhen direkt Hilfe von MS zu bekommen

Zugegeben - einige der Schmerzen beteiligt ist aufgrund unserer spezifischen Umgebung und nicht in-house mit Talent dieses Setup zu unterstützen. Ihre Ergebnisse können variieren.