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:

    Kubernetes

    This section contains Kubernetes specific articles which cover various aspects of administering a Redis Enterprise Cluster K8s deployment. Kubernetes Operator Deployment – Persistent Volumes To deploy a Redis Enterprise Cluster with Redis Enterprise Operator the spec should include a persistentSpec section, in the redis-enterprise-cluster.yaml file: spec: nodes: 3 persistentSpec: enabled: true storageClassName: "standard" volumeSize: "23Gi” #optional Persistence storage is a requirement for this deployment type. Volume Size volumeSize is an optional definition.

    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 To add a node in Redis Enterprise Software (RS): Install the installation package on the machine that will serve as the new node. For additional details, refer to installing the setup package. In a browser, navigate to https://<name or IP address of the node on which you installed the package>:8443.

    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.

    Installing and upgrading

    This section explains how to install, upgrade and uninstall Redis Enterprise Software (RS). Topics: Installing the setup package Configuring Linux Swap CentOS/RHEL Firewall settings DNS Setup Client prerequisites for mDNS Uninstalling Upgrading Offline Installation Configuring AWS instances File Locations

    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, please 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 ensure 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 that can be tracked to give you a detailed picture of what is going on in the cluster/node/database. Below are some of the metrics for RS and Redis on Flash (RoF). Also included is a list of metrics that are important how they are computed from other metrics. For example, if I need the know the RAM hit ratio you can dive the Request served from RAM by the total number of requests.

    Redis Enterprise Software Product Lifecycle

    You can view the Redis Enterprise Software subscription agreement here. For details of the End of Life (EOL) Policy for Redis Enterprise Software, please see Software Terms PDF in the link above and look for details under "Exhibit A - Support Policy", Section #9. 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 represent fundamental changes and additions in capabilities to Redis Enterprise Software.

    Security

    Account Management You can view and update the cluster users in the cluster's Settings > team page. User Roles In Redis Enterprise Software 4.4 and above, administrative user roles as part of Role Based Access Control (RBAC) are now supported. Role Description Details Admin Has full access to the system DB Viewer Allowed to view DB configuration/metrics. All Node/Cluster information and settings are unavailable Can view info about all databases on the clusterCannot view info about nodes and clusterCan view logsCannot view cluster settings outside of changing own password Cluster Viewer Allowed to view Cluster and DB configuration/metrics.

    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.