Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust HELM charts to support replication #912

Closed
romange opened this issue Mar 6, 2023 · 7 comments
Closed

Adjust HELM charts to support replication #912

romange opened this issue Mar 6, 2023 · 7 comments

Comments

@romange
Copy link
Collaborator

romange commented Mar 6, 2023

No description provided.

@romange
Copy link
Collaborator Author

romange commented Apr 27, 2023

@Pothulapati I am guessing we do not need it, right?

@Pothulapati
Copy link
Member

It's confusing. If we don't support replication why do we even have a replicaCount value that allows multiple replicas to exist? 🤔 If we have a way to configure an instance to be a replica during init (i.e through command line flags, environment variables), We can configure *-0 to be master always and other instances to be replica in a static manner and get things working in a normal manner.

If we don't want to do any of that, We can close this issue 👍🏼

@romange
Copy link
Collaborator Author

romange commented Apr 27, 2023

maybe it's for horizontal scale? just deploying multiple instances of Dragonfly?

@Pothulapati
Copy link
Member

Hmm, Valid but we are still providing a single service to access any of that instances part of the horizontal scale which means with default configuration, Users can't be sure on which instance they are landing.

For deploying multiple instances, Users can deploy a helm chart multiple times with different names, namespaces. I don't think anyone would want multiple instances of Dragonfly with the same name, and Service.

I guess, We can leave it for now as it works for the normal case i.e 1 instance and allows users to do something on their own when they want multiple instances (i.e create new services, etc) or manually configure replication.

@joeky888
Copy link

joeky888 commented Jun 4, 2023

https://github.com/Enapter/charts/blob/master/keydb/templates/secret-utils.yaml#L17

for node in {0..{{ (sub (.Values.nodes | int) 1) }}}; do
      if [ "${host}" != "{{ include "keydb.fullname" . }}-${node}" ]; then
          replicas+=("--replicaof {{ include "keydb.fullname" . }}-${node}.{{ include "keydb.fullname" . }}-headless {{ .Values.port }}")
      fi
done

This is how KeyDB helm chart does. It uses a Multi-Master StatefulSet, so redis clients only have to randomly pick one of them to connect (more precisely, using the k8s Service name like keydb:6379), for example:

Pod keydb-0 will have the args --replicaof keydb-1 --replicaof keydb-2.
Pod keydb-1 will have the args --replicaof keydb-0 --replicaof keydb-2.
Pod keydb-2 will have the args --replicaof keydb-0 --replicaof keydb-1.

The interesting part is that this KeyDB chart utilized a Fully-Connected Mesh Network, it is great for a small KeyDB cluster, however, I wonder if they can provide an option to use a Ring Network.

image

@Pothulapati
Copy link
Member

Hey @joeky888 That is interesting to know! Dragonfly does not yet support replica having further replicas, and also a replication from multiple replicas. These have not been previously requested by users too so not a priority right now! But when these features exist, mesh topology seems to be the obvious default with multiple replicas on a helm chart.

@romange
Copy link
Collaborator Author

romange commented Jan 11, 2024

There are no immediate plans to support this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants