{
  "id": "edit-rerc",
  "title": "Edit Redis Enterprise remote clusters",
  "url": "https://redis.io/docs/latest/operate/kubernetes/7.8.4/active-active/edit-rerc/",
  "summary": "Edit the configuration details of an existing RERC with Redis Enterprise for Kubernetes.",
  "content": "This feature is supported for general availability in releases 6.4.2-6 and later. Some of these features were available as a preview in 6.4.2-4 and 6.4.2-5. Please upgrade to 6.4.2-6 for the full set of general availability features and bug fixes. and later.\n\nBefore a RedisEnterpriseCluster (REC) can participate in an Active-Active database, it needs an accompanying RedisEnterpriseRemoteCluster (RERC) custom resource. The RERC contains details allowing the REC to link to the RedisEnterpriseActiveActiveDatabase (REAADB). The RERC resource is listed in the REAADB resource to become a participating cluster for the Active-Active database.\n\nThe RERC controller periodically connects to the local REC endpoint via its external address, to ensure it’s setup correctly. For this to work, the external load balancer must support [NAT hairpinning](https://en.wikipedia.org/wiki/Network_address_translation#NAT_loopback). In some cloud environments, this may involve disabling IP preservation for the load balancer target groups.\n\nFor more details, see the [RERC API reference]().\n\n## Edit RERC\n\nUse the `kubectl patch rerc \u003crerc-name\u003e --type merge --patch` command to patch the local RERC custom resource with your changes. For a full list of available fields, see the [RERC API reference]().\n\nThe following example edits the `dbFqdnSuffix` field for the RERC named `rerc-ohare`.\n\n```sh\nkubectl patch rerc rerc-ohare --type merge --patch \\\n'{\"spec\":{\"dbFqdnSuffix\": \"-example2-cluster-rec-chicago-ns-illinois.example.com\"}}'\n```\n\n## Update RERC secret\n\nIf the credentials are changed or updated for a REC participating cluster, you need to manually edit the RERC secret and apply it to all participating clusters.\n\n1. On the local cluster, update the secret with new credentials and name it with the following convention:  `redis-enterprise-\u003crerc-name\u003e`.\n\n    A secret for a remote cluster named `rerc-ohare` would be similar to the following:\n\n    ```yaml\n    apiVersion: v1\n    data:\n      password: PHNvbWUgcGFzc3dvcmQ+\n      username: PHNvbWUgdXNlcj4\n    kind: Secret\n    metadata:\n      name: redis-enterprise-rerc-ohare\n    type: Opaque\n    ```\n\n1. Apply the file.\n\n    ```sh\n    kubectl apply -f \u003csecret-file\u003e\n    ```\n\n1. Watch the RERC to verify the status is \"Active\" and the spec status is \"Valid.\"\n\n      ```sh\n      kubectl get rerc \u003crerc-name\u003e\n      ```\n\n    The output should look like this:\n  \n      ```sh\n       NAME        STATUS   SPEC STATUS   LOCAL\n        rerc-ohare   Active   Valid         true\n      ```\n      \n    To troubleshoot invalid configurations, view the RERC custom resource events and the [Redis Enterprise operator logs]().\n\n1. Verify the status of each REAADB using that RERC is \"Active\" and the spec status is \"Valid.\"\n\n    ```sh\n    kubectl get reaadb reaadb-boeing\n\n    NAME              STATUS   SPEC STATUS   LINKED REDBS   REPLICATION STATUS\n    reaadb-boeing     active   Valid                        up\n    ```\n\n    To troubleshoot invalid configurations, view the RERC custom resource events and the [Redis Enterprise operator logs]().\n\n1. Repeat the above steps on all other participating clusters.\n",
  "tags": ["docs","operate","kubernetes"],
  "last_updated": "2026-04-08T12:21:52-07:00"
}