We've been running a Zabbix server successfully for about 13-14 months, but suddenly the database crashed and went into a recovery loop. Zabbix 4.0.4 running on Ubuntu 18.04.2 LTS, mysqld 5.7.29.
We restored our VM from backup, and it ran fine for about 24 hours, then the database crashed again.
From the error.log in MySQL and what limited knowledge I have, it seems we may have a corrupt table/data. The database is about 78GB.
Does anyone know of a MySQL command that can run some of kind of consistency check if I restore the VM again and shut Zabbix server down?
This is the tail end of the MySQL error log:
InnoDB: Failing assertion: btr_page_get_prev(get_block->frame, mtr) == page_get_page_no(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/...-recovery.html
InnoDB: about forcing recovery.
19:57:53 UTC - mysqld got signal 6 ;
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.
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 76388 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f56dc000b20
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 = 7f570e03cdf0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xeaf22b]
/usr/sbin/mysqld(handle_fatal_signal+0x48b)[0x7794ab]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f582e0c0890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f582d3bce97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f582d3be801]
/usr/sbin/mysqld[0x74f996]
/usr/sbin/mysqld(_Z20btr_cur_latch_leavesP11buf_block_tRK9pa ge_id_tRK11page_size_tmP9btr_cur_tP5mtr_t+0x738)[0x109d2d8]
/usr/sbin/mysqld(_Z27btr_cur_search_to_nth_levelP12dict_inde x_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP 5mtr_t+0x17ad)[0x10a3f7d]
/usr/sbin/mysqld(_Z30btr_pcur_restore_position_funcmP10btr_p cur_tPKcmP5mtr_t+0x17a)[0x10aac2a]
/usr/sbin/mysqld[0xfea255]
/usr/sbin/mysqld(_Z14row_purge_stepP9que_thr_t+0x5a5)[0xfec975]
/usr/sbin/mysqld(_Z15que_run_threadsP9que_thr_t+0xb95)[0xf9c605]
/usr/sbin/mysqld(srv_worker_thread+0x4b8)[0x10205c8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7f582e0b56db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f582d49f88f]
Connection ID (thread ID): 0 x
Status: NOT_KILLED x
x
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains x
information that should help you find out what is causing the crash.
We restored our VM from backup, and it ran fine for about 24 hours, then the database crashed again.
From the error.log in MySQL and what limited knowledge I have, it seems we may have a corrupt table/data. The database is about 78GB.
Does anyone know of a MySQL command that can run some of kind of consistency check if I restore the VM again and shut Zabbix server down?
This is the tail end of the MySQL error log:
InnoDB: Failing assertion: btr_page_get_prev(get_block->frame, mtr) == page_get_page_no(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/...-recovery.html
InnoDB: about forcing recovery.
19:57:53 UTC - mysqld got signal 6 ;
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.
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 76388 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f56dc000b20
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 = 7f570e03cdf0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xeaf22b]
/usr/sbin/mysqld(handle_fatal_signal+0x48b)[0x7794ab]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f582e0c0890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f582d3bce97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f582d3be801]
/usr/sbin/mysqld[0x74f996]
/usr/sbin/mysqld(_Z20btr_cur_latch_leavesP11buf_block_tRK9pa ge_id_tRK11page_size_tmP9btr_cur_tP5mtr_t+0x738)[0x109d2d8]
/usr/sbin/mysqld(_Z27btr_cur_search_to_nth_levelP12dict_inde x_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP 5mtr_t+0x17ad)[0x10a3f7d]
/usr/sbin/mysqld(_Z30btr_pcur_restore_position_funcmP10btr_p cur_tPKcmP5mtr_t+0x17a)[0x10aac2a]
/usr/sbin/mysqld[0xfea255]
/usr/sbin/mysqld(_Z14row_purge_stepP9que_thr_t+0x5a5)[0xfec975]
/usr/sbin/mysqld(_Z15que_run_threadsP9que_thr_t+0xb95)[0xf9c605]
/usr/sbin/mysqld(srv_worker_thread+0x4b8)[0x10205c8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7f582e0b56db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f582d49f88f]
Connection ID (thread ID): 0 x
Status: NOT_KILLED x
x
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains x
information that should help you find out what is causing the crash.
Comment