The Real Ramblings

In Part One of this series, I discussed what a monorepo is, defined contextual repos, and covered a review of a couple articles which attempted to illustrate the benefits of a monorepo. In this part, I’m going to go a bit deeper into some the of assertions I made, and some claims often made “in defense of” monorepos. But Google Does It, So Should You/We This is a pretty common one, and the glib response is to mutter someting about friends jumping off of cliffs or bridges.

There is a wave of argument growing among how to organize software repositories ; the god-repo (commonly known as a monorepo) and focused repositories. By and large there is no one best way. Rather it is a question of which yaks you want to shave. This is a meager attempt to explore them without a general recommendation. Definitions Any reasonable dissertation or discussion needs the terms to be well defined.

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. The Background: Redis Info Command Results When interacting with a Redis instance, you can get quite a bit of information about it using the info command, complete with several sections such memory, server, and stats.

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. Preliminaries First up I want to mention some changes to Sentinel Salvatore is already working on. Currently Sentinel opens a connection to each “logical master” from each logical master on a Sentinel.

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. Change Summary And Raison d’être You can configure it via the traditional config file method, through the API, and, though lesser known, via the command line where you prepend the directive name with ‘--’ to turn it into a command switch.

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. Update: Article updated to reflect the release of a version supporting the flushconfig command. Requirements First, let us consider the non-recoverable scenario.

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. Handling Sentinel Events First up, why use this instead of using the event subscription model?

Sometimes you need or want to connect to a Sentinel managed Redis master but would rather not manually pull the connection information from the config or API, then run redis-cli with the current information. Now you can do it easily This simple little utility, pod-connector, will let you do that, in addiition to displaying in your terminal the information Sentinel has about the pod in a more readable view than ‘grep /etc/redis/sentinel.

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. Basic Introduction The design of Codis is to have a central closer-structure repository, one or more proxies, and an “HA” component to manage master/slave failover of backend nodes.