MySQL5.7 service crash fails to start

Background of the incident

Test the environment to replace the data disk, directly take the data directory violence online copy to the new disk, and then shut down the original service, enable the new disk.

The service can start normally, but not much development on the response service down, error log output

 .- to- -  the: .: - 0x7ffdadff7700Innodb:assertion failureinchThread140727522653952 inch fileTrx0purge.ccLine167innodb:failing Assertion:purge_sys->iter.trx_no <= purge_sys->rseg->Last_trx_noinnodb: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, eveninnodb:immediately after the mysqld startup, there may Beinnodb:corruptioninchThe InnoDB tablespace. Please refer toinnodb:http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.htmlinnodb:about forcing recovery. -: .: -Utc-mysqld got Signal6 ; This could is because a bug. It's also possible that's binaryor one of the libraries it was linked against are corrupt, improperly built,or misconfi Gured. This error can also is caused by malfunctioning hardware. Attempting to collect some information, could help diagnose the problem. As this was a crash and something is definitely wrong, the informationcollection process might fail.key_buffer_size=8388608read_buffer_size=2097152max_used_connections=0max_threads= +Thread_count=0Connection_count=0It is possible this mysqld could use up tokey_buffer_size+ (read_buffer_size + sort_buffer_size) *max_threads =4117496K bytes of Memoryhope that's OK; if not, decrease some variables in the equation.Thread Pointer:0x7ffda8000900attempting backtrace. can use the following information toFindOutwhere Mysqld died. If you see no messages after this, something wentterribly wrong...stack_bottom= 7ffdadff6d98 Thread_stack0x40000/usr/local/mysql/bin/mysqld (my_print_stacktrace+0x35)[0xf32bd5]/usr/local/mysql/bin/mysqld (handle_fatal_signal+0x4a4)[0x77b844]/lib64/libpthread.so.0(+0xf7e0)[0x7ffe223e17e0]/lib64/libc.so.6(gsignal+0x35)[0x7ffe2108c5e5]/lib64/libc.so.6(abort+0x175)[0X7FFE2108DDC5]/usr/local/mysql/bin/mysqld[0x10c5da5]/usr/local/mysql/bin/mysqld (_zn20trxundorsegsiterator8set_nextev+0x322)[0x1093822]/usr/local/mysql/bin/mysqld[0x1095ea3]/usr/local/mysql/bin/mysqld (_z9trx_purgemmb+0X6AD)[0X10974BD]/usr/local/mysql/bin/mysqld[0x1076178]/usr/local/mysql/bin/mysqld (srv_purge_coordinator_thread+0x86f)[0x107914f]/lib64/libpthread.so.0(+0x7aa1)[0x7ffe223d9aa1]/lib64/libc.so.6(clone+0x6d)[0x7ffe21142aad]trying to get some variables. Some pointers may is invalid and cause the dump to abort. Query (0): is an invalid pointerconnection ID (thread ID):0status:not_killedthe manual page at http://dev.mysql.com/doc/mysql/en/crashing.html containsInformation that should help youFindCausing the crash.

A link to a hint is viewed, and possible impact factors include,

1. data file or index file has bad page

2, mysqld service during operation, there are other project operation data files and index files

This is related to the previous operation, and I copied the data file to another disk while the MYSQLD service was running, which is likely to result in inconsistent data and indexes of the replica

The stack in the log is parsed according to the recommendations given on the website.

vim/data1/sql/Mysqld.sym0xf32bd50x77b8440x7f751eed67e00x7f751db815e50X7F751DB82DC50x10c5da50x10938220x1095ea30X10974BD0x10761780x107914f0x7f751eeceaa10x7f751dc37aadnm-d-n/usr/local/mysql/bin/mysqld >/data1/sql/Mysqld.sym Resolve_stack_dump-s/data1/sql/mysqld.sym-n/data1/sql/Mysqld.stack0xf32bd5My_print_stacktrace + -0x77b844Handle_fatal_signal +11880x7f751eed67e0_end +4864239680x7f751db815e5_end +4661523570X7F751DB82DC5_end +4661584690x10c5da5_z23ut_dbg_assertion_failedpkcs0_m + the0x1093822_zn20trxundorsegsiterator8set_nextev +8020x1095ea3_Z14TRX_PURGE_STOPV +53630X10974BD_Z9TRX_PURGEMMB +17090x1076178_z26srv_get_active_thread_typev +10480x107914fSrv_purge_coordinator_thread +21590x7f751eeceaa1_end +4863919050x7f751dc37aad_end +466899053

Unable to find the root cause of the crash, the temporary solution is to start by setting up Innodb_force_recovery

Related content Reference InnoDB Recovery

1, set innodb_force_recovery set 1 and 2 are not valid, and finally set to 3 after the successful start

2. Dump all databases after startup and revert to the new instance

MySQL5.7 service crash fails to start