2017-02-27 8 views
1

Ich verwende apache cassandra 2.2.4. Ich habe einen 4 (vier) Knoten-Cluster mit Replikationsfaktor 3 in DC1 und Replikationsfaktor 1 in DC2, wobei DC1 3 (drei) Knoten enthält und DC2 1 (einen) Knoten enthält. In diesem Cluster waren zuvor einige weitere Knoten vorhanden, aber aus irgendeinem Grund habe ich sie entfernt und das Replikationsszenario nicht geändert. [Bitte beachten Sie, dass die folgenden IP-Adressen sind nicht original]Unerwartete Ausnahme während Anforderung

Datacenter: DC1 
=============== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address  Load  Tokens  Owns Host ID        Rack 
UN 21.12.19.91 4.08 GB 256   ?  a45bb676-1ddd-4b22-933b-58653cea680f RAC1 
UN 21.12.19.92 3.92 GB 256   ?  a7735fca-8671-4a20-a759-4a2681aed37e RAC1 
UN 21.12.19.93 4.47 GB 256   ?  d98f3cad-881a-41c8-89c7-170c63c3d236 RAC1 
Datacenter: DC2 
=============== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address  Load  Tokens  Owns Host ID        Rack 
UN 21.12.19.99 3.84 GB 256   ?  ccd9ca97-f97a-4473-9a65-49b12a1b60ba RAC1 

Cluster war in Ordnung zu arbeiten, aber jetzt zu Tage, die ich ein Problem wie INFO habe. Ich habe versucht, das Problem zu analysieren, konnte es aber noch nicht schaffen. Gibt es jemanden, der das folgende Szenario kennt?

INFO [SharedPool-Worker-2] 2017-02-26 06:56:48,520 Message.java:605 - Unexpected exception during request; channel = [id: 0x637a702c, /18.12.10.17:60926 :> /21.12.19.91:9042] 
java.io.IOException: Error while read(...): Connection reset by peer 
    at io.netty.channel.epoll.Native.readAddress(Native Method) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 
    at io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.doReadBytes(EpollSocketChannel.java:675) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 
    at io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.epollInReady(EpollSocketChannel.java:714) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:326) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:264) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 
    at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 
+0

Was ist IP 18.12.10.17 (Ausnahme)? – Ralkie

+0

Es ist ein Entwickler endet IP. –

Antwort

0

Bitte stellen Sie sicher, dass Ihre Firewall keine TCP-Verbindungen löscht, die gerade verwendet werden. Tcp am Leben auf allen Knoten muss weniger als die Firewall-Einstellung sein. Einzelheiten zu TCP-Einstellungen finden Sie unter https://docs.datastax.com/en/cassandra/2.0/cassandra/troubleshooting/trblshootIdleFirewall.html. Dies hat mir geholfen, das Problem zu lösen.

+0

Ich habe das von Anfang an durchgemacht. Ich habe genug ** keepalive_time **, ** keepalive_probes ** und ** keepalive_intvl ** Verzögerung konfiguriert. Also, es gibt keine Möglichkeit zu fallen. –

+0

In diesem Fall kann es auch daran liegen, dass Ihre Anwendung oder die anderen Knoten zwischengespeicherte IPs von Cassandra-Knoten gespeichert haben, die zuvor vorhanden waren und jetzt außer Betrieb genommen wurden. Aus den _INFO_Logs gesehen ** 18.12.10.17: 60926 ** scheint entfernt zu sein, versucht aber trotzdem, eine Verbindung herzustellen. Bitte führen Sie einen rollenden Neustart aller Knoten durch, und das sollte das Problem beheben. –

+0

** 18.12.10.17: 60926 ** ist eine Clientseite/Entwickler-IP. Wir verwenden keine anderen Block-IPs für einen einzelnen Cluster. Und wir haben auch rollend gestartet. Aber konnte nicht herausfinden, woher das Problem kommt. –

Verwandte Themen