[Maria-discuss] WHY re TMM files never removed in 10.0.x
i was flooded once again with mcron-mails "ERROR 144 (HY000) at line 1: Table './asterisk/cdr' is marked as crashed and last (automatic?) repair failed" well, because mariadb creates such temp files and don't remove them which makes myisam-recover-options = "FORCE" useless -rw-rw---- 1 mysql mysql 0 2015-08-21 13:47 cdr.TMM MariaDB [asterisk]> optimize table cdr; +--------------+----------+----------+------------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +--------------+----------+----------+------------------------------------------------------------------------+ | asterisk.cdr | optimize | error | Can't create new tempfile: '/Volumes/dune/mysql_data/asterisk/cdr.TMM' | | asterisk.cdr | optimize | status | Operation failed | +--------------+----------+----------+------------------------------------------------------------------------+
Hi Reindl, On 22.08.2015 13:20, Reindl Harald wrote:
i was flooded once again with mcron-mails "ERROR 144 (HY000) at line 1: Table './asterisk/cdr' is marked as crashed and last (automatic?) repair failed"
well, because mariadb creates such temp files and don't remove them which makes myisam-recover-options = "FORCE" useless
Please check https://mariadb.atlassian.net/browse/MDEV-8475, it's probably the same problem that you are experiencing. If so, it's fixed in 10.1.6. Regards, /E
-rw-rw---- 1 mysql mysql 0 2015-08-21 13:47 cdr.TMM
MariaDB [asterisk]> optimize table cdr; +--------------+----------+----------+------------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text | +--------------+----------+----------+------------------------------------------------------------------------+
| asterisk.cdr | optimize | error | Can't create new tempfile: '/Volumes/dune/mysql_data/asterisk/cdr.TMM' | | asterisk.cdr | optimize | status | Operation failed | +--------------+----------+----------+------------------------------------------------------------------------+
_______________________________________________ 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
Am 22.08.2015 um 14:37 schrieb Elena Stepanova:
Hi Reindl,
On 22.08.2015 13:20, Reindl Harald wrote:
i was flooded once again with mcron-mails "ERROR 144 (HY000) at line 1: Table './asterisk/cdr' is marked as crashed and last (automatic?) repair failed"
well, because mariadb creates such temp files and don't remove them which makes myisam-recover-options = "FORCE" useless
Please check https://mariadb.atlassian.net/browse/MDEV-8475, it's probably the same problem that you are experiencing. If so, it's fixed in 10.1.6.
sounds similar this really needs to be fixed in 10.0.x and was introduced with 10.0.x
-rw-rw---- 1 mysql mysql 0 2015-08-21 13:47 cdr.TMM
MariaDB [asterisk]> optimize table cdr; +--------------+----------+----------+------------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text | +--------------+----------+----------+------------------------------------------------------------------------+
| asterisk.cdr | optimize | error | Can't create new tempfile: '/Volumes/dune/mysql_data/asterisk/cdr.TMM' | | asterisk.cdr | optimize | status | Operation failed | +--------------+----------+----------+------------------------------------------------------------------------+
Hi Reindl, On 22.08.2015 15:42, Reindl Harald wrote:
Am 22.08.2015 um 14:37 schrieb Elena Stepanova:
Hi Reindl,
On 22.08.2015 13:20, Reindl Harald wrote:
i was flooded once again with mcron-mails "ERROR 144 (HY000) at line 1: Table './asterisk/cdr' is marked as crashed and last (automatic?) repair failed"
well, because mariadb creates such temp files and don't remove them which makes myisam-recover-options = "FORCE" useless
Please check https://mariadb.atlassian.net/browse/MDEV-8475, it's probably the same problem that you are experiencing. If so, it's fixed in 10.1.6.
sounds similar
this really needs to be fixed in 10.0.x and was introduced with 10.0.x
There are two parts of the problem: that these stale files appear at all, and that they are not removed. MDEV-8475 describes and fixes the second part, and it exists at least in 5.5 as well, both MySQL and MariaDB, so it was not introduced in 10.0.x. I suppose Monty had good reasons to fix it only in 10.1; but since there seems to be a strong interest in this bugfix for 10.0, maybe he will want to reconsider. There is, however, still the first part, why these files appear. We have a separate JIRA issue for it, https://mariadb.atlassian.net/browse/MDEV-8571 -- still open with no good way to reproduce. It is quite possible that *this* was indeed introduced with 10.0.x, at least that's when people started observing it. If you have any information on it, especially if you know how to reproduce it reliably, please comment on the bug report (or here, if you so prefer). Regards, Elena
-rw-rw---- 1 mysql mysql 0 2015-08-21 13:47 cdr.TMM
MariaDB [asterisk]> optimize table cdr; +--------------+----------+----------+------------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text | +--------------+----------+----------+------------------------------------------------------------------------+
| asterisk.cdr | optimize | error | Can't create new tempfile: '/Volumes/dune/mysql_data/asterisk/cdr.TMM' | | asterisk.cdr | optimize | status | Operation failed | +--------------+----------+----------+------------------------------------------------------------------------+
_______________________________________________ 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
Am 22.08.2015 um 15:02 schrieb Elena Stepanova:
Hi Reindl,
On 22.08.2015 15:42, Reindl Harald wrote:
Am 22.08.2015 um 14:37 schrieb Elena Stepanova:
Hi Reindl,
On 22.08.2015 13:20, Reindl Harald wrote:
i was flooded once again with mcron-mails "ERROR 144 (HY000) at line 1: Table './asterisk/cdr' is marked as crashed and last (automatic?) repair failed"
well, because mariadb creates such temp files and don't remove them which makes myisam-recover-options = "FORCE" useless
Please check https://mariadb.atlassian.net/browse/MDEV-8475, it's probably the same problem that you are experiencing. If so, it's fixed in 10.1.6.
sounds similar
this really needs to be fixed in 10.0.x and was introduced with 10.0.x
There are two parts of the problem: that these stale files appear at all, and that they are not removed.
MDEV-8475 describes and fixes the second part, and it exists at least in 5.5 as well, both MySQL and MariaDB, so it was not introduced in 10.0.x. I suppose Monty had good reasons to fix it only in 10.1; but since there seems to be a strong interest in this bugfix for 10.0, maybe he will want to reconsider.
There is, however, still the first part, why these files appear. We have a separate JIRA issue for it, https://mariadb.atlassian.net/browse/MDEV-8571 -- still open with no good way to reproduce. It is quite possible that *this* was indeed introduced with 10.0.x, at least that's when people started observing it. If you have any information on it, especially if you know how to reproduce it reliably, please comment on the bug report (or here, if you so prefer)
at least i faced this the first time after upgrade from 5.5.x to 10.0.x given that we have around 30 MariaDB instances it's a strong indicator that with 10.0.x it got much worser and more likely to happen each time on production machines with the same errors in the logfile and each time the "repair table" seems to have worked and a followed "optimize table" failed until i found out that this file exists well, we have scripts checking the overhead of tables nightly and optimize them if it's larger than 100 KB and try to do this on random selected number of tables to not impact caches too much, likely because of that it gets more visible, but these scripts existing for many years starting with MySQL 5.0 in 2006 or so
Am 22.08.2015 um 15:36 schrieb Reindl Harald:
Am 22.08.2015 um 15:02 schrieb Elena Stepanova:
Hi Reindl,
On 22.08.2015 15:42, Reindl Harald wrote:
Am 22.08.2015 um 14:37 schrieb Elena Stepanova:
Hi Reindl,
On 22.08.2015 13:20, Reindl Harald wrote:
i was flooded once again with mcron-mails "ERROR 144 (HY000) at line 1: Table './asterisk/cdr' is marked as crashed and last (automatic?) repair failed"
well, because mariadb creates such temp files and don't remove them which makes myisam-recover-options = "FORCE" useless
Please check https://mariadb.atlassian.net/browse/MDEV-8475, it's probably the same problem that you are experiencing. If so, it's fixed in 10.1.6.
sounds similar
this really needs to be fixed in 10.0.x and was introduced with 10.0.x
There are two parts of the problem: that these stale files appear at all, and that they are not removed.
MDEV-8475 describes and fixes the second part, and it exists at least in 5.5 as well, both MySQL and MariaDB, so it was not introduced in 10.0.x. I suppose Monty had good reasons to fix it only in 10.1; but since there seems to be a strong interest in this bugfix for 10.0, maybe he will want to reconsider.
There is, however, still the first part, why these files appear. We have a separate JIRA issue for it, https://mariadb.atlassian.net/browse/MDEV-8571 -- still open with no good way to reproduce. It is quite possible that *this* was indeed introduced with 10.0.x, at least that's when people started observing it. If you have any information on it, especially if you know how to reproduce it reliably, please comment on the bug report (or here, if you so prefer)
at least i faced this the first time after upgrade from 5.5.x to 10.0.x
given that we have around 30 MariaDB instances it's a strong indicator that with 10.0.x it got much worser and more likely to happen
each time on production machines with the same errors in the logfile and each time the "repair table" seems to have worked and a followed "optimize table" failed until i found out that this file exists
well, we have scripts checking the overhead of tables nightly and optimize them if it's larger than 100 KB and try to do this on random selected number of tables to not impact caches too much, likely because of that it gets more visible, but these scripts existing for many years starting with MySQL 5.0 in 2006 or so
*that* is *really* not funny just because "optimize table" was used for a table with a single record and for whatever reason the TMM file was left don't get me wrong, but that error messages *not* indicating the real problem and no way to get rid of that leaves TMM files with 'repair table' is a unnaceptable bug from any point of view MariaDB [42virtual]> optimize table cms1_blog_comments; +------------------------------+----------+----------+-------------------------------------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +------------------------------+----------+----------+-------------------------------------------------------------------------------------------------+ | 42virtual.cms1_blog_comments | optimize | Error | Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed | | 42virtual.cms1_blog_comments | optimize | Error | Table 'cms1_blog_comments' is marked as crashed and last (automatic?) repair failed | | 42virtual.cms1_blog_comments | optimize | error | Corrupt | +------------------------------+----------+----------+-------------------------------------------------------------------------------------------------+ 3 rows in set (0.00 sec) MariaDB [42virtual]> optimize table cms1_blog_comments; +------------------------------+----------+----------+-------------------------------------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +------------------------------+----------+----------+-------------------------------------------------------------------------------------------------+ | 42virtual.cms1_blog_comments | optimize | Error | Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed | | 42virtual.cms1_blog_comments | optimize | Error | Table 'cms1_blog_comments' is marked as crashed and last (automatic?) repair failed | | 42virtual.cms1_blog_comments | optimize | error | Corrupt | +------------------------------+----------+----------+-------------------------------------------------------------------------------------------------+ 3 rows in set (0.00 sec) 150920 16:32:33 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:32:33 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:33:15 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:33:17 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:33:23 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:33:28 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:33:49 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:33:55 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:37:13 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:37:15 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:37:21 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:37:27 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:37:47 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 16:37:53 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 17:09:02 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 17:09:08 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 17:09:14 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 17:09:21 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 17:09:41 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed 150920 17:09:48 [ERROR] mysqld: Table './42virtual/cms1_blog_comments' is marked as crashed and last (automatic?) repair failed
participants (2)
-
Elena Stepanova -
Reindl Harald