Zeitplan lesen Reparatur vor lesen

Ich habe ein Reporting-Tool, das Daten von Cassandra liest. Konfigurationen sind Consistency Level ist LOCAL_QUORUM, Compaction Strategie ist Größe abgestuft und RF = 3.Zeitplan lesen Reparatur vor lesen

Wenn die Pull-Anforderung von Reporting-Tool zu Cassandra, nach dem Cassandra-Design, es Lese Reparatur für die Datenkonsistenz auslösen. Das ist eigentlich ein gutes Design. Aber lesen Reparatur ist teuer und Berichte benötigen längere Zeit.

Meine Berichtsbenutzer beginnen erst nach 6:00 Uhr mit dem Generieren von Berichten. Es gibt eine Möglichkeit, Lesereparaturen zu planen, bevor Benutzer Berichte verwenden. zum Beispiel plane ich und lese Reparaturen vor 6 Uhr morgens fertig. Damit wären nach 6 Uhr alle Daten über den Cluster verteilt.

In diesem Fall sollte der Bericht nach dem Lesen der Daten von Cassandra die Lese-Reparatur nicht mehr auslösen, da wir gerade die Lese-Reparatur als geplanten Job beendet haben. Mir geht es gut mit inkonsistenten Daten schreiben/Updates nach 6 Uhr IST passiert ist. Welche Technik ist gut, um Lesereparaturen zu planen, und vermeiden wir wirklich Lesereparaturen, wenn sie kürzlich durchgeführt wurden? -Suyodha

Quelle

2016-07-31 Madhu Mohan Kommu

Wenn Sie traditionelle Anti-Entropie-Reparatur verwenden, könnten Sie dann auf Konsistenzebene lesen: ONE.

Es gibt viele Möglichkeiten, Anti-Entropie Reparatur zu tun, die naheliegendste ist nodetool repair (wahrscheinlich mit nodetool repair -par -inc oder ähnlichen Befehlszeilenoptionen) oder einige der Tools von Drittanbietern verwenden, um kleine Bereiche, wie das Cassandra Range Repair Werkzeug zu reparieren beibehalten von Brian Gallew oder Spotify's Cassandra Reaper.

Quelle

2016-07-31 02:29:05

Hallo Chris und Jeff..Based auf Ihre Eingaben Lese Reparaturen an einem Tisch deaktivieren können ... Ich habe meine Frage beantwortet habe. Danke Jungs. –

Was lässt Sie glauben, dass Lesereparaturen das verlangsamen? Überprüfen Sie (jmx) org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBackground und org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking, um zu überprüfen, ob Reparaturen überhaupt auftreten. Lesereparaturen werden nur ausgelöst, wenn die Daten beim Lesen nicht übereinstimmen, was nicht üblich sein sollte.

Wenn es ist wirklich ein Problem, das Sie Chance auf 0, indem

ALTER TABLE yourtable WITH read_repair_chance = 0;

Quelle

2016-07-31 03:48:32

Hallo Chris und Jeff, vielen Dank für den Blick darauf. Ich werde so bald wie möglich zu euch zurückkommen. Danke vielmals. –

Das Deaktivieren der Lesereparatur mit ALTER TABLE schützt nur vor Hintergrundlese-Reparatur, die nicht blockiert ist. Vordergrundlesereparatur kann nur durch Verwendung einer niedrigeren Konsistenzstufe deaktiviert werden. –

Das ist wahr, Sie brauchen sowohl CL.ONE als auch 'read_repair_chance = 0', um sowohl Blockierungen als auch Hintergrundlesereparaturen zu verhindern. Nur das eine zu tun, würde immer noch andere passieren lassen. Ich denke, es ist immer noch ziemlich wahrscheinlich, dass dies nicht der wahre Grund dafür ist, dass die Berichte lange brauchen –

Antwort

Verwandte Themen