3 ms·
not corrupt != everything is peachy At the very least, you need to be prepared for a possibly very long replay of logs. Also, a huge number of people run datab
by btmorex 12y ago
not corrupt != everything is peachy
At the very least, you need to be prepared for a possibly very long replay of logs. Also, a huge number of people run databases in a configuration that doesn't make those guarantees. For example, many people will run mysql (esp. less performant slaves) with innodb_flush_log_at_trx_commit = 0 for performance with the understanding that a failure might require manual fixes.
- seunosewa 12y agoA failure with that parameter will only cause transactions committed in the last second to be lost. The DB won't require manual fixes.
- spudlyo 12y agoThe DB won't require manual fixes. Losing a transaction that was committed upstream can lead to a bunch of manual fixes in replicated database clusters. What happens if rows inserted in that lost transaction are eventually updated? Replication breaks, you get paged, and now you're faced with either manually fixing the DB consistency error or by rebuilding the whole slave. Woe be unto you if this host is a replication hub with a bunch of slaves hanging off it.