maria-discuss team mailing list archive

[Gionatan Danti <g.danti@xxxxxxxxxx>]

On 20/08/2018 21:40, Reinis Rozitis wrote:
> 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").

Ok, understood.

> 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.

Exactly.

> 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.

What puzzles me it that ext4 with data=journal *should* guarantee atomic 
writes also, but disabling doublewrites led to InnoDB corruption in case 
of mysqld crash/kill

> It has been covered in some recent Percona blog comments [2] (by some authorities in mysql world)
>
> [2] https://www.percona.com/blog/2017/12/07/hands-look-zfs-with-mysql/#comment-10968768

Thanks for the link. The problem I have with such blog is that, in the 
past, it gave incorrect information on doublewrite safety guarantees [1]
Even in the comments section of the link you posted there are users 
warning against disabling checksum (which is another can of worms, for 
sure).

Well, it seems I just need to do some in-house testing... :p
I'll report back any interesting findings.

Thanks.

[1] 
https://www.percona.com/blog/2015/06/17/update-on-the-innodb-double-write-buffer-and-ext4-transactions/

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8