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)
Just having sync replication is enough, doesn't have to be fancy like semi-sync.
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
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
We save 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.
even in the 01990s i don't think ibm had such an offering, though tandem did (but it couldn't run ims)
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.
Instance can be process, container or machine.
If your db does lots of work, I buy new ones, install them in the datacenter, bring them up from backup.
BTW: you skipped a step for a busy database: warming it up with shadow traffic.
Under certain scale just switching like you describe will cause just as much downtime.
Regression via a code or dependency update? Full disk? DNS is down? Too much load? All of these would bring down both servers in quick succession.
I guess something like a "once every 2 days" race condition could buy you some time if you had a 2nd server. But that's not a common error
I like your statelessness point. I suppose in your view it’s better to have the concentrated stateful core with stateless servers as opposed to just one stateful instance. Two instances mean you can’t easily store foo in memory and hope the server doesn’t die until it’s not needed there anymore. Counterpoint is that the extra layer of indirection is 10x slower and horizontal scaling won’t be needed as much if you don’t pay that price in the first place, but you are right, the temptation to store foo in memory would still be in its prime. The thing is, if one machine can scale, putting foo in memory isn’t actually bad. It’s only when things don’t scale that it’s bad.
Absolutely not and I can't understand why I keep hearing this argument. Doing zero downtime upgrades on a single server have been simple since basically forever, run another process on another port, change config, restart front balancer gracefully and there you go.
It could be bad hardware, it could be bad query (left dangling/canceled on old instance), could be bad statistics and unlocks disk fragmentation etc etc.
Spinning disks and all, I was terrified to reboot them and have the boot disk fail (which was not on RAID).
The main disks failed once or twice which slowed the servers down considerably until rebuild of the raid finished. Very nervous time.
This caveat covers "most cases". If there's only a single machine, then any data stored is not durable.
Additionally, to my knowledge SQLite doesn't have a solution for durability other than asynchronous replication. Arguably, most applications can tolerate this, but I'd rather just use MySQL with semi-sync replication, and not have to think through all of the edge cases about data loss.