This section covers everything you need to know to get up and running with RS, included installing, configuring a cluster, maintaining a cluster, creating databases, etc.

Topics include:

    Cluster Operations

    This section has all you need to know pertaining to administering the cluster in Redis Enterprise Software. Adding a Node to an Existing Cluster When you install RS on the first node of a cluster, you create the new cluster. After you install the first node, you can add more nodes to the cluster. Prerequisites The clocks on all nodes must always be synchronized. If the clock in the node you are trying to join to the cluster is not synchronized with the nodes already in the cluster, the action will fail and an error message will appear indicating that you must synchronize the clocks first.

    Database Operations

    This section contains all you need to know to operate databases hosted on Redis Enterprise Software. Causal Consistency in a Conflict-free Replicated Database (CRDB) When enabling Causal Consistency in CRDBs, the order of operations on a specific key will be maintained across all CRDB instances. For instance, if operations A and B were applied on the same key, and B was performed after the effect of A was observed by the CRDB Instance that initiated B, then all CRDB instances would observe the effect of A before observing the effect of B.

    Designing for Production

    The information in the section discusses important topics you need to know about when designing your Redis Enterprise Software cluster for a production deployment. Hardware requirements The hardware requirements for Redis Enterprise Software (RS) are different for development and productions environments. Development environment hardware requirements If you are looking to do development, test or experimentation with RS, you can use non-production hardware (e.g. laptops, desktop, small VM/instance, etc.). Item Description Minimum Requirements Recommended # of nodes per cluster One node is fine, but to utilize the advanced cluster features at least two nodes are required.

    Intercluster Replication

    Administering CRDBs Conflict Free Replicated Databases (CRDBs) provide a simple and effective way to replicate your data between one or more Redis Enterprise Software (RS) clusters. Common uses for CRDBs include disaster recovery, geographically redundant applications, and keeping data closer to your user's locations. MMR is always multi-directional amongst clusters configured in the CRDB. For unidirectional replication, see the ReplicaOf capabilities in Redis Enterprise Software. Note: CRDBs do not replicate the entire database, only the data.

    Logging and Audit Events

    Management actions performed with Redis Enterprise are audited in order to fulfill two major objectives: To make sure that system management tasks are appropriately performed and/or monitored by the Administrator(s) To facilitate compliance with regulatory standards In order to fulfill both objectives, the audit records contain the following information: Who performed the action? What exactly was the performed action? When was the action performed? Did the action succeed or not?

    Monitoring and Metrics

    Metrics Definitions Redis Enterprise Software (RS) includes many useful metrics give you a detailed picture of what is going on in the cluster, node, database, and shard. For Redis on Flash (ROF) databases, additional metrics are available. Standard Metrics Metric Components measured Description More information Connections Cluster, Node, Database Number of connections used to access the database CPU usage Cluster, Node Percent usage of the CPU Evicted objects/sec Database, Shard Number of objects evicted per second The eviction process is taken place if:

    Software Product Lifecycle

    You can view the Redis Enterprise Software subscription agreement here. This Product Lifecycle should fully reflect our subscription agreement. However, for any discrepancy between the two policies, the subscription agreement prevails. Redis Enterprise Release numbering Redis Labs uses a four-place numbering scheme to designate released versions of its products. The format is “Major1.Major2.Minor-Build”. Major sections of the version number represents fundamental changes and additions in capabilities to Redis Enterprise Software.

    Troubleshooting

    This section includes various troubleshooting tips and tricks for Redis Enterprise Software (RS). Topics: Cluster Recovery Cluster recovery in Redis Enterprise Software (RS) is used for restoring an entire cluster, usually due to a complete cluster failure. The recovery process is achieved by creating a new cluster that has the exact same configuration, databases, and data as the original cluster. At a high-level, the cluster recovery process consists of the following steps: Recovering the cluster configuration into the first node in the new cluster.