maria-discuss team mailing list archive

["Reinis Rozitis" <r@xxxxxxx>]

> What I means is that while a ZFS write is an all-or-nothing affair, it can write
> partial data from the application (mysqld) point of view. What it needs is a
> partial data from the application itself (ie: a crashing
> mysqld) - garbage in, garbage out. Doublewrite *shoult* catch that (ie:
> at restarting, mysqld would read the double buffer, detect it as corrupt and
> discard it while not touching at all any previous data on main database files).
> 
> My understanding (which *can* be wrong) is that MariaDB "atomic write
> support" is a mean to inform the underlying device of the entire write process
> and to keep new data on "spare" location until the application itself (mysqld)
> commits the *entire*, verified write, enabling the hardware device to atomically
> swap/remap the affected data locations. In this case, a failed mysqld process
> will never reach the "commit phase", leaving the old data untouched.

I reread my previous mail and I have been a bit unclear - what I wanted to say that turning off doublewrite feels (at least for me) safe enough (compared to other disasters you could get into), but it's not 100% safe. (commenting on the initial "From my understanding, disabling doublebuffer is really 100% safe only when enabling atomic writes"). 

For the application (mysql) itself to perform any sort of checksum (after a crash boot) and possibility to recover you have to write (and keep until the second write is acknowledged) data twice anyways hence the doublewrite buffer. 

Those atomic write hardware bits the same as ZFS [1] just ensure that any write either lands on the metal (which also tend to lie - write caches on drives/controllers, silent errors, bit rot etc) or not. If the application itself issues a 4KB write when it actually needed to write 8KB.

It has been covered in some recent Percona blog comments [2] (by some authorities in mysql world)


So to answer your initial mail - it's not 100% safe ;)


[1] https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSTXGsAndZILs  
[2] https://www.percona.com/blog/2017/12/07/hands-look-zfs-with-mysql/#comment-10968768  


rr