Historische Partitionen fallen, die in der P2P-Replikation nicht mehr benötigt werden

Question

Die Firma, für die ich arbeite, hat eine Reihe von Datenbanken (größte knapp unter 1 TB) auf verschiedenen Servern - 2 in den USA, 2 in Europa.

Wir führen die vollständige Peer-to-Peer-Replikation pro Datenbank zwischen den 4 Knoten aus - so können sie alle Transaktionen (Einfügen / Aktualisieren / Löschen) annehmen, und alle haben die Daten, die die anderen Knoten gesammelt haben (innerhalb einer variablen Latenzzeit) Die Verbindung ist im Durchschnitt etwa 30-40 Sekunden).

Die größte Datenbank trägt Daten von Anfang 2008 bis heute. Alle diese Daten werden weiter auf Berichterstattungsknoten repliziert, die alle Daten halten.

Ich muss Daten an den Transaktionsknoten bis 2013 entfernen, um das Antriebsraumdefizit an den Transaktionsknoten zu entfernen, und daher sind historische Daten nur in den Berichtsknoten verfügbar.

Was ist der beste Weg, dies zu tun? Daten sind relativ überschaubar, da sie (monatlich - per Partition, und dann jährlich in separate Dateien / FileGroups) partitioniert ist. Es besteht jedoch das Problem, nicht in der Lage zu sein, die Trennwände nicht abzulegen, während sie an der Replikation beteiligt sind, und das Ablegen der Partitionsumschaltung - dies ist auch nicht zulässig. ( Umschalten von Partitionen Voraussetzungen - Punkt 18 )

Als volle Produktionsumgebung versuche ich, alles zu vermeiden, was die Replikation beeinträchtigt - einschließlich Resynchronisation (viele Daten an ReSync, über große Entfernungen).

Hat jemand gute Anregungen, wie Sie diese Aufgabe ausführen können?

Answer 1

Also, keine Antworten von hier, aber nach einer gewissen Menge an Diskussionen und Gedanken habe ich vor einigen Monaten einen Plan gemacht.

Ich werde diese Antwort in Concis für dieses Forum machen (Sie stimmen möglicherweise nicht zu, dass ich habe!), um zu versuchen, jemanden zu unterstützen, der in Zukunft eine ähnliche Aufgabe ausführen muss, um Fragen zu stellen, wenn ich alles vermisse - Obwohl die Methode unmittelbar nach unten ist.

Das Hauptanliegen besteht darin, die Daten ohne erhebliche Auswirkungen auf den Produktionsverkehr an den Knoten zu entfernen, die wir auf / von replizieren. Der einfachste Weg, dies zu tun, besteht darin, einen Knoten zu trennen, an dem Sie arbeiten möchten, und das Entfernen der Daten aus diesem Knoten, während alle anderen nicht betroffen sind (einschließlich der Berichtsknoten).

Beste Möglichkeit, dies zu tun (Denken Sie daran, dass Sie keine Partitionen fallen können, und alle meisten Operationen werden repliziert und erstellen daher einen großen Datenverkehr und eine große Menge an Zeilenänderungen), ist, ein neues SP zu erstellen und eine Publikation zu erstellen um diesen eins sp. Es sollte daher in allen Knoten verfügbar sein. Das wichtige Bit besteht darin, die Replikation einzustellen, um die Ausführung des SP zu replizieren - nicht das Ergebnis (d. H. Replizieren Sie den EXEC-SP_DELETE-Anruf nicht den Löschen, an dem id= 1 löschen, wobei ändert, an dem id= 2-Zeilen-Level ändert). Klicken Sie mit der rechten Maustaste auf Ihre neue Publikation (vor der Einrichtung der anderen Knoten in der TOPOLOGIE)> Eigenschaften> Artikel> Klicken Sie auf SP_DELETE Sie haben eingerichtet> Artikel-Eigenschaften-Taste> Eigenschaften der hervorgehobenen gespeicherten Prozedur-Artikel> Replikationszeile= Ausführung der gespeicherte Prozedur. Vervollständige deine P2P-Topologie.

Aber Mhsqldba, Sie können sagen, dass nur die Zeilen an jedem Knoten über die SP separat löschen. - Deshalb setzen Sie den SP auf, um nur die Deletionen zu tun:

wenn @@ serverName= 'der aktuelle Server, den Sie beeinflussen möchten "

Folgen Sie ihm mit Ihrem Löschvorgang.

Wenn dieser EXEC-Anruf an den Server abgeholt wird, dass Sie die Löschungen nicht ausführen möchten, wird es ignoriert, wenn @@ Servername den von Ihnen ausgewählten Server nicht gleich ist.

