Ubuntu 18.04.1 LTS
4.15.0-34-generic #37-Ubuntu
Docker: 18.06.1-ce build e68fc7a

mysql --version = Ver 14.14 Distrib 5.7.25, for Linux (x86_64) using  EditLine wrapper


07:17:39 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68196 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f9814012240
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f98580a4e80 thread_stack 0x40000

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f98141c3520): SELECT `id`, `state`, `param`, `cursor_row`, `cursor_column`, `can_send`, `createdAt`, `updatedAt`, `userId`, `botId` FROM `states` AS `state` WHERE `state`.`userId` = 131913 AND `state`.`botId` = 3202 LIMIT 1
Connection ID (thread ID): 863486

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Probebly unrelated but repeated a lot:

2019-06-12T14:52:32.090130Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 10295ms. The settings might not be optimal. (flushed=9 and evicted=0, during the time.)
2019-06-12T14:53:56.177026Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 8427ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.)
2019-06-12T15:03:05.055209Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 6080ms. The settings might not be optimal. (flushed=3 and evicted=0, during the time.)
2019-06-12T15:03:52.398646Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5042ms. The settings might not be optimal. (flushed=168 and evicted=0, during the time.)

more logs and settings

Default settings from the docker have not been changed. It runs fine and queries to all unaffected tables work fine, but any queries, even CHECK TABLE on the affected table crashed the server instantly.

I haven't attempted data recovery and simply dropped and restored the table from backups. However, this is the second time in 2 months that this has happened (to different tables, but both were tables with more writes compared to the rest).

How can I diagnose the cause of corruption or make it less likely?

What I've checked so far:

  • The included log is the first sign of anything going wrong, the previous log entry is from 30min before and unrelated. And while crash with a corrupted table is reproducible I have no way of reproducing the corruption and higher log verbosity is unideal on the production server under load.
  • dmesg | egrep -i 'killed process' is empty, the box has 4gb of ram and swap enabled. I don't think the tables got corrupted due to oom kill in the middle of a write.
  • Shot in the dark: Have you tried disabling the load of persistent buffer pool? innodb_buffer_pool_load_at_startup is enabled in your settings, which might increase the likelihood of errors if this file already got errors (should be caught by InnoDB checksums but you'll never know). – gertvdijk Jun 18 '19 at 1:15
  • @gertvdijk I don't see any signs of MySQL restarting in the logs of the first crash, so I don't think a setting that applies only to startup would affect this. But I will change it anyway. The only downside is slowdown after restart until caches are warmed up again, correct? We won't find out if it helped until a few months to see if it corrupts tables again or not though... – Bor691 Jun 18 '19 at 5:40
  • Additional information request. Post on pastebin.com and share the links. RAM size of your MySQL Host server A) complete (not edited) my.cnf or my.ini Text results of: B) SHOW GLOBAL STATUS; after minimum 24 hours UPTIME D) SHOW FULL PROCESSLIST; E) complete MySQLTuner report F) SHOW ENGINE INNODB STATUS; AND Optional very helpful information, if available includes - htop OR top OR mytop for most active apps, ulimit -a for a linux/unix list of limits, iostat -xm 5 3 for IOPS by device and core/cpu count, for server workload tuning analysis. – Wilson Hauck Jun 20 '19 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.