A quick question. When we are trying to take snapshot of our keyspace it is throwing an exception as Read Timeout. Below is the command we are using:-
./nodetool -h 172.16.100.52 -p 9042 snapshot test;
"test" is our keyspace which has some tables and we were trying to take a backup through the snapshot command. Below is the error we are receiving after a minute :-
nodetool: Failed to connect to '172.16.100.52:9042' - SocketTimeoutException: 'Read timed out'.
Is there any parameter in the yaml file or env file which you can think of which might help?
Try it without specifying your port
./nodetool -h 172.16.100.52 snapshot test
9042 is the native binary protocol port, so that's not going to work. 7199 is the JMX port, which is what nodetool is expecting here. In fact, you shouldn't need to specify that at all.
If you insist on specifying a port, try 7199 (unless you have altered the JMX port).
./nodetool -h 172.16.100.52 -p 7199 snapshot test
I have a similar issue, looks like you are using local JMX connection. Check cassandra-env.sh.
Related
I want to connect to Cassandra installed in a remote server from my dev environment. Dev Environment doesn't have cassandra installed and hence it is not allowing me to do the below for connecting to my cassandra server running on a different machine.
Client System - Dev System without Cassandra
Destination System - Prod Environment where Cassandra is installed
I am trying the below command over my dev terminal to connect to Prod Cassandra.
/opt/cassandra/dse-4.8.7/bin/cqlsh -e "select * from
/"IasService/"./"Table/" limit 10"
remote.stress.py1.s.com 9160 -u test-p test2;
Any leads would be helpful.
tldr;
Remove the 9160 from your command.
It would be easier to help you if you provided the error message or result of your command.
That being said, DSE 4.8.7 has Cassandra 2.1.14 at its core. As of Cassandra 2.1, cqlsh connects using the native binary protocol on port 9042. So forcing it to 9160 (as you are) will definitely not work.
$ cqlsh -e "SELECT release_version FROM system.local" 192.168.6.5 9042
-u cassdba -p superSecret
release_version
-----------------
2.1.13
(1 rows)
And since 9042 is the default port used by cqlsh now, you don't need to specify it at all.
I am new to cassandra but it seems the nodetool bootstrap command is not working.
huangg#cassandra-mpsre01-sjc1:~$ nodetool help bootstrap
Unknown command bootstrap
huangg#cassandra-mpsre01-sjc1:~$ nodetool bootstrap resume
nodetool: Found unexpected parameters: [bootstrap, resume]
See 'nodetool help' or 'nodetool help <command>'.
huangg#cassandra-mpsre01-sjc1:~$ nodetool help |grep bootstrap
rebuild Rebuild data by streaming from other nodes (similarly to bootstrap)
Is it a version issue?
[cqlsh 5.0.1 | Cassandra 2.1.9 | CQL spec 3.2.0 | Native protocol v3]
I want to use it because I want to resume a node after I decommission it. Right now, after I decommission a node, I have to stop cassandra service and then restart the cassandra service. I guess bootstrap can be used after the decommission command, to commission the node.
nodetool join is a different thing.
So there are two things here
1. First the commands which you specified don't seem correct.
For Bootstrap you can probably use the following link and see the correct syntax.
https://docs.datastax.com/en/cassandra/2.2/cassandra/tools/toolsBootstrap.html
Now after the node is decommissioned, you would want to rebuild it from another node and then work with it as the other nodes are working.
For that you can use nodetool rebuild.
https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsRebuild.html
Both are similar commands, but you can see which suits your scenario best and use accordingly.
nodetool bootstrap doesn't exist in c* 2.1.9. nodetool rebuild is the closest command
$ nodetool help rebuild NAME
nodetool rebuild - Rebuild data by streaming from other nodes (similarly
to bootstrap)
SYNOPSIS
nodetool [(-h | --host )] [(-p | --port )]
[(-pw | --password )]
[(-pwf | --password-file )]
[(-u | --username )] rebuild [--]
OPTIONS
-h , --host
Node hostname or ip address
-p <port>, --port <port>
Remote jmx agent port number
-pw <password>, --password <password>
Remote jmx agent password
-pwf <passwordFilePath>, --password-file <passwordFilePath>
Path to the JMX password file
-u <username>, --username <username>
Remote jmx agent username
--
This option can be used to separate command-line options from the
list of argument, (useful when arguments might be mistaken for
command-line options
<src-dc-name>
Name of DC from which to select sources for streaming. By default,
pick any DC
I'm trying to install and configure cassandra programmatically using a shell script.
I install cassandra, run ./cassandra and then I try to load the schema using cassandra-cli --host localhost -f <schema-file>. The problem is that it tries to load the schema before cassandra is up and throws an exception. Is there any way to know when cassandra is up and running?
Thanks!
You can check to see if anything is listening on 9160 (the Thrift port) prior to loading the schema. Binding to the port is the last thing the service does, and indicates it's ready to service requests.
If Cassandra is running this command will return something:
sudo lsof -i :9160
use ./cassandra -f then you will know it when Cassandra starts to listen on the Thrift port
My Cassandra used to work with no problems.
I was able to connect with no problems but now for some reason it doesn't work anymore.
[default#unknown] connect localhost/9160;
Exception connecting to localhost/9160. Reason: Connection refused.
I am in Ubuntu server
Thanks in-advance
The solution to this question was provided to you on the pycassa google group:
https://groups.google.com/d/topic/pycassa-discuss/Bai7bvkHYU4/discussion
This is not a pycassa problem. The problems you are having are specific to starting a Cassandra instance and not following the documentation in the README.txt that is in the root folder of the distribution:
Getting started
This short guide will walk you through getting a basic one node cluster up
and running, and demonstrate some simple reads and writes.
tar -zxvf apache-cassandra-$VERSION.tar.gz
cd apache-cassandra-$VERSION
sudo mkdir -p /var/log/cassandra
sudo chown -R whoami /var/log/cassandra
sudo mkdir -p /var/lib/cassandra
sudo chown -R whoami /var/lib/cassandra
Note: The sample configuration files in conf/ determine the file-system
locations Cassandra uses for logging and data storage. You are free to
change these to suit your own environment and adjust the path names
used here accordingly.
Now that we're ready, let's start it up!
bin/cassandra -f
Running the startup script with the -f argument will cause Cassandra to
remain in the foreground and log to standard out.
Now let's try to read and write some data using the command line client.
bin/cassandra-cli --host localhost
The command line client is interactive so if everything worked you should
be sitting in front of a prompt...
Connected to: "Test Cluster" on localhost/9160
Welcome to cassandra CLI.
Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit.
[default#unknown]
As the banner says, you can use 'help;' or '?' to see what the CLI has to
offer, and 'quit;' or 'exit;' when you've had enough fun.
Verify the following:
Cassandra process is running and thrift is listening on 9160 (netstat-tulpn)
9160 port not being blocked by a firewall rule or similar
If the above are true, then check the cassandra log for additional information.
Other than that your description is pretty vague. So any other information about what may have changed in the environment would be helpful.
I faced the same problem and the reason was that I had configured Cassandra to listen on the Server IP and not on localhost.
/etc/dse/cassandra/cassandra.yaml
listen_address: 10.102.8.71
So try this and check if it works for you:
cassandra-cli --host "your host name"
When I try and run jmeter-server from a server connected via putty, it hangs with:
bash-3.2$ ./jmeter-server -t filename.jmx
Using local port: 4000
Created remote object: UnicastServerRef [liveRef: [endpoint:[172.31.120.200:4000] (local),objID:[1a15acdf:12f949f58d8:-7fff, -8305458059461378367]]]
What am I doing wrong? It just hangs. Previously it was erroring with:
bash-3.2$ ./jmeter-server
Using local port: 4000
Created remote object: UnicastServerRef [liveRef: [endpoint:[172.31.120.200:4000](local),objID:[1fa5aea9:12f94a578a6:-7fff, -8358825329658872549]]]
Problem creating registry: java.rmi.server.ExportException: Port already in use: 1099; nested exception is:
java.net.BindException: Address already in use
Continuing...
Server failed to start: java.rmi.RemoteException: Cannot start. See server log file.
What gives?
Port 1099 is default port of jmeter server, this means that you have already lauched jmeter server. I think you should first kill it and then try to start:
ps ax | grep jmeter
kill -9 PID (from previous command)
Before starting remote testing I think you should read documentation, seems you are doing it wrong: http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf
Looks you need change your jmeter SERVER_PORT to a not "1099" number from the error information.
Guess I probably were in your situation.
It helps to me to use java8 and the next properties when starting jmeter-server
/opt/jmeter/bin/jmeter-server \
-Dserver.rmi.localport=50000 \
-Dserver_port=1099 \
-Jserver.rmi.ssl.disable=true
Also check logs in jmeter-server.log file