News for hackers. Stuff that matters.
Re:KeyDB: A Multithreaded Redis Fork by xfalcox on Tuesday March 12, 2019 @01:30PM (#19370717)
If using `db-s3-object`, does KeyDB uses that as a seed on startup?

Eg: Running KeyDB on AWS, the EC2 instance fails and is replaced by another one running the same config. Will it read the last S3 dump on startup?

Re:KeyDB: A Multithreaded Redis Fork by lessclue on Wednesday March 13, 2019 @12:20AM (#19375701)
This is a nice project.

Hardcoding "aws" in the core seems like an odd choice though. Wouldn't it be better to make it agnostic and provide some sort of a trigger where a an external script or util to handle backups? That is, why S3 and why not any other service?

Re:KeyDB: A Multithreaded Redis Fork by jdsully on Tuesday March 12, 2019 @01:38PM (#19370815)
Not yet implemented. I’m hoping to get that fixed today.

I mostly use slaves for recovery with the database dumps as a last resort. So I overlooked that.

Re:KeyDB: A Multithreaded Redis Fork by xfalcox on Tuesday March 12, 2019 @01:41PM (#19370858)
Amazing!

Do you have any special config to sync to replica before accepting incoming connections in a straightforward manner?

Re:KeyDB: A Multithreaded Redis Fork by jdsully on Tuesday March 12, 2019 @01:47PM (#19370933)
Yea we have external management software we wrote. We’ve been looking into releasing this as well, but it’s not cleaned up yet.
Re:KeyDB: A Multithreaded Redis Fork by xfalcox on Tuesday March 12, 2019 @01:49PM (#19370958)
Looking forward to that. In the meanwhile I'll wait and test the S3 option when it's live.
Re:KeyDB: A Multithreaded Redis Fork by jdsully on Wednesday March 13, 2019 @04:55PM (#19383659)
I just implemented S3 loading in this change: https://github.com/JohnSully/KeyDB/commit/a45f212693956a6fb1...

Its currently in the unstable branch, once it gets shaken out a bit I'll release 0.9.3 with it included.