This chapter provides an overview of the Oracle Communications Messaging Server Cassandra message store.
Apache Cassandra message store is a free and open-source NoSQL database designed for large amounts of data.
In Messaging Server, the Cassandra message store consists of keyspaces. A keyspace, in a NoSQL data store, is a namespace that defines data replication on nodes. (It resembles the schema concept in Relational database management systems.) The Messaging Server Cassandra message store consists of the following keyspaces:
msg: Contains the email message "blobs." It can be very large.
mbox: Contains user and mailbox metadata. It is relatively small and has a lot of mutations.
cache: Contains cache tables for converted message blobs.
The Cassandra message store differs from the classic message store in the following ways:
The Cassandra message store uses a single maintenance queue. Classic message store uses three maintenance queues.
The imcheck -d and imcheck -s commands are supported only by classic message store.
Other imcheck command differences with classic message store:
imcheck -m output: The Cassandra message store does not have start offset, cache ID and cache offset.
imcheck -q: The RecNo is not unique in Cassandra message store.
When you rename a mailbox on Cassandra, the subscription list is updated automatically. IMAP has SUBSCRIBE and UNSUBSCRIBE commands, which are typically used for shared folders. There is no requirement in the IMAP specification for the subscription to recognize the new name when a shared folder is renamed. Classic message store subscriptions do not follow renames, whereas Cassandra message store does.
Cassandra message store folder purge is always deferred. This is optional in classic message store. Also, Cassandra message store mailbox purge and cleanup tasks are combined into one task.
Cassandra message store does not advertise the IMAP ACL extension (RFC 4314). Although the ACL commands are implemented, the semantics of ACLs with respect to shared folders are not fully implemented. As a result, it is inappropriate to advertise the IMAP ACL extension in this version of Cassandra message store.
Cassandra message store does not support the IMAP ANNOTATE capability. (The ANNOTATE extension to IMAP permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server.)
In Cassandra message store, delete user does not remove access rights from the ACL of the other user's folder. When a user is deleted and recreated, shared folders are still accessible.
User ID (puid) and folder ID (fid) are permanently unique in Cassandra message store.
Cassandra message store does not use a message store partition. Thus, you no longer are able to perform maintenance tasks such as expire, backup, and reconstruct by store partition.
The imexpire command cannot install expire rules by partition.
Cassandra message store supports only mailbox reconstruct.
Cassandra message store only supports Unified Configuration.
IMAP subscribe: Cassandra message store does not permit users to subscribe to non-existing folders.
Specific differences that apply to Messaging Server 8.0.x:
The reconstruct -x command has been obsoleted (it is now always enabled).
imcheck -e output: The File type column has been removed.
imcheck -q output: RecNo has a queue prefix.
Classic message store allows use of invalid identifiers in IMAP ACLs; they are simply ignored when evaluating the ACL. Cassandra message store does not allow use of invalid identifiers in an ACL; an attempt to use an invalid identifier will result in no change to the ACL.
Cassandra message store supports both an external identifier and a persistent identifier for each user. Changing the persistent identifier of an existing user is not recommended. The external identifier for a user can be changed freely and is used for ACLs and shared folders instead of the persistent identifier. See the topic on User Identifiers in Messaging Server Reference, as well as the ldap_permid and ldap_extid options for more information.
A SETACL command for cross-domains is not allowed. Thus, for a Cassandra message store, the value for the store.privatesharedfolders.restrictdomain configuration option is always 1 (to disallow regular users from sharing private folders to users in another domain.) In addition, neither the default domain nor the canonical domain name can ever be changed.
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.
To add a message access tier (IMAP/LMTP-server/enpd) node to a store affinity group:
Configure and start the new server.
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.
Update the recipe that you used to set up store affinity groups to add this server to the store affinity group in question.
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.At this point, IMAP IDLE should work on the new host but it is not yet servicing customer requests.
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.
To remove a node, datacenter, or cluster, see the Cassandra documentation.
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.