03:57:56 GMT <mightyspaj> howdy
03:58:04 GMT <mightyspaj> I'm currently learning about Redis and how it works
03:59:08 GMT <mightyspaj> the app I'm building involves real-time chat. I understand that Redis is a caching layer, but what do you do for persistence?
03:59:42 GMT <mightyspaj> I use PostgreSQL for my DB, so would you use Redis as a data layer in front of PSQL?
03:59:54 GMT <mightyspaj> so it'd look something like this:
04:01:19 GMT <mightyspaj> API call to fetch chat messages -> Redis returns data if it has it; otherwise a call is made to PSQL and Redis is populated w/ the data
07:46:12 GMT <nohitall> it doesnt make sense to use 4.1 slaves with 2.x and 3.x masters right? it could good to update the masters before
08:06:09 GMT <minus> i'm not sure redis 4 slaves even work with redis 3
08:28:56 GMT <nohitall> minus: well I want to upgrade anyway, just need some good arguments
08:29:23 GMT <nohitall> minus: implementing 3.x slaves kind of goes against my policy, I assume the replication changes in 4 are substantional and good to have
08:29:29 GMT <nohitall> well for that matter all 4 changes
08:49:59 GMT <bronge> god morning, last night i have setup an rediscluster for our webservers (thre nodes) i have 6 redis server instances running (one master and one slave) on every node and it works fine but i nead to use the rediscluster for storing my phpsessions this isnt working. I use php7.1 and redis 3.2.9 the error message is "Failed to read session data: rediscluster (path: seed[]=127.0.0.1:6379)" is ther an Bug in the php session heandler ? (sory for
08:49:59 GMT <bronge> my bad englisch ;))
08:50:55 GMT <bronge> and i use haproxy for layer7 ("balancing") to know with instance is the master on the node to write data to it
08:51:32 GMT <RemiFedora> bronge, which version of the redis extension ?
08:53:43 GMT <bronge> the version is 3.1.2-1+0~20170329213509.11+jessie~1.gbpa539c4
08:55:55 GMT <RemiFedora> seems the latest (but don'"t know how debian manage there version scheme), and 3.1.3 is broken
08:59:50 GMT <bronge> ok then i dont upgrade it to 3.1.3 ^^
09:00:16 GMT <RemiFedora> bronge, can have some value https://blog.remirepo.net/post/2016/11/13/Redis-from-PHP  (where I mostly recommend to not use the "redis" extension, and why)
09:10:24 GMT <bronge> Thanks RemiFedora but this isnt my decision :( the developer want redis ^^ (i dont know whats the reason)
09:12:42 GMT <badboy_> > This the most known and used solution, sadly, I have some doubts about the code quality of this extension.
09:12:50 GMT <badboy_> RemiFedora: I'd be interest to know what those doubts are
09:21:48 GMT <RemiFedora> badboy_, 1 recent example, update from 3.1.2 to 3.1.3 (which should be a minor patch version) is, in fact a huge refactoring, with >8k lines diff
09:22:02 GMT <badboy_> oj
09:22:05 GMT <badboy_> oh
09:22:13 GMT <badboy_> I should talk to them :D
09:22:15 GMT <RemiFedora> and 3.1.3 break lot of things (very rare case when I have te "remove" a package from my repository)
09:22:47 GMT <RemiFedora> (at least, this break "magento")
09:23:26 GMT <RemiFedora> badboy_, phpiredis is very simple (~1k lines), rely on redis library... much more robust IMHO (even if minimal feature set)
09:24:07 GMT <RemiFedora> badboy_, https://github.com/remicollet/remirepo/issues/75
09:24:25 GMT <RemiFedora> https://github.com/phpredis/phpredis/issues/1210
09:25:11 GMT <RemiFedora> reported 23days ago....
09:26:25 GMT <badboy_> so?
09:26:41 GMT <badboy_> no reproducable test case
09:27:17 GMT <badboy_> I agree that it might not be named a patch release
09:29:50 GMT <RemiFedora> badboy_, also https://github.com/phpredis/phpredis/issues/1211 (also about 3.1.3, fixed by downgrade to 3.1.2)
09:32:23 GMT <RemiFedora> btw, I would agree that user should have test the RC version... but nobody report anything with them... :(
09:32:26 GMT <RemiFedora> as often...
09:34:55 GMT <badboy_> so? warnings seem fine to me
09:35:00 GMT <badboy_> as they are ... warnings
09:44:14 GMT <RemiFedora> badboy_, I agree, but not in a patch version
09:45:26 GMT <badboy_> who says they are following semver? :P
09:45:35 GMT <badboy_> (Yes, i agree=
09:45:58 GMT <badboy_> Reason #1 why hiredis{,-*} has not seen new releases in 2 years: I can't decide on the version
10:48:20 GMT <bronge> I have it working now i have update the php-redis interface to  3.1.3 now all works fine
11:02:19 GMT <nohitall> anything I have to think about before updating from 2.8 to 3.2 oldstable?
11:08:24 GMT <bronge> my stuff is working (session handling) i dont know if the cache for object is working the developers test it tonight
12:28:12 GMT <nohitall> so I read about dump and save, but is there a way to export a single db from a redis instance and import into another instance?
12:43:36 GMT <granitosaurus> Hey I'm running v2.8 which doesn't support number argument for SPOP. What would be the most efficient way of popping multiple elements from a set then? do I just for loop in my app? I need to pop around 1k values every 5 minutes or so.
13:23:35 GMT <nohitall> I can't find any info on how to export single db from an instance, seems its not possible?
13:29:56 GMT <minus> nohitall: you can dump and then modify the dump; there's tools for that iirc
13:37:36 GMT <nohitall> minus: yea I found that, will try that
13:37:45 GMT <nohitall> minus: export to json, edit db value, import..
14:15:26 GMT <colo-work> how do sentinel instances discover each other on the network to begin gossipping?
14:17:06 GMT <minus> via the redis instances they monitor, iirc, colo-work
14:23:51 GMT <colo-work> ok, that'd make sense :)
14:26:59 GMT <colo-work> do I understand it correctly that I have to manually provide the slaves that ought to be master candidates for a given sentinel-"protected" master?
14:28:34 GMT <minus> no
14:28:57 GMT <minus> all slaves connected to a sentinel'd master are automatically candidates
14:29:12 GMT <minus> you can prevent their election using slave-priority 0 though
14:31:17 GMT <colo-work> minus, ah, but I have to initially configure the redis-server instances as slaves?
14:31:56 GMT <minus> yes
14:46:17 GMT <colo-work> given these configs and command results, can you think of a reason why my sentinels don't notice each other?  https://paste.debian.net/hidden/a9d346cf/
15:10:00 GMT <colo-work> I got it. copying a rewritten config with identical IDs per-sentinel ist bad, as it turns out.
15:28:15 GMT <minus> :)
18:52:35 GMT <JordiGH> Is a scan still O(N) if you're scanning for a key that isn't there?
18:52:38 GMT <JordiGH> Er, O(1)
19:16:53 GMT <minus> Yes, it needs to check all keys
19:21:29 GMT <JordiGH> Okay, that's what I thought.
19:21:47 GMT <JordiGH> Wait, yes to O(N) or to O(1)?
19:21:57 GMT <JordiGH> Just to make sure we understand each other.
19:28:34 GMT <minus> O(1) per scan call, O(N) for the whole keyspace. Whether it finds keys or not doesn't matter
19:30:38 GMT <JordiGH> How can it be O(1) to know there's no key?
19:30:59 GMT <JordiGH> (That matches a pattern)
19:33:37 GMT <minus> well, it still needs to scan the keyspace
19:43:23 GMT <badboy_> O(1) because it is (more or less) a constant operation per SCAN call
19:43:49 GMT <JordiGH> How does that work? How can you know that no key matches your pattern without verifying every key?
19:44:26 GMT <minus> read the docs regarding MATCH
19:44:40 GMT <minus> they explain that
20:34:17 GMT <badboy_> JordiGH: it still checks every key
20:34:32 GMT <badboy_> but per iteration it will fetch only a limited number of keys from the data set
20:35:07 GMT <badboy_> it will then check this limited amount (say M keys) against your pattern (requiring M pattern matches)
20:35:39 GMT <badboy_> which means it is O(M) for that iteration and M is small and fixed and thus it is roughly O(1)
20:35:49 GMT <badboy_> (yey, the fun of O-notation for algorithms)
20:42:37 GMT <JordiGH> minus: Are you talking about this? https://redis.io/commands/scan
20:42:44 GMT <minus> yes
20:43:02 GMT <minus> the part about MATCH specifically
20:44:09 GMT <JordiGH> I don't get it. I don't see an explanation for what it does if there is nothing at all to match and why this doesn't involving looking at every key.
20:46:20 GMT <minus> it /does/ look at every key
22:43:00 GMT <zredis> Hey I am trying to troubleshoot an issue with an redis client and notice when I check client list on our redis server I have a few connections that report the following
22:43:15 GMT <zredis> \name= age=12972172 idle=12972172 flags=d db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
22:43:48 GMT <zredis> The flags=d says that an EXEC will fail.. So why is it sitting idle like this?  If the client reuses this connection does that mean the next request it does will fail?