<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Wed, Apr 14, 2021 at 11:14 PM Frank Muller <<a href="mailto:frank.muller.erl@gmail.com">frank.muller.erl@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Many thanks Mikael. Each file role is clear now. </div><div dir="auto"><br></div><div dir="auto">But I still don’t get how the system recover from a failure. What Mnesia does in that case?</div><div dir="auto">I suppose it will check the transaction logs first. </div><div dir="auto">Please elaborate. </div><div dir="auto"><br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">To be precise: we want the database to have ACID properties around transactions. You can drill this even more down and ask what kind of consistency level you want, see e.g., Kyle Kingsbury: <a href="https://jepsen.io/consistency">https://jepsen.io/consistency</a> - so ACID is a bit hand-wavy but it'll do.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If we lose power in the middle of a transaction, we want the database to come back either with the transaction comitted or not. We don't want a halfway transaction. We could achieve this by writing all our intentions down in a log, together with commit points. When the system then boots again, we replay the log from the genesis point up until the last good transaction commit point. Everything after that point, we discard and regard as not having happened.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">However, that log might grow very large. So we want a way to circumvent indefinite growth. We can do this by keeping a snapshot of our tables on disk. Then we only need to keep a global log from the last snapshot point and forward rather than having to keep the full log available for replay. But taking snapshots is a relatively expensive operation too. So we keep a "local" log for each table. The current state is the snapshot + a replay of the local log. New transactions enter the global log first, and are then flushed out to the local logs. The next dump folds the local log into a new snapshot, so we can delete the local log and create a new local log for future changes.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Getting this to work is quite complicated, and it isn't made simpler by the fact that mnesia can also run in a distributed mode, where data is replicated among several nodes, and you have to handle several impossibility results from distributed computing.</div><br></div></div></div>