8
Raspberry-Pi 4-Node Apache Cassandra Cluster Problem
Hallo zusammen,
also ich habe 4 Raspberrys mit Apache Cassandra installiert. Statische IP und andere kleinere Einstellungen habe ich auch bereits getätigt. Die Pis sehen sich untereinander auch - soweit so gut.
Die IP Adressen lauten: 192.168.178.51 bis .54
In meiner Cassandra.yaml Config-File habe ich folgende Einstellungen getroffen:
cluster_name: 'Test Cluster'
initial_token: Habe ich mit dem mitgelieferten token-generator generiert.
seed_provider:
- seeds: "192.168.178.51"
listen_address: Droplet's IP
rpc_address: 0.0.0.0
endpoint_snitch: RackInferringSnitch
Die Anleitung welche ich verwende sagt mir, dass ich Pi01 mit der IP (.51) als erstes starten soll, da dieser mein "seed" ist.
Während dem booten jedoch kommen hunderte Fehlermeldungen, wie z.B.:
WARN 10:24:09 Token 6436405636961323290 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 7179378171345093230 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 4885181782908097142 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 742967880462982164 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 5652804589798010165 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 4400097028434728215 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 1675545333640867684 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -8663374480600398885 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 1702469637743651899 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -4986820230313833771 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 5284137053355309400 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -7033204945348820093 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -7868759649811811191 changing ownership from /192.168.178.52 to /192.168.178.51
Sobald ich dann die anderen 3 Server starte, nimmt das Chaos seinen lauf und alle Millisekunde kommen auf allen 4 Raspberrys solche Warnungen.
Was mache ich falsch?
Vielen lieben Dank für die Mühe mir zu helfen.
Liebe Grüße,
KawaFFM
also ich habe 4 Raspberrys mit Apache Cassandra installiert. Statische IP und andere kleinere Einstellungen habe ich auch bereits getätigt. Die Pis sehen sich untereinander auch - soweit so gut.
Die IP Adressen lauten: 192.168.178.51 bis .54
In meiner Cassandra.yaml Config-File habe ich folgende Einstellungen getroffen:
cluster_name: 'Test Cluster'
initial_token: Habe ich mit dem mitgelieferten token-generator generiert.
seed_provider:
- seeds: "192.168.178.51"
listen_address: Droplet's IP
rpc_address: 0.0.0.0
endpoint_snitch: RackInferringSnitch
Die Anleitung welche ich verwende sagt mir, dass ich Pi01 mit der IP (.51) als erstes starten soll, da dieser mein "seed" ist.
Während dem booten jedoch kommen hunderte Fehlermeldungen, wie z.B.:
WARN 10:24:09 Token 6436405636961323290 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 7179378171345093230 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 4885181782908097142 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 742967880462982164 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 5652804589798010165 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 4400097028434728215 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 1675545333640867684 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -8663374480600398885 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 1702469637743651899 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -4986820230313833771 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token 5284137053355309400 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -7033204945348820093 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 10:24:09 Token -7868759649811811191 changing ownership from /192.168.178.52 to /192.168.178.51
Sobald ich dann die anderen 3 Server starte, nimmt das Chaos seinen lauf und alle Millisekunde kommen auf allen 4 Raspberrys solche Warnungen.
Was mache ich falsch?
Vielen lieben Dank für die Mühe mir zu helfen.
Liebe Grüße,
KawaFFM
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 277866
Url: https://administrator.de/contentid/277866
Printed on: April 18, 2024 at 19:04 o'clock
8 Comments
Latest comment
Hallo KawaFFM,
bist du dir sicher, dass du an dem PI1 mit der IP 192.168.178.51 und nicht an dem PI2 mit der IP 192.168.178.52 bist?
Dein Log sagt ja, dass er die IP-Adresse von der IP 192.168.178.52 in die IP 192.168.178.51 ändert.
Interessant wäre für uns auch, welche Anleitung du benutze. Da kann man evtl. auch noch den ein oder anderen Fehler finden.
Lg Pago
bist du dir sicher, dass du an dem PI1 mit der IP 192.168.178.51 und nicht an dem PI2 mit der IP 192.168.178.52 bist?
Dein Log sagt ja, dass er die IP-Adresse von der IP 192.168.178.52 in die IP 192.168.178.51 ändert.
Interessant wäre für uns auch, welche Anleitung du benutze. Da kann man evtl. auch noch den ein oder anderen Fehler finden.
Lg Pago
1
Zitat von @Pago159:
Hallo KawaFFM,
bist du dir sicher, dass du an dem PI1 mit der IP 192.168.178.51 und nicht an dem PI2 mit der IP 192.168.178.52 bist?
Hallo KawaFFM,
bist du dir sicher, dass du an dem PI1 mit der IP 192.168.178.51 und nicht an dem PI2 mit der IP 192.168.178.52 bist?
Ja, eigentlich sehr sicher. Ich habe die Vermutung, dass diese ganze "Token" Sache Probleme macht. Brauch man diese zwingend?
Dein Log sagt ja, dass er die IP-Adresse von der IP 192.168.178.52 in die IP 192.168.178.51 ändert.
Interessant wäre für uns auch, welche Anleitung du benutze. Da kann man evtl. auch noch den ein oder anderen Fehler
finden.
Interessant wäre für uns auch, welche Anleitung du benutze. Da kann man evtl. auch noch den ein oder anderen Fehler
finden.
https://www.digitalocean.com/community/tutorials/how-to-configure-a-mult ...
---
Hier ist mal ein kompletter Auszug was passiert, wenn ich auf Pi01 Cassandra starten möchte.
http://pastebin.com/J4xJWyxA
---
Vielen Dank für die schnelle Antwort. Ich hoffe sehr, dass ich das Problem mit Eurer Hilfe in den Griff bekommen kann.
LG,
KawaFFM
Meine Tokens habe ich übrigens mit dem Cassandra mitgelieferten "token-generator" generiert.
Und auch in die `Cassandra.yaml` Files entsprechend eingetragen.
node 0: 0
node 1: 42535295865117307932921825928971026432
node 2: 85070591730234615865843651857942052864
node 3: 127605887595351923798765477786913079296
node 1: 42535295865117307932921825928971026432
node 2: 85070591730234615865843651857942052864
node 3: 127605887595351923798765477786913079296
Und auch in die `Cassandra.yaml` Files entsprechend eingetragen.
Kannst du mal bitte die cassandra.yaml der einzelnen PIs anhängen? da gibt es wohl Probleme mit den Tokens (Zuordnung der Geräte IP)
Auf folgenden Geräten ist die Konfig falsch:
192.168.178.52 hier läuft wohl der Token von 192.168.178.51
192.168.178.53 hier läuft wohl der Token von 192.168.178.52
192.168.178.54 hier läuft wohl der Token von 192.168.178.53
folglich müsste aber auch auf dem 192.168.178.51 der Token des 192.168.178.54 laufen, auch wenn dieser nicht angemosert wurde.
kannst du bitte die Code Tags benutzen, wenn du die Konfiguration Postest? Dann lässt sich das ganze besser lesen.
Lg Pago
Auf folgenden Geräten ist die Konfig falsch:
192.168.178.52 hier läuft wohl der Token von 192.168.178.51
192.168.178.53 hier läuft wohl der Token von 192.168.178.52
192.168.178.54 hier läuft wohl der Token von 192.168.178.53
folglich müsste aber auch auf dem 192.168.178.51 der Token des 192.168.178.54 laufen, auch wenn dieser nicht angemosert wurde.
kannst du bitte die Code Tags benutzen, wenn du die Konfiguration Postest? Dann lässt sich das ganze besser lesen.
Lg Pago
Hallo Pago159,
erstmal vielen Dank für die schnelle Hilfe deinerseits.
Habe an anderer Stelle im Internet gelesen, dass es eventuell am "token-generator" liegen könnte, da der Standard Cassandra-Token-Generator nur (Random Partitioner = 0 to 2^127) rechnet.
Nun habe ich den Murmur3 Partitioner, mit "-2^63 to 2^63-1" benutzt und folgende Tokens rausbekommen:
Hier meine "Cassandra.yaml" bei Pastebin: http://pastebin.com/wyyxFcqA
Die andereren Config-Files haben bis auf das initial-token und die listen_adress denke ich mal keinen Unterschied.
Ich hoffe es ist nur en kleiner Fehler meinerseits, so würde sich mein Wissen diesbezüglich nicht über den Haufen werfen.
erstmal vielen Dank für die schnelle Hilfe deinerseits.
Habe an anderer Stelle im Internet gelesen, dass es eventuell am "token-generator" liegen könnte, da der Standard Cassandra-Token-Generator nur (Random Partitioner = 0 to 2^127) rechnet.
Nun habe ich den Murmur3 Partitioner, mit "-2^63 to 2^63-1" benutzt und folgende Tokens rausbekommen:
How many nodes are in your cluster? 4
node 0: -9223372036854775808
node 1: -4611686018427387904
node 2: 0
node 3: 4611686018427387904
node 0: -9223372036854775808
node 1: -4611686018427387904
node 2: 0
node 3: 4611686018427387904
Hier meine "Cassandra.yaml" bei Pastebin: http://pastebin.com/wyyxFcqA
Die andereren Config-Files haben bis auf das initial-token und die listen_adress denke ich mal keinen Unterschied.
Ich hoffe es ist nur en kleiner Fehler meinerseits, so würde sich mein Wissen diesbezüglich nicht über den Haufen werfen.
Ich habe die config Datei jetzt nur mal schnell überflogen, allerdings würde mir jetzt hier auffallen, dass evtl. unter -seeds die IP-Adressen, der jeweils anderen PIs angegeben werden müssten (Ausgehend davon, dass es sich hier um Client 192.168.178.54 handelt):
Hier würde ich auf dem Interface hören und nicht auf der IP, zumindest zu Testzwecken.
Kannst du dies mal testen? Du müsstest natürlich bei allen PIs die config anpassen.
Lg Pago
# any class that implements the SeedProvider interface and has a
# constructor that takes a Map<String, String> of parameters will do.
seed_provider:
# Addresses of hosts that are deemed contact points.
# Cassandra nodes use this list of hosts to find each other and learn
# the topology of the ring. You must change this if you are running
# multiple nodes!
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
# seeds is actually a comma-delimited list of addresses.
# Ex: "<ip1>,<ip2>,<ip3>"
- seeds: "192.168.178.51","192.168.178.52","192.168.178.53" Hier würde ich auf dem Interface hören und nicht auf der IP, zumindest zu Testzwecken.
# Setting listen_address to 0.0.0.0 is always wrong.
#listen_address: 192.168.178.51
listen_interface: eth0Kannst du dies mal testen? Du müsstest natürlich bei allen PIs die config anpassen.
Lg Pago
Habe eben - nur um sicher zu gehen - mal alle raspberry's neu aufgesetzt und Cassandra neu installiert ... leider vergebens. Hätte ja sein können, dass sich mit Dauer der Experimente und des herumspielens Fehler eingeschlichen haben.
Da könntest du vermutlich Recht haben. Laut dieser Anleitung hier http://docs.datastax.com/en/cassandra/1.2/cassandra/initialize/initiali ... soll man bei den seeds ja nur die IP's angeben, welche auch als seeds fungieren sollen. Da ich jetzt nur ein 4-node-cluster betreiben möchte, dachte ich es würde ein einziger seed ausreichen. Aber ich werde jetzt mal alle 4 Ip's eintragen.
So, erledigt. Jetzt haben alle 4 Raspberrys die selbe Config sozusagen.
Pi01 endet so:
./nodetool status ergibt:
Es kann doch nicht sein! Vor einiger Zeit hat es bereits einmal geklappt und zwar ohne die ständigen "token ownership" Probleme.
Selbst, wenn ich "manual token" auszementiere, bzw. eine "default 1" einsetze kommen derartige Fehlermeldungen.
Hilft dir das weiter bei der Suche zu meinem Fehler oder brauchst du noch andere Angaben?
Vielen, vielen, vielen lieben Dank, dass du dir meines Problems überhaupt angenommen hast.
Da könntest du vermutlich Recht haben. Laut dieser Anleitung hier http://docs.datastax.com/en/cassandra/1.2/cassandra/initialize/initiali ... soll man bei den seeds ja nur die IP's angeben, welche auch als seeds fungieren sollen. Da ich jetzt nur ein 4-node-cluster betreiben möchte, dachte ich es würde ein einziger seed ausreichen. Aber ich werde jetzt mal alle 4 Ip's eintragen.
So, erledigt. Jetzt haben alle 4 Raspberrys die selbe Config sozusagen.
Pi01 endet so:
WARN 09:09:35 Token -2434846149206858783 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 09:09:35 Token 9019203589721596131 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 09:09:35 Token 8233195357869744602 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 09:09:35 Token -3839971700679026648 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 09:09:35 Token -8480194111291298656 changing ownership from /192.168.178.52 to /192.168.178.51
INFO 09:09:35 Node /192.168.178.51 state jump to normal
INFO 09:09:36 Waiting for gossip to settle before accepting client requests...
INFO 09:09:44 No gossip backlog; proceeding
WARN 09:09:35 Token 9019203589721596131 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 09:09:35 Token 8233195357869744602 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 09:09:35 Token -3839971700679026648 changing ownership from /192.168.178.52 to /192.168.178.51
WARN 09:09:35 Token -8480194111291298656 changing ownership from /192.168.178.52 to /192.168.178.51
INFO 09:09:35 Node /192.168.178.51 state jump to normal
INFO 09:09:36 Waiting for gossip to settle before accepting client requests...
INFO 09:09:44 No gossip backlog; proceeding
./nodetool status ergibt:
pi@pi01 ~/cassandra/bin $ ./nodetool status
error: No nodes present in the cluster. Has this node finished starting up?
-- StackTrace --
java.lang.RuntimeException: No nodes present in the cluster. Has this node finished starting up?
at org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:129)
at org.apache.cassandra.service.StorageService.effectiveOwnership(StorageService.java:3763)
at org.apache.cassandra.service.StorageService.effectiveOwnership(StorageService.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
error: No nodes present in the cluster. Has this node finished starting up?
-- StackTrace --
java.lang.RuntimeException: No nodes present in the cluster. Has this node finished starting up?
at org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:129)
at org.apache.cassandra.service.StorageService.effectiveOwnership(StorageService.java:3763)
at org.apache.cassandra.service.StorageService.effectiveOwnership(StorageService.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Es kann doch nicht sein! Vor einiger Zeit hat es bereits einmal geklappt und zwar ohne die ständigen "token ownership" Probleme.
Selbst, wenn ich "manual token" auszementiere, bzw. eine "default 1" einsetze kommen derartige Fehlermeldungen.
Hilft dir das weiter bei der Suche zu meinem Fehler oder brauchst du noch andere Angaben?
Vielen, vielen, vielen lieben Dank, dass du dir meines Problems überhaupt angenommen hast.
Also ich habe jetzt doch noch mal in die Doku geschaut:
Die "listen_address" (IP-Adresse des PIs):
(Default: localhost ) The IP address or hostname that other Cassandra nodes use to connect to this node. If left unset, the hostname must resolve to the IP address of this node using /etc/hostname, /etc/hosts , or DNS. Do not specify 0.0.0.0.
Der "seed_provider" (Es wird wirklich nur einer benötigt in dem fall wäre es dann 127.0.0.1, es sei denn du hättest mehrere Seeds, dann müssten die IP-Adressen der Seeds eingetragen werden)¶
(Default: org.apache.cassandra.locator.SimpleSeedProvider ) A list of comma-delimited hosts (IP addresses) to use as contact points when a node joins a cluster. Cassandra also uses this list to learn the topology of the ring. When running multiple nodes, you must change the - seeds list from the default value ( 127.0.0.1 ). In multiple data-center clusters, the - seeds list should include at least one node from each data center (replication group). See Initializing a multiple node cluster (single data center) and Initializing a multiple node cluster (multiple data centers).
Eine gute Erklärung aller Einstellungen findest du hier:
http://docs.datastax.com/en/cassandra/1.2/cassandra/configuration/confi ...
Ich habe leider nur einen Banana PRO hier stehen, sonst hätte ich das mal testweise aufgebaut, da fehlt allerdings die komplette Testumgebung.
Die "listen_address" (IP-Adresse des PIs):
(Default: localhost ) The IP address or hostname that other Cassandra nodes use to connect to this node. If left unset, the hostname must resolve to the IP address of this node using /etc/hostname, /etc/hosts , or DNS. Do not specify 0.0.0.0.
Der "seed_provider" (Es wird wirklich nur einer benötigt in dem fall wäre es dann 127.0.0.1, es sei denn du hättest mehrere Seeds, dann müssten die IP-Adressen der Seeds eingetragen werden)¶
(Default: org.apache.cassandra.locator.SimpleSeedProvider ) A list of comma-delimited hosts (IP addresses) to use as contact points when a node joins a cluster. Cassandra also uses this list to learn the topology of the ring. When running multiple nodes, you must change the - seeds list from the default value ( 127.0.0.1 ). In multiple data-center clusters, the - seeds list should include at least one node from each data center (replication group). See Initializing a multiple node cluster (single data center) and Initializing a multiple node cluster (multiple data centers).
Eine gute Erklärung aller Einstellungen findest du hier:
http://docs.datastax.com/en/cassandra/1.2/cassandra/configuration/confi ...
Ich habe leider nur einen Banana PRO hier stehen, sonst hätte ich das mal testweise aufgebaut, da fehlt allerdings die komplette Testumgebung.
