What do I lose if I self-host Redis? reddit / selfhosted ---------------------------------------------------------------------- s3r3ng · 2023-11-16 19:52 How many features of Redis Enterprise are Enterprise only or can I get them with some pain points if I self-host in my own home-lab? Much of what I find in search is about various managed Redis or Redis Enterprise plans. For many of those you are actually paying a lot for inferior cloud servers or one HELLUVA LOT for resources equivalent to those in my home office. Which is a bit crazy-making. I would love Redis self-hosted on one of my home machines and accessible to a home machine exposed to the internet on 443 but tightly fire-walled. ---------------------------------------------------------------------- ElevenNotes · 2023-11-16 19:54 Depends on what you do with Redis and which features you need and how you handle high availability if needed at all? ---------------------------------------------------------------------- phein4242 · 2023-11-16 20:00 you need to ask yourself the question if you want to maintain it (including figuring out stuff that is badly documented), or that you want someone else to figure it out for you. ---------------------------------------------------------------------- s3r3ng · 2023-11-16 20:09 Along with its standard features I would like to explore its Graph DB solutions and perhaps whatever they have done for vector databases as well. I have an idle older linux workstation sized laptop with 64 GB of RAM and 2TB of NVME SSD that I could repurpose to this. So not memory or fast disk limited at all. I would like to try their Flash backed offering as well since I have the disk for it. I plan to make heavy use of pub/sub, queues, and hashes in general to among other things built an adapter for my home brewed Object Database that I have under a couple of apps in development. This is mainly geared to home lab or small business at this point. So I don't need much in HA. Fast reload from persisted data (which is backed up) would be sufficient for now. ---------------------------------------------------------------------- opensrcdev · 2023-11-16 20:48 What do you need Redis to do? If you don't even know that, then you can probably get away with self-hosting it. ---------------------------------------------------------------------- IfxT16 · 2023-11-16 21:33 It's just a key-value store in memory. What other feature you need that you cannot implement yourself? ---------------------------------------------------------------------- borg286 · 2023-11-16 23:11 Who watches the watchers? So you've got a VM with docker and you're running Redis. You have your application pointed at port 6379 on the IP address for the VM. The spice is flowing and everything is great. All of a sudden your application starts throwing 500's. Every thread in your frontend server is waiting on redis. TCP timeouts are the only thing making the user requests to your frontend server complete and the user is unhappy. YOu've tracked it down to connections made to redis. You try to ssh into that machine but your attempt at sshing in just hangs. How do you kill your VM? You then find some way to tell your VM manager to kill the VM and restart it. You don't have logs, you have no idea why redis died. You thank your lucky stars that you're using a cloud service to control your VMs and can see that the Ram slowly climbed and then plateaued and some time thereafter you had your outage. Your VM is back up and running, but docker isn't installed, so you go through the tedium of reinstalling all the dependencies, then running redis and scratch your head if you had any custom tweaks. You download redis and realize it is the version that is hot off the press. You hope that there isn't some incompatability with the redis clients. You created the redis server 2 years ago, and there have been some changes since then, but can't remember which version of redis. They said there were some critical changes in the last year, but you weren't paying attention to that channel, so it simply never crossed your mind. You make a mental note to subscribe to the email thread that redis sends out when there are new versions. But you honestly know that it won't be a priority for you to migrate your data and upgrade. This version will probably be fine for you. Redis is back up and running and the spice is flowing again. The cache is empty, so users are experiencing lots of latency as all the frontend servers are hammering the MySQL DB, but you cross your fingers that MySQL stays up while redis gets populated with cached values and latency can return back to low values. You cut a ticket to track adding a replia so you can do a failover quicker next time. Only you realize that the ram on both master and replica is increasing at the same time. Both are likely going to hit the same problem at the same time. You then realize that you need to put a TTL on all your keys. You update your application to add a TTL. You then manually clear all the data. You then see RAM increase but level off at some reasonable level. Whew!!! All good. You get back to putting out other fires. A month later more 500's. Client latency increases. Redis is maxed out on ram again. Can't ssh in. The replica looks healthy. Let's do a manual failover! telnet [10.34.223.34](https://10.34.223.34):6379 FAILOVER Now the replica thinks it is a master and can accept writes. But latency is still high!! Your clients are still connected to the old master. You update the application code and hard code [10.34.223.34](https://10.34.223.34) as the redis server it should connect to. You do a quick cherrypick and rollout. Traffic is fine, the spice is flowing. You don't know how to make clients know about both a master IP and replica IP address. You don't know how to make a client failover, only how to tell the replica to treat itself as a master, but not the clients and to send their traffic to the new host. You learn about sentinel, and that it can do failovers for you. You learn that some redis clients can be told separately of the sentinel IP addresses apart from the redis IP addresses. That these sentinel- aware clients will first check with sentinel to see who the current master is, and then to connect to that. You suppose that the library API hides away a reconnecting event. Finally you're in business. You've got 2 redis nodes, 3 sentinel (you opted for micro instances). You're feeling great. YOu've got an HA redis pair and watchers. A zonal failure occurs and now both the master, replica, and all 3 sentinel VMs go down!!!! Your application that has VMs across all of us-central1 are susceptable to a zonal failure where you stuffed all your redis servers. You spin it all up in us-central1-b, point your frontend application to that group and you're back in business, but how do you fix this long-term? You put one redis server in us-central1-a and the other in us- central1-b. But where do you put the sentinel servers? Perhaps us- central1-a, b, and one on c. There you go, you're safe from zonal failures, 2 our of 3 sentinal servers should be up at any given time (unless 2 zones go out, which the cloud provider promised would NEVER HAPPEN). Now you need to scale up. You get another VM that's bigger, hook it up as replica of the current master, manually perform a failover to the bigger node, remove the 2 dinky replicas, get another beefy VM, hook it up. Oh yeah, update the sentinel config to point to the new IP addresses. Now you need Persistance!?!?!?!? Time to learn about how frequently redis flushes, backups, restores... You ask if there is someone to save you from all this headache. comes in and asks, how about you pay me through the nose and I'll just keep redis running. If you run out of ram, you just bump the capacity. We'll take care of the rest. Your manager won't pay for another admin. You were trained in SQL, not this NoSQL crap. Yes please. Just make the pain go away. Hiring a redis expert is just too hard. Let the cloud provider do it. ---------------------------------------------------------------------- borg286 · 2023-11-16 23:25 I absolutely love Redis, if you couldn't tell. When redis went cluster I was head over heels. Dynamically add in nodes, all masters were implicitly sentinels and formed a majority quorum to elect one of its members to do a failover. Now I only had to worry about keeping redis spread across a region, doing setup, and having some background thread that would infrequently rebalance the cluster. It even handled putting a spare replica somewhere, and slotting it in when a failover happened and a node was down hard. This forced me to restrict what redis client library I could use. No problem. I love the new RESP v3 protocol with its in-memory dirty cache notifications and the Streams datastructure. That sure opens up architecture possibilities. I can use redis for tons of purposes, and as long as the Redis DB Admin understands the different ways to use redis, I could pump them out by the dozens in my company. Their overhead is dinky, they are blazingly fast(40k QPS/core), and the devs love the docs telling them that call should take O(n log m) time. I just need to frontload the work of realizing I need redis expertise in both my devs and DB admins. Redis clustering solves most of the headache from above. K8s solves it even more with its addition of StatefulSet. The thing it doesn't solve is bootstrapping. Often database clusters need a zookeeper, or etcd to provide some kind of locking service so you avoid split-brain. The only thing I've found in the k8s space is the creation of secrets, not the update operation of a secret, only the creation of one. That operation has strong guarantees that trace down to the guarantees that etcd provides. For redis cluster to get bootstrapped you need a good source of truth as to which IP address you should join, and the k8s secret is that path. ---------------------------------------------------------------------- ElevenNotes · 2023-11-17 05:45 This all works, for free. Since you only have one system I think you are not concerned about high availability?