[bitnami/keydb] Feature request: Add support for Active-Active replication in KeyDB Helm chart

[ibadullaev-inc4]

Name and Version

bitnami/keydb:0.1.4

What is the problem this feature will solve?

The current Bitnami KeyDB Helm chart does not provide built-in support for Active-Active (master-master) replication. Users who wish to use this replication mode have to manually configure it, which complicates the setup and maintenance. Without native support, it's harder to deploy, upgrade, and scale the KeyDB cluster in Kubernetes environments, limiting high availability and fault tolerance.

What is the feature you are proposing to solve the problem?

I propose adding support for Active-Active replication in the KeyDB Helm chart. This feature should include configuration options for enabling and managing master-master replication across nodes. Documentation on how to set up, scale, and monitor this replication mode should also be provided to ensure users can take full advantage of KeyDB’s high-availability capabilities.

What alternatives have you considered?

The alternative is manually configuring KeyDB for Active-Active replication outside of the Helm chart, which requires custom scripting and manual intervention for each upgrade or scale operation. This approach increases complexity and the risk of misconfiguration, making the system harder to manage in the long run. Having this functionality natively supported within the Helm chart would streamline operations and improve reliability.

[juan131]

Hi @ibadullaev-inc4

Active replication is supported, please take a look to the docs below:

• https://github.com/bitnami/charts/tree/main/bitnami/keydb#active-replicas

If you're looking for a multi-master setup with active replication, please check:

• https://github.com/bitnami/charts/tree/main/bitnami/keydb#multi-master---replicas

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[Kashemir001]

Hi @juan131

Looking at templated Kubernetes manifests after setting required chart values per docs provided, I can see that chart still deploys two separate statefulsets with differents configurations, one for master nodes which do not replicate each other, and another SS for replica nodes that replicate all of the masters. That contradicts KeyDB documentation on the subject, which implies that all nodes in that configuration are simultaniously a master and a replica of each other.

This prevents us from deploying a topology which would allow a client to pick a random KeyDB node from the deployment (preferably by hitting a single Kubernetes service that does load balancing between them) and not worry about any topology caveats. Consider a situation when a write operation hits one of the master nodes - that data will get replicated to all the replicas, but second master will not receive that data. Consider a write to a replica node - no other nodes use it as a replication source.

[juan131]

Hi @Kashemir001

Thanks so much for your feedback. As you mentioned, it's not possible to automatically configure this chart to have multiple masters that are replica of each other. Instead, there are "independent" master nodes and replicas are configured as active replicas of every single master nodes (hence they contain a superset of the data of all the master nodes).

IMO there's no contradiction with the docs. Please note that, as stated in the docs there are multiple topologies that can be achieved using the multi-master feature. This chart allows you to automatically configure one of them.

(...) With multi-master setup you make each master a replica of other nodes. This can accept many topologies, you could make different variations of ring topologies or make every master a replica of all other masters

[Kashemir001]

Hi @juan131 thanks for your reply

As you mentioned, it's not possible to automatically configure this chart to have multiple masters that are replica of each other.

I see, so this is by design of the chart then. That's a bummer, being able to run a full-mesh active replica topology sounds like a killer feature, well, for me at least :)

as stated in the docs there are multiple topologies

I see your point, perhaps the linked documentation isn't phrased very well. If I read these sentences as-is:

With multi-master setup you make each master a replica of other nodes.

Multiple Master setup is very similar to active replica setup, but allows more than one replica node (all masters)

I can guess that multi-master setup always suggests a "all masters are replicas, and vice-versa" configuration, or at least it's the target configuration to be achieved.

[juan131]

Hi @Kashemir001

Could you please open a new issue requesting supporting a multi-master where "all masters are replicas, and vice-versa"?

[Kashemir001]

Hi @juan131

My team currently decided against using KeyDB for our projects, therefore I have no interest in doing a feature request right now. Perhaps some other community members will be interested in that and our conversation here will help them to assess the situattion. Thanks again for clarifying!