Check out a free preview of the full Complete Intro to Databases course
The "Redis Ops" Lesson is part of the full, Complete Intro to Databases course featured in this preview video. Here's what you'd learn in this lesson:
Brian explains that, similarly to Neo4j, Redis has a primary and a secondary configuration. The preferred terms used are leader and follower.
Transcript from the "Redis Ops" Lesson
[00:00:00]
>> Let's talk about how you administrate Redis. They do also have a primary secondary kind of configuration sort of thing. Their primary terms know that they prefer a leader and follower. So you have the leader server which is one that you write to the primary. And they also have a follower server which is kind of the secondary so the one that are being replicated to from the leader.
[00:00:23]
You also see as the master and follower that's not the terms that I choose to use. But you will find master and slave in some of their older documentation, but yeah, they have since moved on to leader and follower. The leader will accept all of the rights, the followers are expected to be exact replicas of the leader.
[00:00:44]
The followers are also sometimes called replicas. If the leader and the followers lose track of each other, the followers are smart enough to actually suggest request the delta. So the actual changes between when they last saw the leader and now, right? They'll actually just request that delta and they're smart enough to kind of go through and selectively apply those updates.
[00:01:09]
If it gets too out of sync or if they just can't deal with it anymore it'll just wipe itself and totally copy a brand new copy of the leader. So suffice to say it's actually pretty sophisticated with its replication strategy. You can kind of mess with the consistency, right?
[00:01:27]
The C part of asset to say like acknowledge my right as soon as the follower sees it, or you can also go as far as saying, don't acknowledge my right until all of the followers have written it to disk has a very slow way to do it but it's possible to do it that way.
[00:01:46]
There's also a way to command, we didn't talk about that one too much or at all. But there's actually one that's called WAIT, and you can say I need this to be into at least one replica before I feel comfortable. So imagine I don't know again, you're doing like banking stuff you might feel comfortable as like I need for this to be at least written to one replica.
[00:02:09]
So that's what WAIT will do. It's for your highly important stuff. Let's talk about Redis Cluster for a second. Redis Clusters is shanding but for Redis it'll take your keys and shand them out amongst the different pockets of replicated leaders and followers. This is how you're gonna start handling terabytes or at least gigabytes of key value stuff.
[00:02:38]
It will make your Redis deployment less consistent, which is usually a trade off that you have to be willing to make. So it has a higher chance of dropping rights on accident, which is not good. But the trade off that you're making here is that Redis can scale to be much, much larger.
[00:02:56]
So you need to think about that. That feature is called cluster, Redis cluster. And there's another cool feature called Redis Sentinel. So Redis Sentinel does what's called self healing. We haven't talked a lot about self healing, but it's a really hot topic in operations. What that means is like let's say you have one follower and four leaders, sorry other way around.
[00:03:21]
You have one leader and four followers and Redis suddenly detects that one of your followers is dropping rights, it's latencies spiking, it's running out of disk space. What you can do with Redis Sentinel is like it can see that before it actually starts becoming a problem. So it's actually like a sentinel, right?
[00:03:41]
It's watching all the vitals of all these different servers. Before it becomes a problem, you can rotate that server out of rotation, put in a brand new follower, and then you can kind of continue on as if nothing had ever happened. It can do this kind of self healing.
[00:03:58]
And so your operations persons or you don't have to get paged it actually just gets fixed before it even becomes a problem. That's called Sentinel. It's self healing Redis. It also has a bunch of charts and graphs and metrics that let you know how much they're being written to, how much they're being read out of, what queries are very old, which ones never get run.
[00:04:20]
Bunch of stuff like that. So Redis Sentinel, if you can be running a lot of Redis is very helpful. So a big key with this is with Sentinel, you want these servers to live independent of each other. So usually that's gonna be like cross region. And what's cool about that, is if you have some of your servers in US West, some of them in US East, some of them in I don't know where else regions are, Europe, you can have them in, [COUGH] various different other places.
[00:04:46]
The Sentinel can actually see those across regions. And if they can see that US West is going down, it can move all of your servers automatically to US East and really compensate for that particular problem. So yeah, it means you can survive regional downtime, which is a big deal.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops