[kragen]

people have been providing acid transaction semantics on single machines for 50 years

do you think ims/db ran on a cluster

the d in acid stands for durability

you're talking about pitr, which is what mysql semi-sync provides (and afaik you are correct that sqlite doesn't offer pitr)

[Spivak]

That's not what the parent means by durability, they mean having your data survive any one of your machines being instantly nuked from orbit at the most inconvenient possible time.

Just having sync replication is enough, doesn't have to be fancy like semi-sync.

[kragen]

i know that

i'm correcting their terminology

'durability' already has a well-established, rigorously-defined meaning in this context, which is confusingly similar to pitr but definitely not the same thing

the downside of sync replication, as i understand it, is that although your data will survive any one of your machines being instantly nuked from orbit, your entire service will go down; semi-sync avoids this problem

[Spivak]

But they’re using the other well-established meaning of durability a la how AWS and others describe their storage platforms. It’s pretty much the same thing but taken at whole system level. On that level an ACID database is as durable as the underlying storage medium which is sadly not very durable.

[kragen]

well, it's sort of arbitrary that the standard definition of durability requires your data to survive machine checks and kernel panics and power outages but not disk failures, isn't it

especially since nowadays in many data centers disk failures are far more common

(though full raid failures are less common)

but that is the standard definition

[xwowsersx]

Michael, is that you?

[nl]

The OPs point is that the single process ACID semantics of SQLite don't provide a durability guarantee that includes replication.

Other databases have a commit level that makes sure logs have been shipped.

For me this is an edge case in just about everything except financial transactions (the performance penalty of distributed transactions is pretty high!) but it is correct to note it.

[erik_seaberg]

Sounds like IMS runs on Z system mainframes with redundant hot-swappable CPUs and memory. They pay IBM a lot of money for the illusion of a single reliable machine, when a different OS would manage it as a small cluster.

We economize by using racks of cheap, flaky commodity hardware, but we have to be ready for one computer to die by failing each application over to another.

[kragen]

in 01973 the s/360 did not have hot-swappable cpus or memory

even in the 01990s i don't think ibm had such an offering, though tandem did (but it couldn't run ims)

[jpgvm]

it didn't run ims but it ran nonstop SQL instead which was a rdbms designed for their redundant hw architecture

[kragen]

right, i didn't mean to imply it didn't support acid