Distributed transactions - why are transaction logs saved to disk?

Question

Database

All transactional managers (Atomikos, Bitronix, IBM WebSphere TM, etc.) save some kind of "transactional logs" in folders like "tranlogs".
When something bad happens and the server crashes, these translogs are sometimes not easy to get back up and running.
For example, it is necessary to somehow carry out a manual recovery procedure, or simply delete translogs with the threat of obtaining an inconsistent state (as they say in the docks) of the resources involved in transactions.
I'm a dumb programmer and I want to think of a two-phase transaction manager like a normal transaction manager:
1. If something goes wrong on either side (network, software error, timeout) - rollback the entire transaction with all resources.
2. The transactional manager crashes - rollback of all transactions that this TM started (apparently, by timeout at the database level).
3. File storage of translogs is not necessary if I am not going to somehow carry out automatic recovery of transactions (whatever this term means).
Question.
Why can't I think like that? Please explain in Russian.
Can I clear translogs on server restart? What am I losing?

Answer 1

There is such a fun model as MVCC .
All the fun starts when transactions start to be written on several nodes at the same time - it can be difficult to tell exactly what is outdated and what conflicts have arisen. Therefore, it is safe to delete something, without state synchronization and subsequent consistency check on all nodes, it is impossible ... all sorts of WebLogic's do not know that you have one node, and even with one node they have problems.
If we just have a power failure, then the disk cache affects it - there are RAIDs with batteries that themselves add the last transactions during power failures, though files need to be written with a special flag without caching in the OS and with a size limit ... in general, this is the only case at which you can safely restore the current state after a power failure. If you write on a "prostovin" without a buffer and batteries, you can lose the entire log.
"Just delete" is not possible due to the specificity of the transaction log consistency checks - the entire log must be applied from beginning to end. They often use specific Reed-Solomon codes for additional fault tolerance when information on the disk is corrupted, they introduce their own limitations.
Consider the Riak operation model, there Lamport marks are used to designate transactions ... just "take and delete" without consequences in a complex transactional system will not work.