Sie denken vielleicht -, warum nicht nur ein SP auf dem Server erstellen, an dem Sie interessiert sind, und das? - Dies ist, wenn Sie dies tun, die Replikation die Änderungen in der Auswirkungen auf die Auswirkungen auf die Artikel (Tabelle) auswirken und die tatsächlichen Änderungen replizieren - Sie müssen den SP replizieren, so dass Sie angeben können, dass die Exec of the SP repliziert wird anstatt die resultierenden Änderungen.

Dies ist die vorgeschlagene Reihenfolge der Ereignisse meiner Meinung nach:

.
1. Erstellen Sie sp mit Löschen von Code, der angibt, dass er nur den Löschcode ausführt, wenn @@ Servername= Ihr gewünschter Server
2. Einrichten einer neuen Veröffentlichung, die diesen 1 SP mit der Replikation= Ausführung der gespeicherten Prozedur innerhalb der Artikeleigenschaften
repliziert
3. Führen Sie den SP auf Ihrem gewünschten Server aus und freuen Sie sich, dass Sie das gesamte Anwesen nicht mit Tausenden replizierter Löschbefehle zurückgebracht haben

Hinweispunkte:

.
1. Das ist immer noch eine mühsame Aufgabe. Durch die Verwendung dieser Methode haben Sie Ihren Effekt auf alle Server abgesehen von dem, an dem Sie arbeiten. Sie haben die Arbeitslast für Sie nicht verringert, tatsächlich haben Sie es schlimmer gemacht - Sie müssen das gleiche SP an jedem Knoten ausführen (mit der IF-Zeile, die auf den von Ihnen geänderten Server geändert wird), wodurch die Arbeit effektiv erhöht wird zu tun, durch die Anzahl der Server, die Sie beeinflussen müssen. Es ist massiv sicherer, da Sie auf alle anderen Knoten minimalen Effekt haben (ich vermutete, dass Sie den Datenverkehr vom Knoten fehlgeschlagen, an dem Sie natürlich arbeiten!)
2. Durch die Verwendung dieser Methode haben Sie Inkonsistenz zwischen Ihren Knoten geschaffen - Sie müssen wirklich sicher sein, dass die Daten, die Sie entfernen, nicht ändern, bevor Sie denselben Vorgang in allen Knoten, die Arbeit erfordern, ausführen können. Wenn eine Zeile, die Sie bei 1 Knoten gelöscht haben, innerhalb des Rests des Anwesens geändert wird, enden Sie mit den Konsistenzfehlern.
3. Sie werden wahrscheinlich Ihre normale Replikation erwartet, um die SLAs hinter sich zu hinterlassen, um die Löschungen am Knoten zu erfüllen Um sich dessen bewusst zu sein, dass Sie, sobald der Betrieb abgeschlossen ist, nicht den Knoten in Aktion wieder in Aktion haben, bis die normale Replikation nach dem Löschen der Löschvorgänge freigegeben hat. Wenn Sie über hohe Latenzlinien replizieren, empfehle ich Ihnen ernsthaft, Sie prüfen Sie mit Pull Agents anstelle von Push - es macht einen harmonischen Unterschied.

Es gibt wahrscheinlich eine bessere Art, die Daten in der SP zu verschieben, als die Verwendung von Löschen - vielleicht in eine andere Tabelle verschieben, die nicht an der Replikation beteiligt ist, und dann die "Neue" Tabelle - oder umgekehrt ablegen, wenn die Daten Sie verwenden Möchten Sie behalten, ist weniger als der zu löschen Es war einfacher, für den Lösch zu kämpfen, als ein Konzept zu fördern

Einige Personal verstehen nicht, also beschreibe ich den schmerzhaften, aber grundlegenden Weg.

Haftungsausschluss: Alle oben genannten sind gefährlich.Wenn Sie eilig ohne angemessene Voraussetzung gemacht haben, können Sie ernsthaft eine Replikationstopologie, die Daten Ihres Unternehmens und wahrscheinlich Ihre Beschäftigung erheben.Bitte nehmen Sie die obige Methode und entwickeln Sie Ihren eigenen BattlePlan - erstellen Sie eine Testumgebung, um das Konzept, den Testtest und den Retest zu beweisen, nehmen Sie diese Aufgabe nicht leicht.Mit genügend Überlegung erreichen Sie Ihre Aufgabe - aber es lohnt sich am Freitagnachmittag nach ein paar Mittagsbier nicht.Mach es richtig, mach es einmal (für echte Test so viel wie möglich), mach es ordnungsgemäß.

Ich hoffe, das hilft jemand anderem.- Ich füge dieses Bit hinzu, da ich gesucht hätte, wenn ich diese Antwort wollte:

löschen große Datenmenge aus einer Peer-to-Peer-Replikationstopologie