So we know how to move around data and manage Cassandra instances to handle the production situations. Cassandra provides simple one-liner commands to perform various complicated maintenance tasks to make life easy. Scaling up, scaling down, removing live or dead nodes, and load balancing are pleasantly simple and can be automated based on your configuration using scripts. Backups fall in the same category, but restoration can be a bit tricky. With the Cassandra data model, built-in replication, and support for multiple data center setup, one may configure Cassandra such that it may never need a backup. Also, for really large databases, it may be impractical to siphon out data instead of using replication. It may make sense to back up in a case where the database is not very large and one uses a replication factor of 1. In such a case, going down a node may cause loss of data. However, RF=1 is a bad idea in production setup and backup can just restore the data until the latest backup is made.

Priam gives a decent option to move on from the nodetool-based mechanism to a more sophisticated tool. If you are just starting out, or have a small cluster, it is not worth the effort it takes to configure Priam. It is a good suggestion for large cluster owners. Moreover, Priam is built to support the AWS infrastructure and tied to the AWS configuration. So, it may not be useful to everyone. One may consider DataStax's OpsCenter for such tasks. We will discuss OpsCenter in the next chapter.

This chapter gives you enough knowledge to tackle an infrastructure issue. Now, you, as an operations person, need to keep a watch on how things are doing without losing your sleep and waking up from nightmares. The next chapter will walk you through the various ways to monitor and recognize problems, and troubleshoot the Cassandra infrastructure in detail.