Thank you for your answer.

Yes, actually I think that we should be able to tolerate the failure of any server. And when a service tries to fail gracefully, I see the danger that something goes wrong and the error propagates.

But sure, despite this, having to restart mysqld with --innodb-force-recovery (potentially, several attempts with increasing values) is at best annoying.

Having a future version of InnoDB which doesn't crash for a corrupted table will also pose new problems. What will happen if some queries will be able to run, and others will not (because they access a table marked as crashed)? I guess that the problem should be detected and handled at proxy level - and the interesting part is, on the top of my head, I have no idea if this is currently possible.

So, while non-crashing behaviour is desirable, old behaviour should IMHO remain available for users who don't know how to handle corrupted tables.

About Galera... good point, actually it is very easy to make it inconsistent (at least, intentionally). So this is also something that users should definitely be able to handle. But still, when you will work at this "bug", I hope that you will find some way to avoid corrupted/incorrect data propagation.

Federico



Da: Marko Mäkelä <marko.makela@mariadb.com>
A: Roberto Spadim <roberto@spadim.com.br>
Cc: Federico Razzoli <federico_raz@yahoo.it>; Mailing-List Mariadb <maria-discuss@lists.launchpad.net>
Inviato: Lunedì 20 Novembre 2017 17:04
Oggetto: Re: [Maria-discuss] innodb and corrupted tables

Hi all,

On Mon, Nov 13, 2017 at 7:16 PM, Roberto Spadim <roberto@spadim.com.br> wrote:
2017-11-12 22:37 GMT-02:00 Federico Razzoli <federico_raz@yahoo.it>:
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