08:53:39 GMT <minus> fluffypony: it's not baked into redis
08:56:58 GMT <fluffypony> mmmkay - any suggestion wrt third-party tools for this ?
09:10:13 GMT <soveran> fluffypony: do you have the MIGRATE command?
09:10:43 GMT <fluffypony> lemme check
09:11:01 GMT <fluffypony> yes it appears so
09:11:18 GMT <fluffypony> ok so just setup a remote connection to the destination redis and use that, easy peasy
09:15:10 GMT <soveran> yes, that should do
09:24:04 GMT <minus> oh, interesting, i didn't know about that one
09:25:05 GMT <minus> this is actually pretty neat
10:22:04 GMT <dogol> i
10:22:06 GMT <dogol> hi
10:24:19 GMT <dogol> anyone can help me pls?
10:25:29 GMT <soveran> dogol: what's up?
10:29:12 GMT <dogol> i have integrated redis with tomcat and using spring framework, but when login i got an error page
10:31:38 GMT <dogol> i got an error message like "...could not initialize proxy - no session.."
11:22:43 GMT <colo-work> assuming I have a sentinel-managed bunch of redis servers, can I hook additional slaves onto the master _without_ having those slave configs also be managed by sentinel?
12:29:58 GMT <badboy_> colo-work: no
12:31:05 GMT <colo-work> badboy_, because the redis-server's slave support cannot detect when a new master is elected?
12:31:34 GMT <colo-work> or is there another reason for that?
12:31:49 GMT <badboy_> Sentinel will auto-detect all slaves and will take them under control as well
12:31:53 GMT <badboy_> what is it you want to achieve?
12:33:49 GMT <minus> it is however possible to prevent certain slaves from being elected as master. no idea what implications that has for the election process
12:33:50 GMT <colo-work> that's my problem; I'm not 100% sure yet ;)
12:33:57 GMT <colo-work> minus, I know that
12:35:17 GMT <colo-work> right now, we have a single master (without HA) and N slaves, which are local to the application servers (each app server hosts >30 processes that perform lots of redis-reads)
12:35:53 GMT <colo-work> I'd like to increase the availability of the master, while also keeping the host-local slave servers for read scalability/data locality
12:36:55 GMT <colo-work> so I was thinking I could set up a three-node sentinel setup (with three master candidates) and haproxy in front of that. haproxy would determine which master canidate actually is master (as configured by sentinel), and then I'd have all application-server-host-local slaves be SLAVEOF that haproxy listener
12:37:24 GMT <colo-work> (with slave prio 0, so that sentinel won't consider those slaves as master candidates)
12:38:51 GMT <colo-work> the host-local slave instances have a unix domain socket listener that the application servers connect to, so the app servers would not have to rely on sentinel to discover who to talk to
12:43:28 GMT <minus> colo-work: don't connect slaves to a sentinel setup using HAProxy. sentinels will see the HAProxy as redis instance, connect to it (which in turn connects to the current master) which has slave-priority ≠ 0, thus sentinel will consinder HAProxy as master
12:43:45 GMT <minus> that bit quite hard
12:44:02 GMT <colo-work> minus, I wasn't intending to tell the sentinels about the haproxy involved
12:44:24 GMT <colo-work> haproxy should serve as the listener for ordinary redis clients (that aren't even aware of sentinel being active)
12:44:45 GMT <colo-work> (I'm not sure if this works in practice as I did not try to set it up yet :)(
12:45:23 GMT <minus> you'd have local redis instances on the app servers, right? and those connect to haproxy and SLAVEOF?
12:45:44 GMT <colo-work> yes. hmm. I think I see what you're getting at....
12:46:03 GMT <colo-work> since sentinel discovers the connected slave instances from the redis master itself
12:46:08 GMT <colo-work> that's probably going to blow up
12:46:13 GMT <minus> it definitely does
12:46:19 GMT <colo-work> well, bummer
12:46:44 GMT <*> colo-work  sighs
12:47:09 GMT <colo-work> HA for stateful services is hard, I'd rather go shopping :/
12:48:06 GMT <colo-work> so it seems like I'll have to have all slaves managed by sentinel
12:48:07 GMT <minus> what's the problem with letting sentinel manage your app servers' redis instances?
12:48:19 GMT <colo-work> (and writable configs on/for all slave redis instances)
12:48:41 GMT <colo-work> minus, it amplifies the migration pain a fair bit
12:51:54 GMT <Manoj_> hi i want to remove a set of keys from my redis index, where the pattern will be intl-chahe:/{url}?{urlParams}
12:52:06 GMT <Manoj_> right now for debugging im using KEYS command
12:53:00 GMT <Manoj_> redis-cli  keys 'intl-cache:*a.html*'
12:53:04 GMT <Manoj_> gives me one result
12:53:27 GMT <Manoj_> i actually have to scan a group of urls
12:53:31 GMT <Manoj_> how can i do it?
12:54:04 GMT <Manoj_> i mean redis-cli keys 'intl-cache:*a.html| abc.html | def.html *'
12:54:26 GMT <Manoj_> i need this kind of behaviuor, what should my pattern be??
12:56:03 GMT <fheuhek> I'm using redis-rb and it raises an `InheritedError` when a children uses the same connection with the parent. However that's precisely what I want to do
12:56:12 GMT <fheuhek> how can I overcome this?
13:10:13 GMT <Kesav> Hi
13:16:40 GMT <Kesav> Hello, bit new to this . Is it this window to discuss on redis ?
13:17:34 GMT <colo-work> Kesav, yes, it is :)
13:17:40 GMT <Kesav> oh , thanks .
13:17:48 GMT <colo-work> (this "window" is commonly referred to as a "channel" on IRC)
13:19:21 GMT <Kesav> okay. Thanks colo-work. I already raised my question in REDISDB google groups. But, thought it would be bit fast to get clarified in an interactive fashion here
13:20:57 GMT <Kesav> can we bring redis-cluster as docker swarm service using overlay network  feature of swarm??
13:22:04 GMT <Kesav> I am able to bring redis cluster on docker (3 hosts) but now want to utilize swarm of docker
13:23:04 GMT <Kesav> is it possible ? after issuing "redis-trib.rc create X Y Z" ., it was getting strucked infinitely at "Waiting for nodes to join......................"
13:23:35 GMT <colo-work> I personally can't help with that, sorry. if you stick around, someone else might be able to.
13:50:53 GMT <Guest87740> Hello.  Is this the correct channel to ask questions regarding a Redis issue I am having?
14:02:14 GMT <colo-work> Guest87740, yes
14:14:39 GMT <Guest87740> colo-work, thanks.  I have a 3 node setup.  Each node has a sentinel and Redis server.  The customer I am working with I have told them not to put the sentinel on the same node as the Redis server.  They noticed if they killed the sentinel on one of the nodes and then killed the Redis server right after that the 2 remaining sentinels are not electing a new master.  The sentinels discover the down sentinel is subjectively down and the
14:15:18 GMT <Guest87740> +odown and then -odown within microseconds.  It does this several times until a failover-abort-not-elected is reported.
14:15:59 GMT <Guest87740> This is on Redis 3.2.10
14:17:57 GMT <Guest87740> I think they just need to add more sentinels as antirez reported in this issue: https://github.com/antirez/redis/issues/2284#issuecomment-69946150
14:18:31 GMT <colo-work> you do have a quorum of 2 for that master, right?
14:18:43 GMT <colo-work> (at any rate, more sentinels should do the trick, I believe)
14:21:04 GMT <Guest87740> Yes.  I believe so because it reports this: +odown master localhost localhost 6379 #quorum 2/2
14:21:30 GMT <colo-work> "localhost" seems fishy...
14:21:45 GMT <Guest87740> I put that in to hide the actual host names.
14:22:13 GMT <colo-work> OK, so you actually configured sentinel with network-wide routed names/addresses?
14:22:15 GMT <Guest87740> It was: +odown master <host name removed to protect the innocent> 10.3.48.44 6379 #quorum 2/2
14:22:23 GMT <colo-work> I see
14:22:52 GMT <Guest87740> This customer decided to fire up Docker containers.  I am aware of the issues with Docker with Redis and had them turn on host networked mode.
14:23:49 GMT <Guest87740> So each of the 3 Docker containers has a sentinel and Redis server.  I hate this setup.
14:24:07 GMT <Guest87740> I advised them to put the sentinels on the client.
14:24:55 GMT <Guest87740> Or use a script like TheRealBill to detect Sentinel outages: https://github.com/TheRealBill/redskull