Erstellen neue Tabelle mit cqlsh auf bestehende Schlüsselraum: Column family ID mismatch

Kurze Antwort: Sie haben eine race-condition, die Sie denken, dass Sie gelöst in 1.1.8...

Lange Antwort:

Bekomme ich diesen Fehler die ganze Zeit auf einem meiner Cluster. Ich habe test-Maschinen, die wirklich langsamen Festplatten und erstellen einer oder zwei Tabellen genug, um die Fehler, wenn ich 4 Knoten auf zwei verschiedenen Computern.

Unten habe ich eine Kopie der stack-trace von meiner Cassandra 3.7 installation. Obwohl Ihre version wurde 2.1.3, ich würde überrascht sein, dass dieser Teil des Codes viel verändert.

Als wir sehen können, ist die Ausnahme passiert in der validateCompatibility() Funktion. Dies erfordert, dass die neuen und alten Versionen der Metadaten haben diese gleich:

• ksName (Schlüsselraum name)
• cfName (columnfamily name)
• cfId (columnfamily UUID)
• flags (isSuper, isCounter, isDense, isCompound)
• Komparator (key-Sortierung Komparator)

Wenn diese Werte nicht übereinstimmen zwischen der alten und der neuen meta-Daten, dann wird der Prozess wirft eine exception. In unserem Fall, die cfId Werte unterschiedlich sind.

Hinauf auf den stack, wir haben die apply() fordert validateCompatibility() sofort.

Als Nächstes haben wir updateTable(). Ebenso ruft es apply() fast sofort. Zuerst ruft er die getCFMetaData() zum abrufen der aktuellen Spalte Familie Daten ("alt") ist im Vergleich gegen den neuen Daten.

Als Nächstes sehen wir updateKeyspace(). Diese Funktion berechnet eine diff zu wissen, was sich geändert hat. Dann spart es, dass in jede Art von Daten. Tabelle 2. nach der Art...

Vor, dass Sie die mergeSchema() berechnet, was geändert an der Schlüsselraum Ebene. Es fällt dann schlüsselräume, die gelöscht wurden, und generieren neue schlüsselräume für diejenigen, die aktualisiert wurden (und für neue schlüsselräume). Schließlich, Sie Schleife über die neue schlüsselräume aufrufen updateKeyspace() für jeden von Ihnen.

Nächsten im Stapel sehen wir eine interessante Funktion: mergeSchemaAndAnnounceVersion(). Dies wird aktualisieren Sie die version, sobald die schlüsselräume aktualisiert wurden, im Speicher und auf der Festplatte. Die version des Schemas enthält, die cfID nicht kompatibel ist und somit erzeugt die Ausnahme. Die Announce Teil ist das senden einer gossip-Nachricht zu dem anderen Knoten über die Tatsache, dass dieser Knoten kennt nun die neue version von einem bestimmten schema.

Als Nächstes sehen wir etwas, genannt MigrationTask. Dies ist die Botschaft verwendet, zum migrieren von änderungen zwischen Cassandra-Knoten. Der message-payload ist eine Sammlung von Mutationen (diese werden von der mergeSchema() Funktion.)

Den rest der stack zeigt nur run() Funktionen, die verschiedene Arten von Funktionen verwendet, um Nachrichten zu behandeln.

In meinem Fall, bei mir ist das problem aufgelöst wird und ein wenig später, und alles ist gut. Ich habe nichts zu tun für das schema, um endlich wieder in sync. wie erwartet. Aber es hindert mich, die schaffen alle meine Tabellen in einem Rutsch. So, mein nehmen an dieser Suche ist, dass die migration die Nachrichten kommen nicht in der erwarteten Reihenfolge. Es muss ein timeout, das erfolgt durch erneutes senden des Ereignisses und erzeugt, dass der mix-up.

So, lassen Sie uns den code, der das senden der Nachricht in den ersten Platz, Sie sehen, dass einer in der MigrationManager. Hier haben wir eine MIGRATION_DELAY_IN_MS parameter in Verbindung mit einem alten Problem, Schema push/pull-Rennen, das war zu vermeiden, eine race-condition. Naja... da gehen Sie. So sind Sie sich bewusst, dass eine mögliche race-condition und zu versuchen, es zu vermeiden, Sie fügte hinzu, ein wenig Verzögerung gibt. Ein Teil dieses Update enthält eine version überprüfen. Wenn die Versionen bereits gleich sind, vermeiden Sie das update insgesamt (D. H. ignorieren, Klatsch).

if (Schema.instance.getVersion().equals(currentVersion))
{
    logger.debug("not submitting migration task for {} because our versions match", endpoint);
    return;
}

Die Verzögerung, die wir sprechen, ist eine minute:

public static final int MIGRATION_DELAY_IN_MS = 60000;

Man würde denken, dass eine ganze minute würde ausreichen, aber irgendwie habe ich immer noch den Fehler die ganze Zeit.

Tatsache ist, dass Ihr code nicht erwarten, dass mehrere Veränderungen, die da eine nach der anderen, darunter große Verzögerungen, wie ich Sie habe. Wenn ich also zum erstellen einer Tabelle, und dann andere Dinge tun, ich würde in Ordnung sein. Auf der anderen Seite, wenn ich will 20 Tabellen in eine Zeile auf die langsame Maschinen, die Klatsch-Nachricht von einem früheren schema-änderung kommt zu spät (d.h. nach dem neuen CREATE-TABLE-Befehl kam zu diesem Knoten). Das ist, wenn bekomme ich diesen Fehler. Das Schlimmste, denke ich, ist, dass es ist ein falscher Fehler (d.h. es sagt mir, dass die Gerüchte, die später war, und nicht, dass mein schema ist ungültig und das schema in der gossip-Nachricht ist ein alten.)

org.apache.cassandra.exceptions.ConfigurationException: Column family ID mismatch (found 122a2d20-9e13-11e6-b830-55bace508971; expected 1213bef0-9e
    at org.apache.cassandra.config.CFMetaData.validateCompatibility(CFMetaData.java:790) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.config.CFMetaData.apply(CFMetaData.java:750) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.config.Schema.updateTable(Schema.java:661) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.schema.SchemaKeyspace.updateKeyspace(SchemaKeyspace.java:1350) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1306) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53) [apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) [apache-cassandra-3.9.jar:3.9]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_111]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_111]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_111]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_111]
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]