09:00:48 GMT Hi 09:01:07 GMT am still battling with migrating my redis data to another redis server 09:01:09 GMT any help? 09:19:42 GMT cannot you just copy data file over or..? 09:27:29 GMT domeh_: that will override existing data on the other server 09:47:24 GMT ok so with migration you mean copying only data that is not already there 09:48:29 GMT cannot think of anything else but creating script that connects to both servers, gets all keys from source server and adds them to target server if key doesn't exist or something similar 09:50:24 GMT ok 10:57:23 GMT likely someone has already needed to do this 10:57:25 GMT e.g. http://stackoverflow.com/questions/23222616/copy-all-keys-from-one-db-to-another-in-redis 12:37:32 GMT hi all. just wondering if someone can point me to an article or resource that will help me understand the impact of using a very high value in the "count" property when doing a scan command. 12:37:56 GMT for example, I can call a recursive lua method i wrote that will call the redis scan command "n" times until I get a cursor value of 0. 12:38:19 GMT or... i can supply a value in "count" that's really high... and get everything in one shot. 12:38:29 GMT i'm trying to figure out what is more performant. 12:39:08 GMT in my case, for this particular method,I don't need paging ... and so it's actually better for me to get everything in one shot. The result set I'm expecting will never exceed 10 records. 13:55:39 GMT cpama: SCAN/KEYS is bad because it needs to scan the entire key space, so the number of results you get from SCAN/KEYS doesn't really matter, it still needs to scan the entire keyspace 13:56:07 GMT hm. i remember reading that KEYS is bad... but I thought SCAN was ok. 13:56:09 GMT :/ 13:56:38 GMT SCAN with a huge count is the same as KEYS 13:59:06 GMT minus - I see. so if scan has to be used... it is better to use a lower value in count... is that correct? 13:59:26 GMT the larger the value, the longer redis is blocked 13:59:33 GMT ah ok. 13:59:41 GMT the lower the value, the more iterations you need 14:00:02 GMT k. thanks minus 14:00:19 GMT you should look into doing that differently, without needing SCAN/KEYS 14:00:30 GMT (if it's for anything more than debugging) 14:01:19 GMT that's the problem minus. 14:01:34 GMT i'm using redis to look up routing rules based on time 14:01:41 GMT so my keys actually represent time ranges. 14:01:44 GMT for example: 14:01:48 GMT that was the phone number stuff, right? 14:01:54 GMT yeah exactly 14:02:07 GMT so short of creating a routing rule for every minute / second of the day... 14:02:17 GMT i have to use ranges 14:02:48 GMT based on your experience, what's a reasonable "count" value to start with ? 14:02:59 GMT so you have keys like :