Closed JRemitz closed 6 years ago
@JRemitz Why was this closed? What should we do to setup multiple instances?
Oof. Two years. Let me see. First of all, my fork and branch are still alive here: https://github.com/JRemitz/ansible-role-redis/tree/slave-master
I closed it because it had been open with no interest or discussion to merge. I think this role is pretty straight forward to install and configure an instance, and my role seemingly introduced a lot of complexities. Maybe that’s the “why.”
Running multiple instances on a single VM doesn’t appear to be a best practice either, at least for production workloads. Better to have two smaller vms than one large one for two instances, for example. Otherwise you can have the processes competing against each other for resources. I do think there are some valuable components to my branch, like implementing the best practices recommended by Redis in the VM.
Also with multiple instances, I also have a clustering role that issues cluster commands against the inventory to make it a cluster with replicas. One of the complexities here is staggering instances so that the slave/replica are not on the same VM or there is no value if the VM crashes. But that may not be a use case you’re looking for.
Anyways, take a look if you need the source. I haven’t looked at my Private role in awhile. Scanning through I think there are some good changes embedded in it, but I might do it a little differently. Would definitely update the service templates to be drop-in updates to systemd. Good luck!
Enhancements
2) Added flexibility for different user to run Redis than default "redis" user. Useful for operational roles that support multiple technologies with a common user for simplicity.
Additional Details
Changes applied and tested preliminarily with Arch Linux, Debian, and Redhat. Debian has the unique setup where the config files are titled "redis-server" but the service is titled "redis." Rather than getting into details of a unique, default configuration, I just went with a common name for all. This is the rationale for changing the .travis.yml. I did not, but have considered adding tests for a master/slave. I'm also adding some of the default "best practices" offered by the Redis team to be included in defaults, but configurable.