Live data from Hacker News

Reply to Aphyr attack on Redis Sentinel

antirez.com

1–10 of 42 posts

Re: Reply to Aphyr attack on Redis Sentinel

#4
Tangentially related:

In the PostgreSQL evaluation[0], Aphyr noticed that, if a packet confirming a transaction is dropped, the client ends up in a deadlock.

Does PostgreSQL keep a record of the past transactions, and their success or failure. If so, is it possible to query it?

[0] http://aphyr.com/posts/282-call-me-maybe-postgres

Re: Reply to Aphyr attack on Redis Sentinel

#5
post #3
post #2

A response to this article on Redis: http://aphyr.com/posts/283-call-me-maybe-redis

His continued use of "CP" confused me for a while, so TIL about CAP Theorem http://en.wikipedia.org/wiki/CAP_theorem

And better: http://henryr.github.io/cap-faq/

Re: Reply to Aphyr attack on Redis Sentinel

#6
post #3
post #2

A response to this article on Redis: http://aphyr.com/posts/283-call-me-maybe-redis

His continued use of "CP" confused me for a while, so TIL about CAP Theorem http://en.wikipedia.org/wiki/CAP_theorem

If you have the time, this video by Basho's CTO will give you a much better understanding of the tradeoffs that are involved in distributed system design: http://www.infoq.com/presentations/Concurrency-Scale-Distrib...

A great alternative to thinking about things in terms of CAP that Justin brings up is harvest-yield, where yield is the probability of completing a request and harvest is the fraction of your data that the response actually represents. Here's the paper: http://lab.mscs.mu.edu/Dist2012/lectures/HarvestYield.pdf

Re: Reply to Aphyr attack on Redis Sentinel

#7
post #4

Tangentially related: In the PostgreSQL evaluation[0], Aphyr noticed that, if a packet confirming a transaction is dropped, the client ends up in a deadlock. Does PostgreSQL keep a record of the past transactions, and their success or failure. If so, is it possible to query it? [0] http://aphyr.com/posts/282-call-me-maybe-postgres

Yes, you can recover from lost acknowledgements by asking for the transaction ID from postgres before committing--or by making up your own flake ID and writing it to a table. Given a queue with at-least-once delivery (which includes, say, durable storage on the client), you can check for the presence of that ID at a later time and re-apply the transaction to recover from network errors safely.

The transaction ID does wrap around, so there's a time limit depending on your transaction throughput. You can also ask for certain transactional properties on rows, though this won't allow you to recover in all (most?) cases.

Re: Reply to Aphyr attack on Redis Sentinel

#9

Redis is one of those things I both love and love to hate. I've had good results using Redis as a lock server, but I live in (perhaps misplaced) fear of a client hanging or crashing leaving a lock stranded. Not that this is really Redis's problem.

Hello, you can easily mount a lock that auto-releases itself after some timeout using the new (2.6.13) extended SET command (see http://redis.io/commands/set) or simply a Lua script.

Re: Reply to Aphyr attack on Redis Sentinel

#10
I'm frustrated that when the HN editors deduped the original story, they apparently deleted ALL the instances, leaving only this one. I wanted to read the discussion on the subject of Aphyr's research, not Antirez' response.

It looks bad, HN. We all know that VMWare is litigious as (try looking up benchmarks sometime.) But to (presumably) cave so quickly and effortlessly suggests... well, I'm not sure.

The other possibility is that Aphyr yanked them himself, probably under duress (or else there'd just be an 'update' at the bottom of the research's page.) Aphyr, is this what happened? I figure you probably can't talk freely if so, but say something.

Post reply on HN