Is there a breakpoint when a database transaction gets corrupted?

Question

I am wondering how database transactions are “typically” implemented in a database system such as MySQL.

Assuming that actually writing data to the physical storage of the database is not an atomic operation (now we are talking about a clock-cycle), should I spoil the transaction, for example, breaking the power cable at some carefully chosen moment?

Answer 1

If the database system is carefully written, there should be no point in time when a power outage can ruin the data, and when a power outage occurs, no committed data will ever be lost.

rdbms first writes data to the transaction log before actually updating the data. After a failure, it repeats the log, copies any pending changes from the log to the database, and rolls back any transactions that were not completed in the log. Commit is considered successful only after the hard drive reports a completed logging operation.

Answer 2

Databases follow ACID properties. Regardless of when something explodes, there is a way to at least return to a known correct state.

Answer 3

It is well known that a database writes logs during an update. Then he can say that he failed to complete his work as a single transaction and use the logs for ROLL BACK changes.