08:44:51 GMT <ernetas> Hey guys.
08:45:13 GMT <ernetas> I have appendonly no and yet Redis keeps writing aof file even after rebooting the whole host. Why?
08:45:38 GMT <ernetas> It slowly consumes all my disk space and the rewrite from scratch does not seem to be taking place.
09:36:25 GMT <nnog> Anyone else having problems with sentinel 3.2.1 discovery?
09:37:33 GMT <nnog> issuing the same monitor command on 3 sentinels in a 3-sent, 1-master setup, and they are not connected, and all report sdown, and ofc no gossip discovery of the other sents
09:38:28 GMT <nnog> doing CLIENT LIST and INFO in the master shows no sentinel clients are connecting or have connected
09:39:02 GMT <nnog> is there a regression here? Pretty much deployed exactly the same way as my previous v3.0.4 setup
09:40:14 GMT <nnog> unit tests passed when I built, and I checked that I have "bind *" in my configs to disable the new "protected mode" with the old-style bind behaviour
09:45:37 GMT <nnog> This setup is all on a single host too, so not sure why sentinel is not making connections to anything... @antirez ?
09:51:05 GMT <nnog> aha, ok so when I enable debug logging, I see -cmd-link-reconnection master Test 164.xx.xx.xx 6513 #Can't get addr: Name or service not known
09:52:44 GMT <nnog> that's weird, I'm using the same IPs as before, and putting the same addr and port into $ ./bin/redis-cli -h 164.xx.xx.xx -p 6513
09:53:21 GMT <nnog> has name discovery in sentinels changed in 3.2 since 3.0?
09:53:42 GMT <nnog> name resolution, I should say
10:02:18 GMT <antirez> nnog: did you checked the redis / sentinel instances are able to see each other? Maybe it's the new protected mode or some firewalling not allowing them to talk.
10:02:43 GMT <antirez> Make sure that, from Sentinel machines, you can do: redis-cli -h <master_host> -p <master_port> and correctly talk with Redis instances
10:03:57 GMT <nnog> yep, that works. Also this test setup is just a single machine
10:04:16 GMT <nnog> I'm doing "bind *" on both sentinels and server
10:07:13 GMT <nnog> i.e. I can, from the same host, do redis-cli -h <ip> -p <port> where the IP and port matches the result of: redis-cli -h <same IP> -p <sentinel 1 port> sentinel get-master-addr-by-name Test
10:08:56 GMT <antirez> nnog: are you using hostnames instead of IPs?
10:09:10 GMT <nnog> no, full addresses
10:09:42 GMT <nnog> i.e. what I get for $ getent hosts $HOST
10:09:44 GMT <antirez> I can't think at anything that can prevent Sentinel to connect to Redis. The only way is to perform in your side the inspection needed to narrow the problem to something I can check/address
10:10:25 GMT <nnog> ok, so nothing should be different between the sentinel connection and the redis-cli connection then?
10:10:57 GMT <antirez> nnog: no... should be the same, Sentinel is for Redis just a client, there is no special meaning in a Sentinel connection
10:11:01 GMT <antirez> so there must be something that either
10:11:07 GMT <antirez> 1) Prevents the connection from succeeding.
10:11:16 GMT <antirez> 2) Or that stops Sentinel to try to connect at all
10:17:09 GMT <nnog> Ok, thanks, antirez. I'll do some digging and swap some binary versions to see what's happening. Sentinel is definitely trying though. Every second I get -cmd-link-reconnection and -pubsub-link-reconnection errors
10:17:12 GMT <nnog> in sentinel log
10:23:09 GMT <antirez> nnog: oh, that's interesting
10:23:29 GMT <antirez> nnog: can you easily try if reverting to 3.2.0 fixes it?
10:24:10 GMT <nnog> actually just trying 3.0.4 just to check my config, because that used to work for me
10:24:17 GMT <nnog> but I'll do that next
11:12:50 GMT <nnog> antirez: I found cause of the problem. When I changed from 3.0 to 3.2 I added "bind *", which I thought would be the old behaviour, since redis was putting *:26379 in the process name, but actually I need "bind 0.0.0.0" on the sentinel to be able to connect
11:13:31 GMT <nnog> I didn't realise these were different? anyway, I saw the same issue when explicitly setting "bind *" in the sentinel in 3.0.4
11:16:05 GMT <nnog> the master server itself works fine with "bind *". Right now, I'm back to running 3.2.1 with "bind *" in server and "bind 0.0.0.0" in the sentinel and the problem has gone away.
11:26:07 GMT <nnog> I'll double check everything works in my usual deployment, but this seems to solve my issues. Thanks for your help, @antirez
13:18:45 GMT <antirez> nnog: "bind *" was never supported, I'm not sure how it does not exit with an error.
13:18:59 GMT <antirez> Btw glad you fixed it
13:19:21 GMT <antirez> But, the right method is to comment "bind" at all, in order to bind everywhere
13:19:34 GMT <antirez> And se protected-mode no
13:19:39 GMT <antirez> s/se/use/
13:19:53 GMT <antirez> or, if you want, you can bind explicitly the network interfaces you want. Your pick.
13:20:48 GMT <nnog> antirez: ah, okay. I figured just setting just the bind option would be a more backwards-compatible config, in case I wanted to start up an older server version
13:23:07 GMT <nnog> "bind *" works just fine for the server btw, but I'll probably go with bind 0.0.0.0 for consistency (we're behind firewalls) and setting protected-mode no, as you suggest
13:24:14 GMT <nnog> oh, you're suggesting not setting bind at all. gotcha.
13:34:39 GMT <antirez> nnog: if you specify "bind 0.0.0.0" protected mode is off by default AFAIK
13:34:57 GMT <antirez> nnog: protected mode is only automatically enabled if there is no clear binding directive AND there is no password set on the server.
13:35:11 GMT <antirez> It's just a feature to avoid unwanted instances on the internet
14:39:46 GMT <marcv> Hi. I've got a List of 100 latest messages in a chatroom, as strings. I want to eliminate invalid messages, based on a check with PHP (it's not just searching a substring). How can I make sure that between the time I "LRange 0 -1" the 100 substrings and the time I've eliminated the last of the invalid messages, no new message has been added to the List?
14:45:49 GMT <minus> a lock probably, but maybe you should ask yourself if what you're doing even makes sense
14:48:15 GMT <marcv> minus: thanks minus. What makes you think it does not make sens?
14:49:58 GMT <minus> because you need to block the key from being modified, that can probably be solved better
14:53:52 GMT <marcv> minus: Well, each chat message is actually a json object. Inside the Json object, I must check a specific key => value to see it this message was a comment to another message that has been deleted (and in this case remove it). Do you see a better way to do this ? Is there an obvious better way to you ?
14:54:13 GMT <marcv> I'm taking any advice :-)
14:54:57 GMT <minus> shouldn't you check that stuff on insert?
14:56:19 GMT <marcv> Let's say I create a message #2 which is a comment on message #1. Then the chatrrom admin deletes message #1. I then want that message#2 be deleted in the process
14:57:42 GMT <marcv> I don't see any other way than checking every one of the latest 100 messages to see if any of them is a commenton message #1. And then delete it.
14:58:18 GMT <marcv> But if in the meantime someone adds a comment on message#1, it won't be deleted
14:58:22 GMT <marcv> this is the problem
14:58:44 GMT <minus> aye
14:59:10 GMT <minus> you could use a lua script to do the recursive deletion
15:00:12 GMT <marcv> I thought of that but I actually hoped there would be a solution that did not involved learning a new language :-D
15:00:53 GMT <marcv> but i'm afraid I'll have to do it.
15:01:00 GMT <marcv> Thanks for your help
15:04:22 GMT <minus> well, it shouldn't be very much, right? redis' lua even has json support
15:06:10 GMT <marcv> shouldn't be very much. I hope so ^^ I don't know anything about Redis scripting
15:43:38 GMT <mickkelodeon> Hi
15:44:25 GMT <mickkelodeon> I have a doubt, how’s redis managing expirations ?
15:45:00 GMT <mickkelodeon> I mean, how does it work behind the scenes?
15:46:25 GMT <mickkelodeon> is there a thread or something checkig that?
15:54:20 GMT <mickkelodeon> ….ok, thanks
16:11:15 GMT <minus> np