If you’re a programmer you’ve likely heard or read someone expound the benefits and advantages of typed code. Things like compile-time validation that you are passing an integer rather than a string, or avoiding variable type overloading, speed, and many more. However, sometimes this can lead to better code in programs other than the one you’re writing in a statically typed language.
Everything doesn’t have to be asynchronous and sometimes making something asynchronous leads to problems. The following rules and guidelines should help you minimize those problems and make proper use of asynchronous calling.
While Salvatore and I have discussed some significant changes to various aspects of Sentinel, enough to likely warrant a Sentinel version change, I wanted to capture some of the more incremental proposals we talked about during this year’s #redislondon dev day.
Redis already has one of the most extensive set of configuration options available to any data store. But we can do better. I proposed these changes at the Redis Developer Day 2015 in London this week but this is the greater detail version.
Sentinel configuration and configuration management systems don’t play well together, and neither do package management systems and the config file. As a result it is possible to have your sentinel configuration file wiped clean under a running sentinel. Here are some ways you might be able to recover your running configuration.
A little-known ability of Redis’ Sentinel mode is event based “script” execution. When so configured, Redis can call an external executable file on certain events, passing the event information on to the command. This is useful for monitoring as well as reconfiguration events. Eventilator is a small utility I’ve written to make this process easier.
In the first of this mini-series on Clustering Redis I mentioned Codis as one of the projects doing this for you. In this installment I’m going into more detail on Codis. The authors of the project have made some interesting choices, and these choices make Codis different with different requirements and implications than some of the others.
Yesterday Salvatore released the long-awaited native Redis Cluster solution as part of Redis 3.0. It takes one specific approach to building a cluster that has operational implications - clients need to know which Redis master node to talk to. The server will redirect, and can be asked directly, when the client submits a command and the client will then need to ensure it connects to the appropriate master. Essentially it is like client-side hashing where the server tells you the results.
Like most industries computer programming has cycles. One of these cycles is how we write or compile programs. We fundamentally have two methods: static vs. dynamic. Neither is perfect. Because each has benefits and drawbacks the wheel is slowly turning between which is perceived as “better” or is more common. There are changes afoot right now which to me signal the wheel is turning away from the current preference and moving toward static.
In the previous installment I discussed topics and approaches to preventing your Redis instance from becoming slow.
Now it is time to go into ways of measuring it.