Installing Cassandra on Windows

If you are upgrading Teamwork Cloud from a version lower than 18.5, do not upgrade Cassandra to 3.11-x until you have followed the directions for Upgrading Teamwork Cloud.

This page provides the instructions to install and configure Cassandra on Windows.

Prior to installing Cassandra, it is important to understand how Cassandra utilizes disk space in order to properly configure the host server.

Disk space depends on usage, so it's important to understand the mechanism. The database writes data to disk when appending data to the commitlog for durability and when flushing memtables to SSTable data files for persistent storage. The commit log has a different access pattern (read/writes ratio) than the pattern for accessing data from SSTables. This is more important for spinning disks than for SSDs.

SSTables are periodically compacted. Compaction improves performance by merging and rewriting data and discarding old data. However, depending on the type of compaction and size of the compactions, during compaction disk utilization and data directory volume temporarily increases. For this reason, be sure to leave an adequate amount of free disk space available on a node.

Compaction

In a worst-case scenario, compaction can potentially use the same amount of disk space as the dataset. Therefore, your data drive utilization should be monitored for maximum growth, and volume size increased if it reaches over 80% utilization.

Cassandra data and commit logs should not, under any circumstances, be placed on the drive where the operating system is installed. Ideally, a server would have 3-4 drives or partitions. Drive C:, the OS partition can be used as the target for the application. Drive D: should have adequate amounts of storage to accommodate your data. Drive E: would hold you commit logs (and unless SSD, should be on a different physical disk than the data partition), and Drive F: would be allocated for backups.

Commit logs

Commit logs should not be placed on the same partition as data. Commit log utilization varies from a few megabytes up to 8 gigabytes, constantly fluctuating as memtables get flushed to disk. This behavior, combined with transient growth of the data volume during compaction, can result in a database crash due to running out of disk space.

Following Microsoft Best Practices:

Your OS partition should be at least 60 GB.
The size of Drive D:, your data partition, will be dictated by the size and activity of the models in the repository. You should allocate as much as feasible but under no circumstances less than 250 GB.
Drive E:, your commit log partition should be at least 10GB (the commit logs are 8GB).
Drive F:, your backup partition, should be of the same size as Drive D:, and be located on a different physical drive.

Please refer to http://cassandra.apache.org/doc/latest/operating/hardware.html for explanations on hardware selection.