maria-discuss team mailing list archive

[Marko Mäkelä <marko.makela@xxxxxxxxxxx>]

Hi all,

On Mon, Nov 13, 2017 at 7:16 PM, Roberto Spadim <roberto@xxxxxxxxxxxxx>
wrote:

> 2017-11-12 22:37 GMT-02:00 Federico Razzoli <federico_raz@xxxxxxxx>:
>
>> I just noticed this old MySQL bug:
>> https://bugs.mysql.com/bug.php?id=10132
>>
>> In the comments (2005 to 2014) everyone seems to agree that current
>> behaviour should be treated as a bug.
>> The main commenter now works for MariaDB.
>>
>
That is right. And I recently filed a corresponding MariaDB bug, even
copying the title:
https://jira.mariadb.org/browse/MDEV-13542 Crashing on a corrupted page is
unhelpful


> What is currently your opinion?
>>
>
> if it execute
>
> 1: highly redundant systems. These places will tend to want an immediate total failure because their strategy tends to be to replace or reclone a slave.
>
>
> ok... it take some time to recover innodb,  but
>
> 2: less highly redundant or shared hosting. These places will tend to want to continue limited service to the maximum extent possible.
>
>
> is more interesting, we don't need to stop database, just stop table
> space/table and return an error at engine level
>

Right. I have noticed these two schools of thought, also among Linux kernel
developers. Some want to kill the system ASAP, others want to fail
gracefully.

On a redundant system, you might even want to disable redo logging to speed
up some operations. If the system crashes, you just start over.

Will this behaviour change at some point? If so, what will be the
>> consequences for Galera?
>>
>
> no idea, but it's a critical issue
>

Yes, I hope that it will be possible to fix this at some point, but
unfortunately I cannot say when. It involves extensive changes to the
InnoDB code base, to properly propagate errors up the call stack. It is not
an easy task. Maybe it is feasible to improve the reliability piece by
piece. I am afraid that it can only be done in a development branch before
it reaches beta or GA status.

At Oracle there were no resources allocated on this. The MySQL bug 10132
was closed for some time until I reopened it (in 2014, according to a
comment timestamp). If I remember correctly, the motivation to close the
bug was that MySQL 5.5 introduced the ability of marking an index corrupted
(in CHECK TABLE only, and potentially with more devastating results:
Bug#19584379 Reporting corruption may corrupt the innodb data dictionary,
fixed by me in October 2014). IIRC, also CHECK TABLE could crash InnoDB due
to a corrupted page.

When it comes to Galera, I have understood that there are other ways to
cause inconsistency between the nodes. One example ought to be enabling the
auto-recalculation of persistent statistics and then updating the
mysql.innodb_index_stats or mysql.innodb_table_stats tables from SQL.

With best regards,

Marko
-- 
Marko Mäkelä, Lead Developer InnoDB
MariaDB Corporation

DON’T MISS

M|18

MariaDB User Conference

February 26 - 27, 2018

New York City

https://m18.mariadb.com/