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.mak...@mariadb.com>
A: Roberto Spadim <robe...@spadim.com.br>
Cc: Federico Razzoli <federico_...@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 <robe...@spadim.com.br> wrote:
2017-11-12 22:37 GMT-02:00 Federico Razzoli <federico_...@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 CorporationDON’T MISSM|18MariaDB User Conference February 26 - 27,
2018New York Cityhttps://m18.mariadb.com/
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
