aphyr

7 ms·

31.
by aphyr 10mo ago
Jepsen started as a personal blog series in nights and weekends; jepsen.io is when I started doing it professionally, about ten years ago.
32.
by aphyr 10mo ago
Ah, pardon me, spoke too quickly! I remembered that it fsynced by default, and offered batching, and forgot that the batch size is 0 by default. My bad!
33.
by aphyr 10mo ago
Yes, good call! You can batch up multiple operations into a single call to fsync. You can also tune the number of milliseconds or bytes you're willing to buffer before calling `fsync` to balance latency and throughput. This is how data
34.
Jepsen: NATS 2.12.1(jepsen.io)
432 points by aphyr 10mo ago|165 comments
35.
by aphyr 1y ago
Author here--from discussions with Capela's team, I think this sort of early testing can be remarkably helpful, because it offers a test suite that Capela's team can check their work against as they move forward. I would suggest a
36.
by aphyr 1y ago
It does indeed! This is a part of https://github.com/jepsen-io/elle , which infers totally-connected components of the transaction dependency graph. :-)
37.
Jepsen: Capela dda5892(jepsen.io)
81 points by aphyr 1y ago|14 comments
38.
by aphyr 1y ago
If I might add on to what you and Joran are both saying, after some time working with TigerBeetle, I found it useful to think of Protocol-Aware Recovery as similar to TAPIR ( https://syslab.cs.washington.edu/papers/tapir
39.
by aphyr 1y ago
And honestly--designing a generator for a system like this is hard. Really hard. I struggled for weeks to get something that didn't just fail 99% of requests trivially, and it's an (ahem) giant pile of probabilistic hacks. So I wo
40.
by aphyr 1y ago
Yeah, TigerBeetle's blog post goes into more detail here, but in short, the tests that were running in Antithesis (which were remarkably thorough) didn't happen to generate the precise combination of intersecting queries and out
41.
by aphyr 1y ago
To build on this--this is something of a novel technique in Jepsen testing! We've done arbitrary state machine verification before, but usually that requires playing forward lots of alternate timelines: one for each possible ordering o
42.
Jepsen: TigerBeetle 0.16.11(jepsen.io)
241 points by aphyr 1y ago|86 comments
43.
by aphyr 1y ago
This is a whole story unto itself. I (and a bunch of other small-site operators) actually got the chance to ask Ofcom directly about how small a site would have to be to declare itself out-of-scope of part 3/5 services, and in short: t
44.
by aphyr 1y ago
I made a lot of my furniture--it's hard to replace.
45.
by aphyr 1y ago
Thanks to you both! I've updated the article to discuss this, and we've got an update on the AWS blog too. :-) https://jepsen.io/analyses/amazon-rds-for-postgresql-17.4
46.
by aphyr 1y ago
Thank you matashii--this would definitely explain it. I've also received another email suggesting this anomaly is due to the difference in commit/visibility order between primary and secondary. Is there by chance a writeup of this
47.
by aphyr 1y ago
Yeah, that's right. It may be that the (apparent) order of transactions differs between primary and secondary.
48.
by aphyr 1y ago
This is a very good question! I do not understand AWS's replication architecture well enough to reimplement it with standard Postgres yet. This behavior doesn't happen in single-node Postgres, as far as I can tell, but it might ha
49.
by aphyr 1y ago
I have actually been working on this (very slowly, in occasional nights and weekends!) Peter Alvaro and I reported on a safety issue in RDS for MySQL here too: https://jepsen.io/analyses/mysql-8.0.34#fractured-read-like
50.
by aphyr 1y ago
Folks on HN are often upset with the titles of Jepsen reports, so perhaps a little more context is in order. Jepsen reports are usually the product of a long collaboration with a client. Clients often have strong feelings about how the repo
51.
by aphyr 1y ago
This isn't just stale data, in the sense of "a point-in-time consistent snapshot which does not reflect some recent transactions". I think what's going on here is that a read-only transaction against a secondary can obse
52.
Jepsen: Amazon RDS for PostgreSQL 17.4(jepsen.io)
608 points by aphyr 1y ago|146 comments
53.
by aphyr 2y ago
The fundamental definition of consensus already requires that some proposal will eventually (given sufficient communicating, non-faulty, non-malicious nodes) win, so that doesn't seem particularly novel: https://lamport.azur
54.
by aphyr 2y ago
I (and apparently the Confluent docs?) may be wrong about this. I've added an update to the report.
55.
by aphyr 2y ago
Apple is positively swimming in money! They could pay me! (Hi, Apple ;-))
56.
by aphyr 2y ago
Kafka actually does call these transactions! However (and this is a loooong discussion I can't really dig into right now) there's sort of two ways to look at "exactly once". One is in the sense that DB transactions are &
57.
by aphyr 2y ago
I'm not really sure how to answer this question, but even a few chapters worth of clear prose would go a long way. We lay out a bunch of questions in the discussion section that would be really helpful in firming up intended txn semant
58.
by aphyr 2y ago
Both are true, but we use "transactions" for clarity, since the semantics of consumers outside transactions is even murkier. Every read in this workload takes place in the context of a transaction, and goes through the transaction
59.
by aphyr 2y ago
I don't think so, but I've said a lot about databases in the last fifteen years haha. Sometimes I look at what people say about FDB and it feels like... folks are putting words in my mouth that I don't recognize. I was very
60.
by aphyr 2y ago
Nope. You'll find a full list of analyses here: https://jepsen.io/analyses

More ›