Running a Cassandra server
Now that we know the prerequisites, let's quickly check the language dependencies:
We can check the Java version using the following code:
$ java –version java version "1.7.0_45"
The Python version can be checked using this command:
$ python –version Python 2.6.6
Running a Cassandra node
Since we're running only single node, we can skip configurations and directly start our node. Run the Cassandra node using the command for tarball installation:
$ bin/Cassandra
We can stop the server by using the following command:
$ pgrep -u `whoami` -f cassandra | xargs kill -9
Sometimes, we might want to run a Cassandra node in the foreground for debugging purposes, then we'll run it with –f flag:
$ bin/cassandra –f
To stop, press Ctrl + C.
For package-based installations, use the following commands to start and stop, respectively:
$ sudo service Cassandra start $ sudo service Cassandra stop
Wohooo!! Our node is running, let's check our Cassandra server version:
$nodetool version ReleaseVersion: 2.1.2
Note
Since we used the default Cassandra configuration, our node is running on the local interface and we'll not be able to connect to it from outside this machine using clients, for example, Java driver or other CQL clients.
Setting up the cluster
Let's set up a three-node cluster with the IPs 127.0.0.1, 127.0.0.2 and 127.0.0.3. So, our Cassandra.yaml for each node will look like this:
Since all our nodes are the same from a hardware configuration perspective, we used num_tokens: 256 for all of them. The second node with an IP address of 127.0.0.2 acts as a seed node.
Additionally, we can set rpc_address and native_transport_ports for each node so that our Java client can connect to our nodes.
Now, we'll run the Cassandra server on each node using as discussed in the previous section, and our cluster with three nodes is ready.
Viewing the cluster status
Now that our cluster is up and running, let's check its status. We can use the Cassandra tool called nodetool to check the status:
$ nodetool status Datacenter: datacenter1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 127.0.0.1 171.88 MB 256 ? 940ba0cf-b75a-448c-a15e-40e05efbeb34 rack1 UN 127.0.0.2 141.12 MB 256 ? 4b728c3c-c545-4e4d-b1aa-2f66ef6bdce rack1 UN 127.0.0.3 174.71 MB 256 ? d63a18c4-0d2c-4574-8f66-c4eb1e5ca5a8 rack1 Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless
The first character in the status, which is U in our example, denotes the node's status whether it is Up (U) or Down (D). The second character tells us about the state of the joining cluster; it can be Normal (N), Leaving (L), Joining (J), or Moving (M). In our example, every node in the cluster is Up (U) and in the Normal (N) state. So, the first column is UN for each node. It also tells us about the data center in which our node lies. In our example, all the nodes lie in 'DataCenter 1' and rack 'rack1'.
Now, let's use the nodetool info command to check the individual node statistics such as its uptime, caching details, load details, and so on. We'll discuss Cassandra caching in detail in Chapter 4, Read and Write – Behind the Scenes:
$ nodetool info ID : 2f9bb0a9-db48-4146-83c6-4ce06bd22259 Gossip active : true Thrift active : true Native Transport active: true Load : 179.4 MB Generation No : 1422937400 Uptime (seconds) : 593431 Heap Memory (MB) : 474.63 / 920.00 Data Center : datacenter1 Rack : rack1 Exceptions : 0 Key Cache : entries 226, size 23.07 KB, capacity 45 MB, 4714 hits, 5006 requests, 0.942 recent hit rate, 14400 save period in seconds Row Cache : entries 0, size 0 bytes, capacity 600 MB, 0 hits, 0 requests, NaN recent hit rate, 3000 save period in seconds Counter Cache : entries 0, size 0 bytes, capacity 22 MB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds Token : (invoke with -T/--tokens to see all 256 tokens)
