Clear your ACID concepts with me — Durability

 When we work with databases, there can be multiple events that go wrong. A few of them are:

1. Several clients can update the same data, leading to overwriting each other’ changes
2. Several client can read partially updated data that doesn’t make sense
3. The database can go down and lead to partial updates of write.
4. The application may crash and lead to partial updates of write.
5. Network issues can cut off both databases and applications and lead to partial write updates.

Photo by Rodion Kutsaiev on Unsplash

Databases have to deal with all these faults and avoid catastrophic failures. The safety guarantees provided by the transactions are defined by ACID which stands for

A: Atomicity

C: Consistency

I: Isolation

D: Durability

Atomicity

If the writes are grouped together into an atomic transaction, and the transaction cannot be completed (committed) due to a fault, then the transaction is aborted and the database must discard or undo any writes it has made so far in that transaction.

For more understanding of atomicity, refer to:

https://fintechcoddler.blogspot.com/2023/03/clear-your-acid-concepts-with-mepart-1.html

Consistency

I want to discuss the I and D of ACID, before jumping into this. I will surely talk about consistency in my later posts.

Let’s start

Isolation

Isolation means that concurrently executing transactions are isolated from
each other.

The database ensures that when the transactions have
committed, the result is the same as if they had run serially (one after another), even though in reality they may have run concurrently.

For more understanding of atomicity, refer to:

https://fintechcoddler.blogspot.com/2023/03/clear-your-acid-concepts-with-me.html

Durability

Durability in the database promises that once a transaction has been successfully committed, the data won’t be lost even if the database crashes or any other scenario happens.

In a single-node database, it means that data is stored on the hard drive, and also written to a write-ahead log to help in recovery if the disk gets corrupted.

In a multi-node database, it means that data has been copied to some number of nodes, which we call replication.

Replication helps to an extent because if one node gets corrupted, the other node can remain available.

But no technique can provide you with an absolute guarantee.

1. Data on the disk can get corrupted without being detected. The replicas and recent backups can also get corrupted because of it.
2. If SSDs get disconnected from power, they can start losing data within a few weeks.
3. If all your hard disks and all your backups are destroyed at the same time, there’s obviously nothing your database can do to save you.

There are various risk-reduction techniques that can be used together to achieve durability at multiple levels, but there is no guarantee.

Soon, I will be sharing the C of ACID.

Copyright © 2023 fintechcoddler.blogspot.com