Am 08.12.22 um 22:32 schrieb Gordan Bobic:
On Thu, Dec 8, 2022 at 10:59 PM Reindl Harald <h.reindl@thelounge.net> wrote:
What is the net benefit of detecting said error? The way I see it, the options are: 1) MariaDB detects and error, crashes out 2) MariaDB doesn't detect an error, ingests garbage, crashes out
silent data corruption
At what layer? If at anything below, up to and including the file system level, ZFS will detect and correct it for you. MariaDB can at best only detect it for you. So catching it at a lower level wins.
The only way an error will creep in without the error checking FS spotting it is: 1) manually corrupting the block by writing garbage over it 2) MariaDB generated a duff block and wrote it out 3) Some other hardware failure corrupted the block in MariaDB memory, just before writing it to the file system
If any of the latter set happens, the data is toast anyway. If the former set happens, the data is toast anyway.
silent data corruption
At what layer?
on the database layer itself
If at anything below, up to and including the file system level, ZFS will detect and correct it for you
are you really that dumb that you don't understand that the filesystem don't matter here?
MariaDB can at best only detect it for you. So catching it at a lower level wins.
that layer can't do anything about databse internals
moron the files are fine from the viewpoint of the filessystem
At what layer?
the database layer moron
If at anything below, up to and including the file system level, ZFS will detect and correct it for you
different layer moron
moron the files are fine from the viewpoint of the filessystem
AGAIN: THE FILESYSTEM CAN'T DO ANYTHING BECAUSE IT'S NOT AFFECTED
So your argument is that the page checksum is there to tell you that your data is corrupted because of either: 1) data was corrupted by the database itself, or 2) a superuser overwriting the block on the disk
and it's impressive how long it takes until you mororn understand such basics
And in that case what exactly will the ckecksum do for you?
let you notice you have a problem and need backups
What do you gain from it? The error message that the block is corrupted just before the database crashes?
know that your data are damaged instead growing silent corruption
2) InnoDB has no checksums. Database steps on the duff block. 2.1) Database crashes during a query. You get the query and tables accessed during a stack trace. You run a check table and it finds a corrupted table. You restore it from backup
and without that over time you have no backup without the problem and even if you have one nobody wants a backup from months ago not containg any recent data
2.2) Database doesn't crash because the damage merely corrupts a single value but the record structure remains sound.
So it is that 2.2) point where the InnoDB checksum gives you anything
moron it don't matter if you find it useful - the whole point was that you pretended the filesystem can do the same with it's checksums which is nonsense