This section includes various troubleshooting tips and tricks for Redis Enterprise Software (RS).
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. Recovering the rest of the nodes by joining nodes to the new cluster that replace corresponding nodes in the old cluster.
If you encounter any issues that you are not able to resolve yourself and need to contact Redis Labs support for assistance, you can create a support package that gathers all essential information to help us debug your issues. Creating a support package To create a support package: Click Support at the top right of the management UI. Click Create Support Package at the bottom of the page, and confirm the action.
Because data is being moved around across shards during the resharding process, it is impossible to report the values of some of the metrics in an accurate manner. Therefore, several database metrics are not collected, and as a result, the graph is blank when you view the database or shard metrics. Examples of metrics that are not collected during the resharding process are: Used memory Memory usage Total keys Write misses/sec Read misses/sec Expired objects/sec Evicted objects/sec Incoming traffic Outgoing traffic
Nodes in the same cluster must reside on the same VLAN. If you cannot host the nodes on the same VLAN then you must configure all ports between them to be open. For additional details, refer to network port configuration.
There might be instances in which the Replica of process repeatedly fails and restarts itself on Redis Enterprise Software (RS). This can result from the Redis "client-output-buffer-limit" setting on the source database being configured to a relatively small value, which causes the connection to be dropped. To identify this issue you can review the Redis log of the source database and find an entry in the log describing this issue.
In various scenarios, such as after creating a new cluster or upgrading the cluster, it is highly advisable to verify client connectivity to the database. To test client connectivity: Create a Redis database and get the database's endpoint, which contains the cluster name (FQDN). For additional details, refer to Creating a new database. Try to connect to the database endpoint from your client of choice, and execute commands against the database.