73 Managing Cassandra Message Store

This chapter describes tasks for managing a Cassandra Message store.

Restarting a Cassandra Message Store Cluster

When using a Cassandra message store cluster, follow the instructions in this section to ensure proper shutdown and startup of the cluster.

Cassandra replays the commitlog updates during node startup. On Solr nodes, this means all the commitlog updates are reindexed. The Field Input Transformer (FIT) requires reading from Cassandra (from the conversioncache table in ms_cache keyspace) at index time. Therefore, when restarting a cluster, you must follow one of the following recommendations:

  1. It is best to restart nodes one at a time, to ensure that the FIT is always able to read data from the ms_cache keyspace.

  2. If you must stop the entire cluster, run the Cassandra nodetool flush command on each node before stopping it. This command ensures that all data is flushed to sstables.

  3. If the entire cluster stops before you have a chance to run the nodetool flush command, then you must start the ms_cache ring first. (You should set up the ms_cache keyspace in a separate ring). This ensures that the FIT can read cache data during the replay of the commitlog.

Failure to follow these recommendations results in read failures in the FIT logs. Additionally, DataStax software takes a long time to start on the Solr nodes. It is also possible that the reindexing of the commitlog experiences a timeout and the node does not start.

Scaling Your Cassandra Message Store Deployment Horizontally

You can scale your Cassandra message store deployment horizontally by adding more nodes to an existing deployment. For adding a node, datacenter, or cluster, see the Cassandra documentation at:

http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/operations/opsAddingRemovingNodeTOC.html

Adding an Access-Tier Node (IMAP/LMTP Server/enpd)

To add a message access tier (IMAP/LMTP-server/enpd) node to a store affinity group:

  1. Configure and start the new server.

  2. Test the new server.

    You should be able to access IMAP accounts through the new server, although LMTP, IMAP IDLE, and notifications for IMAP APPEND operations are not yet live.

  3. Update the recipe that you used to set up store affinity groups to add this server to the store affinity group in question.

  4. Run the store affinity group recipe on all message access tier hosts in the deployment and use the refresh command to activate the change in the deployment.

    EA Note:

    For Early Access, this is technically only necessary on the store affinity group in question. However, when shared folder support is added, that will no longer be true.
  5. At this point, IMAP IDLE should work on the new host but it is not yet servicing customer requests.

  6. Run the recipe on all front-end tier hosts in the deployment and use refresh for MMP/mshttpd, and imsimta reload to update the store affinity group configuration.

Creating a new store affinity group is a similar procedure but you must have at least two hosts in the new group.

Managing Your Cassandra Message Store Availability

To remove a node, datacenter, or cluster, see the Cassandra documentation at:

http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/operations/opsAddingRemovingNodeTOC.html

Removing an Access-Tier Node (IMAP/LMTP Server/enpd)

To remove a message access tier (IMAP/LMTP-server/enpd) node from a store affinity group:

  • Update the store affinity group recipe to remove the node.

    Remember, keep at least two nodes in an affinity group for robustness.

  • Run the recipe on the front-end tier, and use the refresh or imsimta command to update information.

  • Run the recipe on the message access tier and refresh (run on host being removed last).

  • Wait for active IMAP/LMTP connections to finish or forcefully disconnect users with the imsconnutil command or by stopping the server.