Klarstellungen zu nodetool repair -pr

Question

Von der Dokumentation:

Die Verwendung der nodetool repair -pr (–partitioner-range) Option repariert nur den Primärbereich für diesen Knoten, die anderen Replikate für diesen Bereich müssen weiterhin die Merkle-Tree-Berechnung durchführen, was zu einer Validierungs-Kompaktierung führt. Da alle Replikate gleichzeitig kompaktieren, kann es sein, dass alle Knoten für diesen Teil der Daten langsam reagieren.

Es gibt wahrscheinlich niemals einen Zeitpunkt, an dem ich akzeptieren kann, dass alle Knoten für einen bestimmten Teil der Daten langsam sind. Aber ich frage mich: Warum passiert das (oder gibt es vielleicht einfach eine Verwechslung mit der "-par" Option in der Dokumentation?!), wenn nodetool repair anscheinend klüger ist:

Standardmäßig erstellt der Reparatur-Befehl sofort einen Snapshot von jedem Replikat und repariert dann sequenziell jedes Replikat aus den Snapshots. Zum Beispiel, wenn Sie RF=3 haben und A, B und C drei Replikate repräsentieren, erstellt dieser Befehl sofort einen Snapshot von jedem Replikat und repariert dann sequenziell jedes Replikat aus den Snapshots (A<->B, A<->C, B<->C) anstatt A, B und C gleichzeitig zu reparieren. Dies ermöglicht dem dynamischen Snitch, die Leistung für Ihre Anwendung über die anderen Replikate aufrechtzuerhalten, weil mindestens ein Replikat im Snapshot nicht repariert wird.

Der Datastax Blog geht jedoch auf dieses Problem ein:

Die erste Phase kann jedoch intensiv auf die Festplatten-E/A sein. Sie können dies in gewissem Maße mit Kompaktierungsdrosselung abmildern (da diese Phase das ist, was wir eine Validierungs-Kompaktierung nennen). Manchmal reicht das jedoch nicht aus, und einige Leute versuchen, dies weiter zu mildern, indem sie die -pr (–partitioner-range) Option für nodetool repair verwenden, die nur den Primärbereich für diesen Knoten repariert. Leider müssen die anderen Replikate für diesen Bereich weiterhin die Merkle-Tree-Berechnung durchführen, was zu einer Validierungs-Kompaktierung führt. Dies kann ein Problem sein, da alle Replikate dies gleichzeitig durchführen, was sie alle langsam machen kann, um für diesen Teil Ihrer Daten zu antworten. Glücklicherweise gibt es hiermit umzugehen, indem Sie die -snapshot Option verwenden.

Das könnte nett sein, aber tatsächlich gibt es keine -snapshot Option für nodetool repair (siehe die manpage oder die Dokumentation) (wurde diese Option entfernt?!)

Insgesamt also:

• Ich kann anscheinend nodetool repair -pr nicht verwenden, da ich immer mindestens sicherstellen muss, dass das System reaktionsschnell genug ist, um mit einer Konsistenz von EINS zu lesen/schreiben, ohne wesentliche Verzögerung. (Anmerkung: Wir haben nur ein Rechenzentrum.) Oder übersehe/verstehe ich etwas?
• Warum ist nodetool repair klug, indem es einen Knoten reaktionsschnell hält, während nodetool repair -pr alle Knoten für einen Teil der Daten langsam macht?
• Wo ist die -snapshot Option: Wurde sie entfernt, nie implementiert oder funktioniert sie jetzt vielleicht automatisch so, auch wenn nodetool repair -pr verwendet wird?

Answer 1

Der unten stehende Blog behandelt diese Themen:

http://www.datastax.com/dev/blog/repair-in-cassandra

Ein einfaches nodetool repair startet nicht nur eine Reparatur am Knoten selbst, sondern auch an allen Knoten, die Repliken seiner Bereiche halten. Obwohl dies in Ordnung ist, ist es sehr teuer und in der Regel keine Operation, die Sie während der Stoßzeiten auf einem geschäftigen Produktionssystem durchführen werden.

Folglich wird nodetool repair -pr eine Reparatur der primären Bereiche auf diesem Knoten durchführen. Wie im Blog erwähnt, müssen Sie dies auf jedem Knoten des Clusters ausführen. Kunden mit großen Produktionssystemen werden dies in der Regel nacheinander über ihren Cluster ausführen.

Ein weiterer Hinweis: Datastax OpsCenter bietet den Reparaturdienst an, der kontinuierlich kleinere Teilbereichsreparaturen durchführt, sodass, obwohl Sie ständig reparieren, dies kontinuierlich im Hintergrund auf einem geringeren Ressourcenlevel stattfindet.

Was die Snapshots betrifft, bei einer regelmäßigen Reparatur wird wie von Ihnen erwähnt ein Snapshot ausgelöst, Sie können aber auch selbst einen Snapshot auslösen mit nodetool snapshot

Hoffe, das hilft!