Administering Redis Enterprise
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.
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.
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.
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.
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.
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.
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?
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:
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. 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. The Major1 and Major2 part of the version number are incremented based on the size and scale of the changes in each release.
Account Management You can view and update the cluster users in the cluster Settings > team page. User Roles The user roles included in Role Based Access Control (RBAC) are: 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.
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.