0

MySQL InnoDB redo log block size is 512 bytes (maybe a sector in the disk). I read Are disk sector writes atomic?. It looks like it depends on the underlying hardware to decide if a sector writing is atomic. So if it's not atomic, how can InnoDB redo log guarantees that it won't be corrupted?

Say the last log block was not full in the disk, then the InnoDB engine wrote more log records to this block and flushed it to the disk. Sudden power loss caused only part of the block had been written into disk. By that the checksum of this block is mismatched. Other previous committed transactions would be lost after the server restarts.

xnervwang
  • 125
  • 1
  • 8
  • 1
    There's a fairly big long and interesting discussion on [MDEV-14425](https://jira.mariadb.org/browse/MDEV-14425) and we can see [via the implementation](https://github.com/MariaDB/server/blob/385842e15bbd51ad6cad9cf3bfb69d93d0c36921/storage/innobase/os/os0file.cc#L1319-L1325) that the OS physical block size is used (and is atomic, under O_DIRECT for linux >=3.14 (and others?)). – danblack Jan 09 '22 at 03:00
  • @danblack - Sounds like an Answer, not just a Comment. – Rick James Jan 10 '22 at 01:30
  • @danblack Thanks. I would accept your answer. – xnervwang Jan 23 '22 at 19:52

1 Answers1

0

when a transcation commit, mysql will force flush the redo log block(512b) to disk, if the log block is not full, mysql will fill the blcok with zero(zero-filling) before flush to disk.

if the flush action is success, the transcation commit will be success; if the flush action has error, the transcation commit will be fail;

so if a transcation commit is success, the transcation's redo log must has flushed to disk.

if the checksum of redo block is mismatched, it mean the redo log block flush action has error(such as power loss), the transcation of the redo log in this block must is fail.

So the commited transcation will not be lost when mysql recover from power loss, because a success transcation must flush his redo log to disk successfully.

And Last, why the redo log block size is 512 byte? because it try to use the disk atomic write(a disk sector size 512 byte) for speed up and less mismatched checksum. if the disk not support 512byte atomic write, it doesn't matter.

liliang
  • 1
  • 1
  • I think it matters. The block may have previous committed transaction. The next failed flush can corrupt the block and causes previous committed transaction loss. So I think the block writing has to be atomic. – xnervwang Jan 23 '22 at 19:52
  • @xnervwang if a block have commited transaction, the block must has been flush to disk, and after it be flushed, it will not be write any other transaction's redo log, until it be reused. – liliang Jan 30 '22 at 15:30