Cassandra Knoten können nicht miteinander kommunizieren, führen Readtimeout

Question

Dies ist auf DataStax Cassandra (dse) Version: 4.8.5-1
Dies entspricht (glaube ich) zu Cassandra: 2.1.x

Ich erhalte viele der folgenden Fehler, wenn sie von unserer Anwendung abfragt:

ReadTimeout: code=1200 [Coordinator node timed out waiting for replica nodes' responses] message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'data_retrieved': False, 'required_responses': 1, 'consistency': 1}

Graben in diese mehr; Eine Beispielabfrage (die mit cqlsh lokal auf jedem Knoten ausgeführt wird) wird auf 3 der Knoten im Ring zurückgegeben, schlägt jedoch mit einem ReadTimeout auf dem Rest fehl. Es scheint, als ob nur die Knoten, die die Replikate enthalten, mit einer Antwort zurückkehren, während der Rest nicht weiß, wie sie überhaupt zu finden sind.

Gibt es eine Konfiguration oder ein bekanntes Problem, das ich untersuchen sollte, um dieses Problem zu beheben?

Wenn die anderen Knoten fehlschlagen, sehe ich diesen Fehler in den Protokollen:

ERROR [MessagingService-Outgoing-/10.0.10.14] 2016-04-25 20:46:46,818 CassandraDaemon.java:229 - Exception in thread Thread[MessagingService-Outgoing-/10.0.10.14,5, 
main] 
java.lang.AssertionError: 371205 
     at org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:393) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:382) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:271) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:259) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:503) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:490) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.SliceFromReadCommandSerializer.serialize(SliceFromReadCommand.java:168) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:143) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:132) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:121) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:330) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:282) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 
     at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:218) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131] 

Nodetool Statusausgang

Datacenter: primary 
======================= 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address  Load  Tokens Owns Host ID        Rack 
UN 10.0.10.224 557.95 GB 1  ?  d1b984b0-50d4-4faa-b349-08bc0cf36447 RAC1 
UN 10.0.10.225 740.11 GB 1  ?  16ab3c8c-476e-46c2-837c-6dbb89b7d40d RAC1 
UN 10.0.10.12 748.23 GB 1  ?  4127f0d7-6bd0-4dc8-b6a0-3b261e55b44e RAC1 
UN 10.0.10.45 629.27 GB 1  ?  f4499c5d-f892-43b8-97f3-dcce5be51fb8 RAC2 
UN 10.0.10.13 592.57 GB 1  ?  41b58044-942d-4e77-a8de-95495b88a073 RAC1 
UN 10.0.10.14 616.45 GB 1  ?  d2b568fb-13e1-4ff7-a247-3751a8ca49cf RAC1 
UN 10.0.10.15 623.23 GB 1  ?  fb10e521-8359-409b-bfd8-b27829157a80 RAC1 
UN 10.0.10.21 538.56 GB 1  ?  72288b4c-bd1d-4398-9d95-5af312c2f904 RAC2 
UN 10.0.10.25 616.63 GB 1  ?  4a8f04ff-a198-44d1-baf4-72cc430cd8a9 RAC2 
UN 10.0.10.218 562.98 GB 1  ?  c00c375d-90bb-48c5-a8d0-7102a13db468 RAC2 
UN 10.0.10.219 632.58 GB 1  ?  1e2ea144-35bd-412b-89b5-41544a347a75 RAC2 
UN 10.0.10.220 746.85 GB 1  ?  d40f59c1-430a-4d96-9d7e-1e846b8eb1fc RAC2 
UN 10.0.10.221 575.89 GB 1  ?  7e407d6b-2bd5-43b4-9116-96ee72a926b2 RAC2 
UN 10.0.10.222 639.98 GB 1  ?  bfd04ab8-7679-4474-8d47-984950bdd2c7 RAC1 
UN 10.0.10.223 652.58 GB 1  ?  6366cd3e-7910-40bb-8a12-926c53adf95b RAC1 

Der Code für diese Behauptung ist hier:

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cassandra/cassandra-all/2.1.1/org/apache/cassandra/utils/ByteBufferUtil.java?av=f#290

• Es gibt kein offensichtliches Schema-Mismatch, wenn Sie entweder die Tabellen system.local oder system.peers betrachten.
• nodetool describecluster kehrt UNREACHABLE von einigen Knoten

Answer 1

Sie sind wahrscheinlich die 64 K max Schlüsselgröße Grenze trifft, http://wiki.apache.org/cassandra/FAQ#max_key_size

Geben Sie für Ihre Anwendungscode, wahrscheinlich lange Daten als Primärschlüssel cassandra 371.205 Byte jemanden senden, vielleicht jemand versuchen, Ihre Anwendung zu knacken i don‘ t wissen, weil sehr unwahrscheinlich 370k Daten als Primärschlüssel ist sinnvoll, schränken Sie dies in Ihrem Anwendungscode,

Ich weiß nicht, ob ein Bug oder Fix oder eine Problemumgehung darüber besteht.

Answer 2

1. Replikationsfaktor überprüfen. 2. Mit unterschiedlicher Konsistenz prüfen. 3. Meistens kann die Konfiguration falsch sein, wenn Sie nur einen Token pro Knoten geben. Wenn Sie 256 Token pro Knoten haben, verteilt Cassandra die Last auf jeden Knoten.