Why Database Changes Get Reverted in Kubernetes Environments

Configuration changes to Redis Enterprise Databases in Kubernetes may appear to succeed, but then get reverted by the operator during reconciliation. This article explains why this happens and how to troubleshoot it. It covers root causes, step-by-step troubleshooting, environment-specific checks, and best practices to ensure configuration changes persist.

Why Do Database Changes Get Reverted?

Reversions usually occur when the Kubernetes operator reconciles the database to match its declared source of truth. While a UI or REST API change may appear to succeed, it can be rolled back almost immediately during reconciliation. Only attributes defined and managed by the REDB controller are reconciled. If an attribute appears in the Redis Enterprise Database API specification, it is considered operator-managed and must be set in the REDB YAML.

Typical causes include:

Controller authority: The operator continuously syncs the database state to match the REDB spec.

Missing parameters: If an operator-managed attribute (for example, tlsMode) is not declared in the manifest, it is enforced with its documented default value during reconciliation.

How Configuration Changes Work

Kubernetes:

• The REDB resource definition (YAML/spec) is the source of truth.

• The operator reconciles state from the database’s set spec.

• UI or API changes not set in the database’s spec will be reverted at the next reconciliation.

  • Read more here: Redis Enterprise Database API specification

Common Scenarios

REDB: TLS setting appears to “revert”

• Situation: Database created from a REDB YAML without tlsMode.

• What happens: You enable TLS in the UI/API → the operator resets to default (disabled) during reconciliation.

• Why: Source of truth is the manifest; missing fields are reset to documented defaults. Even if the attribute was never explicitly set in the YAML, the operator enforces its documented default value during reconciliation.

• Fix: Add tlsMode: enabled to the REDB YAML and kubectl apply.

FAQ — “Why are my REDB changes getting reverted?”
If the database was created from YAML, UI/API edits to spec-managed fields (like tlsMode) are overridden by the controller. Always update the manifest and re-apply. 

Step-by-Step Troubleshooting Instructions

For Kubernetes:

• Check the YAML manifest — confirm the attribute you want to change (e.g., tlsMode, eviction policy, persistence) is set.

• Apply the manifest — update and run kubectl apply -f <file.yaml>.

• Allow reconciliation — wait 30–90 seconds for operator reconciliation.

• Avoid UI/API-only changes for REDBs — updates to attributes that can be configured within the database’s spec will be reverted.

Best Practices for Persisting Database Changes

• Always update the source of truth — edit and apply the YAML manifest. Update it accordingly if direct changes are completed with kubectl edit or oc edit.

• Avoid direct/manual changes that bypass controllers for supported attributes — they will always be reverted.

• Monitor logs

  • Check for reconciliation events that indicate overrides.

• Schedule carefully

  • Avoid changes during maintenance or auto-upgrades.

• Test in staging first 

  • Confirm persistence before applying to production.

Troubleshooting Guide: Common Issues & Solutions