I was importing an old sql into existing schema. But the mysql service was stopped suddenly. Now I'm not able to start the service. It seems that the ibdata1 file is somehow corrupted. Here are the logs I got. I've tried several ways, such as adding the innodb_force_recovery in my.cnf, kill all of the mysql process. None of them works.
Could anyone help? Thanks in advance!!
I think I posted the wrong logs. This is the real log:
=======================
2017-12-08T17:56:24.927955Z 0 [Note] InnoDB: Using CPU crc32 instructions
2017-12-08T17:56:24.929802Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2017-12-08T17:56:24.942256Z 0 [Note] InnoDB: Completed initialization of buffer pool
2017-12-08T17:56:24.961017Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2017-12-08T17:56:24.962154Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 16417491586
2017-12-08T17:56:24.962169Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 16417493278
2017-12-08T17:56:24.963433Z 0 [Note] InnoDB: Database was not shutdown normally!
2017-12-08T17:56:24.963443Z 0 [Note] InnoDB: Starting crash recovery.
2017-12-08T17:56:24.996387Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
2017-12-08T17:56:25.501869Z 0 [Note] InnoDB: Apply batch completed
2017-12-08T17:56:25.626479Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2017-12-08T17:56:25.626508Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2017-12-08T17:56:25.626637Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2017-12-08T17:56:25.649790Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2017-12-08T17:56:25.650460Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2017-12-08T17:56:25.650469Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2017-12-08T17:56:25.650670Z 0 [Note] InnoDB: Waiting for purge to start
2017-12-08T17:56:25.655806Z 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2017-12-08T17:56:25.655825Z 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
2017-12-08 12:56:25 0x7000049f8000 InnoDB: Assertion failure in thread 123145379872768 in file fil0fil.cc line 896
InnoDB: Failing assertion: success
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/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
17:56:25 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=8388608
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 = 68218 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f9792000000
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 = 7000049f7e20 thread_stack 0x40000
0 mysqld 0x000000010caa714a my_print_stacktrace + 58
1 mysqld 0x000000010ca039d0 handle_fatal_signal + 688
2 libsystem_platform.dylib 0x00007fffb8d52b3a _sigtramp + 26
3 mysqld 0x000000010d3bac17 _ZZN10binary_log4Uuid9to_stringEPKhPcE11byte_to_hex + 41879
4 libsystem_c.dylib 0x00007fffb8bd7420 abort + 129
5 mysqld 0x000000010ccfd9c1 _Z23ut_dbg_assertion_failedPKcS0_m + 161
6 mysqld 0x000000010cb623bc _ZL18fil_node_open_fileP10fil_node_t + 3948
7 mysqld 0x000000010cb6d962 _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 194
8 mysqld 0x000000010cb6e418 _Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_ + 1096
9 mysqld 0x000000010cb27073 _ZL17buf_read_page_lowP7dberr_tbmmRK9page_id_tRK11page_size_tb + 387
10 mysqld 0x000000010cb27288 _Z13buf_read_pageRK9page_id_tRK11page_size_t + 56
11 mysqld 0x000000010cb0bb7a _Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb + 1290
12 mysqld 0x000000010cae91e8 _Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t + 4008
13 mysqld 0x000000010cc97824 _Z21row_search_on_row_refP10btr_pcur_tmPK12dict_table_tPK8dtuple_tP5mtr_t + 164
14 mysqld 0x000000010cc956a6 _ZL34row_purge_remove_clust_if_poss_lowP12purge_node_tm + 438
15 mysqld 0x000000010cc93a68 _Z14row_purge_stepP9que_thr_t + 1944
16 mysqld 0x000000010cc55919 _Z15que_run_threadsP9que_thr_t + 937
17 mysqld 0x000000010ccd9c4d _Z9trx_purgemmb + 2973
18 mysqld 0x000000010ccc2d57 srv_purge_coordinator_thread + 2871
19 libsystem_pthread.dylib 0x00007fffb8d5c93b _pthread_body + 180
20 libsystem_pthread.dylib 0x00007fffb8d5c887 _pthread_body + 0
21 libsystem_pthread.dylib 0x00007fffb8d5c08d thread_start + 13
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 0
Status: NOT_KILLED
After setting innodb_file_format_max to Antelope instead of default Barraccuda and innodb_force_recovery to 2 (SRV_FORCE_NO_BACKGROUND) mysqld 10.2.17-MariaDB runs faultlessly in my development environment.
mysqld --innodb-force-recovery=2 --innodb-file-format-max=Antelope
As mentioned in innodb_force_recovery it wouldn't be wise to use this approach in production.
Related
I am running AMPPS 3.8 on OS X (Mojave v10.14)
After my HD unexpectedly died, I replaced the HD and reloaded my latest backup. MySQL does not load/run in AMMPPS :( My expectation was that the AMPPS would work as expected (Apache/php 7.1/MySQL would all run per usual).
In attempting to resolve the issue I have read through the AMPPS wiki, youtube, googling, and reading similar threads on stackOverflow, I attempted the following steps as listed below. MySQL did not turn on when i clicked on the on/off butto, nor did clicking the restart cause MySQL to start.
WHAT I ATTEMPTED:
1. Clicked on config icon: This now opens 'my.cnf', not 'my.ini'
2. added instruction line to my.cnf: innodb_force_recovery = 1
3. Save configuration
4. Clicked on/off switch (did nothing/Did not click/did not work)
5. Clicked restart icon
My MySql did not start.
OBSERVATION: when you click on the configuration tool (tool icon), it opens the file 'my.cnf' instead of 'my.ini'
mysql.err log
2020-02-24 10:38:28 1417 [Warning] You need to use --log-bin to make --binlog-format work.
2020-02-24 10:38:28 1417 [Note] Plugin 'FEDERATED' is disabled.
2020-02-24 10:38:28 1417 [Note] InnoDB: Using atomics to ref count buffer pool pages
2020-02-24 10:38:28 1417 [Note] InnoDB: The InnoDB memory heap is disabled
2020-02-24 10:38:28 1417 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-02-24 10:38:28 1417 [Note] InnoDB: Memory barrier is not used
2020-02-24 10:38:28 1417 [Note] InnoDB: Compressed tables use zlib 1.2.3
2020-02-24 10:38:28 1417 [Note] InnoDB: Not using CPU crc32 instructions
2020-02-24 10:38:28 1417 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2020-02-24 10:38:28 1417 [Note] InnoDB: Completed initialization of buffer pool
2020-02-24 10:38:28 1417 [Note] InnoDB: Highest supported file format is Barracuda.
2020-02-24 10:38:28 1417 [Note] InnoDB: 128 rollback segment(s) are active.
2020-02-24 10:38:28 1417 [Note] InnoDB: Waiting for purge to start
InnoDB: Error: tablespace id is 1140 in the data dictionary
InnoDB: but in file ./test#002emarvelchampionsuniverse/ma_images.ibd it is 1155!
2020-02-24 10:38:28 b088c000 InnoDB: Assertion failure in thread 2961752064 in file fil0fil.cc line 797
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
18:38:28 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.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=16777216
read_buffer_size=262144
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 = 133617 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
0 mysqld 0x00309dbe my_print_stacktrace + 46
1 mysqld 0x00148c35 handle_fatal_signal + 758
2 libsystem_platform.dylib 0xa7cd7b6e _sigtramp + 46
3 ??? 0xffffffff 0x0 + 4294967295
4 libsystem_c.dylib 0xa7b9162b abort + 133
5 mysqld 0x00377605 _ZL18fil_node_open_fileP10fil_node_tP12fil_system_tP11fil_space_t + 100
6 mysqld 0x003780ad _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 147
7 mysqld 0x0037bea3 _Z6fil_iombmmmmmPvS_ + 513
8 mysqld 0x00354bf1 _ZL17buf_read_page_lowP7dberr_tbmmmmxm + 460
9 mysqld 0x00355134 _Z13buf_read_pagemmm + 88
10 mysqld 0x00346f06 _Z16buf_page_get_genmmmmP11buf_block_tmPKcmP5mtr_t + 488
11 mysqld 0x0033c88d _Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_tmmP9btr_cur_tmPKcmP5mtr_t + 1128
12 mysqld 0x0042100b _ZL17btr_pcur_open_lowP12dict_index_tmPK8dtuple_tmmP10btr_pcur_tPKcmP5mtr_t + 119
13 mysqld 0x0042117f _Z21row_search_on_row_refP10btr_pcur_tmPK12dict_table_tPK8dtuple_tP5mtr_t + 141
14 mysqld 0x0041f64c _ZL25row_purge_reposition_pcurmP12purge_node_tP5mtr_t + 116
15 mysqld 0x0041f73d _ZL34row_purge_remove_clust_if_poss_lowP12purge_node_tm + 194
16 mysqld 0x004203d3 _Z14row_purge_stepP9que_thr_t + 478
17 mysqld 0x003f9e0e _Z15que_run_threadsP9que_thr_t + 710
18 mysqld 0x00443413 _Z9trx_purgemmb + 2971
19 mysqld 0x00434bed _ZL12srv_do_purgemPm + 317
20 mysqld 0x00435759 srv_purge_coordinator_thread + 1055
21 libsystem_pthread.dylib 0xa7cdf63c _pthread_body + 137
22 libsystem_pthread.dylib 0xa7ce2833 _pthread_start + 82
23 libsystem_pthread.dylib 0xa7cde806 thread_start + 34
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.
I am a barista who enjoys attempting to write apps for fun and to help keep my mind sharp with early on set Alzheimer's disease, at best I am a novice. I do this to exercise my mind in an attempt to hold on to as much as I can for as long as I can. I am hoping to get MySQL working again if only once to export my local db to preserve what I have done.
Thank you for any and all help.
I was adding a new field to an existing database with about 7 million records already within it. This modification suddenly caused mysql to crash and I cannot figure out how to recover things.
I am running a Vagrant/Homestead setup on my local windows 10 machine.
I run "vagrant ssh" to connect to the virtual box.
Output from /var/log/mysql/error.log
Thread pointer: 0x0
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 = 0 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)[0x7f6eafeea890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f6eaf1e6e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f6eaf1e8801]
/usr/sbin/mysqld[0x74f996]
/usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0x66)[0x1086196]
/usr/sbin/mysqld(_Z18os_file_flush_funci+0x1e0)[0xf69e00]
/usr/sbin/mysqld(_Z16os_file_set_sizePKc13pfs_os_file_tmb+0x324)[0xf71314]
/usr/sbin/mysqld(_ZN13SysTablespace8set_sizeER8Datafile+0x22b)[0x1156a8b]
/usr/sbin/mysqld(_ZN13SysTablespace14open_or_createEbbPmS0_+0xcf)[0x115921f]
/usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x34c8)[0x1030628]
/usr/sbin/mysqld[0xef683d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x7cc69f]
/usr/sbin/mysqld[0xc888c5]
/usr/sbin/mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x1e5)[0xc8bde5]
/usr/sbin/mysqld[0x771770]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x795)[0x772e75]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f6eaf1c9b97]
/usr/sbin/mysqld(_start+0x2a)[0x76921a]
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.
2020-01-29T03:01:42.557756Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2020-01-29T03:01:42.558912Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.29-0ubuntu0.18.04.1) starting as process 10980 ...
2020-01-29T03:01:42.564351Z 0 [Note] InnoDB: PUNCH HOLE support available
2020-01-29T03:01:42.564377Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-01-29T03:01:42.564383Z 0 [Note] InnoDB: Uses event mutexes
2020-01-29T03:01:42.564388Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2020-01-29T03:01:42.564393Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-01-29T03:01:42.564397Z 0 [Note] InnoDB: Using Linux native AIO
2020-01-29T03:01:42.564680Z 0 [Note] InnoDB: Number of pools: 1
2020-01-29T03:01:42.564803Z 0 [Note] InnoDB: Using CPU crc32 instructions
2020-01-29T03:01:42.567749Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-01-29T03:01:42.579265Z 0 [Note] InnoDB: Completed initialization of buffer pool
2020-01-29T03:01:42.580822Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-01-29T03:01:42.592142Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2020-01-29T03:01:42.593066Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 62908547934
2020-01-29T03:01:42.601807Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 62909011867
2020-01-29T03:01:42.601920Z 0 [Note] InnoDB: Database was not shutdown normally!
2020-01-29T03:01:42.601926Z 0 [Note] InnoDB: Starting crash recovery.
2020-01-29T03:01:42.618100Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
2020-01-29T03:01:42.625779Z 0 [Note] InnoDB: Apply batch completed
2020-01-29T03:01:42.738017Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-01-29T03:01:42.738043Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-01-29T03:01:42.738085Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-01-29T03:01:42.748224Z 0 [ERROR] [FATAL] InnoDB: fsync() returned EIO, aborting.
2020-01-29 03:01:42 0x7fca264c1740 InnoDB: Assertion failure in thread 140506202642240 in file ut0ut.cc line 918
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/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
03:01:42 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.
Any ideas how to proceed?
I attempted a reinstallation of mysql without any luck. The databases should still be there, but I am unsure if I am able to recover them now?
Error dump & conf below on a OSX MariaDb instance (installed via Brew). This db worked fine prior to my mac freezing up and restarting while the DB was running.
Now when I try to mysql.server start I get the following error:
mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
ERROR!
I have checked for surplus .pid files and deleted them (after trying other things such as starting in safe mode and doing a db check on table corruption, which passed it's check).
My .cnf file:
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]
#
# include all files from the config directory
#
!includedir /usr/local/etc/my.cnf.d
[mysqld]
innodb_buffer_pool_size=1676M
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Uses event mutexes
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Number of pools: 1
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Using SSE2 crc32 instructions
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Initializing buffer pool, total size = 2G, instances = 8, chunk size = 128M
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Completed initialization of buffer pool
2019-01-28 12:39:28 4802311616 [Note] InnoDB: Highest supported file format is Barracuda.
2019-01-28 12:39:29 4802311616 [Note] InnoDB: 3 transaction(s) which must be rolled back or cleaned up in total 2294467 row operations to undo
2019-01-28 12:39:29 4802311616 [Note] InnoDB: Trx id counter is 230784256
2019-01-28 12:39:29 4802311616 [Note] InnoDB: 128 out of 128 rollback segments are active.
2019-01-28 12:39:29 123145460723712 [Note] InnoDB: Starting in background the rollback of recovered transactions
2019-01-28 12:39:29 4802311616 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-01-28 12:39:29 4802311616 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-01-28 12:39:29 0x700009713000 InnoDB: Assertion failure in file /tmp/mariadb-20180328-24866-1e7eel7/mariadb-10.2.14/storage/innobase/include/fut0lst.ic line 85
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
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: https://mariadb.com/kb/en/library/xtradbinnodb-recovery-modes/
InnoDB: about forcing recovery.
190128 12:39:29 [ERROR] 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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.2.14-MariaDB
key_buffer_size=268435456
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 598321 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0x0 thread_stack 0x49000
2019-01-28 12:39:29 4802311616 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2019-01-28 12:39:29 4802311616 [Note] InnoDB: 5.7.21 started; log sequence number 732581563327
2019-01-28 12:39:29 4802311616 [Note] InnoDB: !!! innodb_force_recovery is set to 1 !!!
2019-01-28 12:39:29 123145466626048 [Note] InnoDB: Loading buffer pool(s) from /usr/local/var/mysql/ib_buffer_pool
0 mysqld 0x000000010edc812c my_print_stacktrace + 60
0 mysqld 0x000000010e814cdc handle_fatal_signal + 718
0 libsystem_platform.dylib 0x00007fff793fdb3d _sigtramp + 29
0 ??? 0x000000011e3a4e50 0x0 + 4802104912
2019-01-28 12:39:29 4802311616 [Note] Plugin 'FEEDBACK' is disabled.
0 libsystem_c.dylib 0x00007fff792bc1c9 abort + 127
2019-01-28 12:39:29 4802311616 [Note] Server socket created on IP: '::'.
0 mysqld 0x000000010eccadb0 _Z14ib_list_createv + 0
0 mysqld 0x000000010eba48ac _Z14flst_add_firstPhS_P5mtr_t + 1420
0 mysqld 0x000000010ecad0eb _Z36trx_purge_add_update_undo_to_historyP5trx_tPhP5mtr_t + 355
0 mysqld 0x000000010ecc84d3 _Z23trx_undo_update_cleanupP5trx_tPhP5mtr_t + 32
0 mysqld 0x000000010ecc0db3 _Z14trx_commit_lowP5trx_tP5mtr_t + 2750
0 mysqld 0x000000010ecc1103 _Z10trx_commitP5trx_t + 214
0 mysqld 0x000000010ecba6f2 _Z31trx_rollback_or_clean_recoveredm + 787
0 mysqld 0x000000010ecbacef trx_rollback_or_clean_all_recovered + 62
0 libsystem_pthread.dylib 0x00007fff79406339 _pthread_body + 126
0 libsystem_pthread.dylib 0x00007fff794092a7 _pthread_start + 70
0 libsystem_pthread.dylib 0x00007fff79405445 thread_start + 13
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.
2019-01-28 12:39:29 4350166464 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-01-28 12:39:29 4350166464 [Note] InnoDB: Uses event mutexes
2019-01-28 12:39:29 4350166464 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-01-28 12:39:29 4350166464 [Note] InnoDB: Number of pools: 1
2019-01-28 12:39:29 4350166464 [Note] InnoDB: Using SSE2 crc32 instructions
2019-01-28 12:39:29 4350166464 [Note] InnoDB: Initializing buffer pool, total size = 2G, instances = 8, chunk size = 128M
2019-01-28 12:39:30 4350166464 [Note] InnoDB: Completed initialization of buffer pool
2019-01-28 12:39:30 4350166464 [Note] InnoDB: Highest supported file format is Barracuda.
2019-01-28 12:39:30 4350166464 [Note] InnoDB: 3 transaction(s) which must be rolled back or cleaned up in total 2294467 row operations to undo
2019-01-28 12:39:30 4350166464 [Note] InnoDB: Trx id counter is 230784256
2019-01-28 12:39:30 4350166464 [Note] InnoDB: 128 out of 128 rollback segments are active.
2019-01-28 12:39:30 123145347538944 [Note] InnoDB: Starting in background the rollback of recovered transactions
2019-01-28 12:39:30 0x700002b22000 InnoDB: Assertion failure in file /tmp/mariadb-20180328-24866-1e7eel7/mariadb-10.2.14/storage/innobase/include/fut0lst.ic line 85
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
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: https://mariadb.com/kb/en/library/xtradbinnodb-recovery-modes/
InnoDB: about forcing recovery.
190128 12:39:30 [ERROR] 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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.2.14-MariaDB
key_buffer_size=268435456
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 598321 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0x0 thread_stack 0x49000
2019-01-28 12:39:30 4350166464 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2019-01-28 12:39:30 4350166464 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-01-28 12:39:30 4350166464 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
0 mysqld 0x000000010128112c my_print_stacktrace + 60
0 mysqld 0x0000000100ccdcdc handle_fatal_signal + 718
0 libsystem_platform.dylib 0x00007fff793fdb3d _sigtramp + 29
0 ??? 0x0000000103471e50 0x0 + 4349959760
0 libsystem_c.dylib 0x00007fff792bc1c9 abort + 127
0 mysqld 0x0000000101183db0 _Z14ib_list_createv + 0
0 mysqld 0x000000010105d8ac _Z14flst_add_firstPhS_P5mtr_t + 1420
0 mysqld 0x00000001011660eb _Z36trx_purge_add_update_undo_to_historyP5trx_tPhP5mtr_t + 355
0 mysqld 0x00000001011814d3 _Z23trx_undo_update_cleanupP5trx_tPhP5mtr_t + 32
0 mysqld 0x0000000101179db3 _Z14trx_commit_lowP5trx_tP5mtr_t + 2750
0 mysqld 0x000000010117a103 _Z10trx_commitP5trx_t + 214
0 mysqld 0x00000001011736f2 _Z31trx_rollback_or_clean_recoveredm + 787
0 mysqld 0x0000000101173cef trx_rollback_or_clean_all_recovered + 62
0 libsystem_pthread.dylib 0x00007fff79406339 _pthread_body + 126
0 libsystem_pthread.dylib 0x00007fff794092a7 _pthread_start + 70
0 libsystem_pthread.dylib 0x00007fff79405445 thread_start + 13
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.
below is a log of mysql
MYSQL shutdown frequent and i cant solve the problem
image file
logfile
2018-02-26T08:15:08.301271Z 591 [Warning] IP address '192.168.1.4' has been resolved to the host name '192.168.1.4', which resembles IPv4-address itself.
2018-02-26T08:15:08.395035Z 596 [Warning] IP address '192.168.1.4' has been resolved to the host name '192.168.1.4', which resembles IPv4-address itself.
2018-02-26T08:19:23.208784Z 0 [ERROR] InnoDB: Operating system error number 995 in a file operation.
2018-02-26T08:19:23.208784Z 0 [ERROR] InnoDB: The error means that the I/O operation has been aborted because of either a thread exit or an application request. Retry attempt is made.
2018-02-26 15:19:23 0x25b0 InnoDB: Assertion failure in thread 9648 in file fil0fil.cc line 5789
InnoDB: Failing assertion: err == DB_SUCCESS
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/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
08:19:23 UTC - mysqld got exception 0x80000003 ;
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=8388608
read_buffer_size=65536
max_used_connections=48
max_threads=200
thread_count=7
connection_count=7
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 74620 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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...
7f68cb05ea2 mysqld.exe!my_errno()
7f68cea9919 mysqld.exe!my_wildcmp_mb()
7f68cea8810 mysqld.exe!my_wildcmp_mb()
7f68cc05ac8 mysqld.exe!?reserve#?$vector#EV?$allocator#E#std###std##QEAAX_K#Z()
7f68cc2c49a mysqld.exe!?reserve#?$vector#EV?$allocator#E#std###std##QEAAX_K#Z()
7f68cbc4e94 mysqld.exe!?reserve#?$vector#EV?$allocator#E#std###std##QEAAX_K#Z()
7fefff81842 KERNEL32.DLL!BaseThreadInitThunk()
7ff012ac3f1 ntdll.dll!RtlUserThreadStart()
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.
2018-02-26T08:19:36.819511Z 0 [Note] C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe (mysqld 5.7.11-log) starting as process 7620 ...
2018-02-26T08:19:36.835137Z 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2018-02-26T08:19:36.835137Z 0 [Note] InnoDB: Uses event mutexes
2018-02-26T08:19:36.835137Z 0 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier
2018-02-26T08:19:36.835137Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-02-26T08:19:36.835137Z 0 [Note] InnoDB: Adjusting innodb_buffer_pool_instances from 8 to 1 since innodb_buffer_pool_size is less than 1024 MiB
2018-02-26T08:19:36.835137Z 0 [Note] InnoDB: Number of pools: 1
2018-02-26T08:19:36.835137Z 0 [Note] InnoDB: Not using CPU crc32 instructions
2018-02-26T08:19:36.897642Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2018-02-26T08:19:36.897642Z 0 [Note] InnoDB: Completed initialization of buffer pool
2018-02-26T08:19:36.944522Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2018-02-26T08:19:36.960149Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 100862484017
2018-02-26T08:19:36.960149Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 100862486308
2018-02-26T08:19:36.960149Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 100862486308
2018-02-26T08:19:36.975774Z 0 [Note] InnoDB: Database was not shutdown normally!
2018-02-26T08:19:36.975774Z 0 [Note] InnoDB: Starting crash recovery.
2018-02-26T08:19:37.444572Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
2018-02-26T08:19:37.975874Z 0 [Note] InnoDB: Apply batch completed
2018-02-26T08:19:39.585408Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2018-02-26T08:19:39.585408Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2018-02-26T08:19:39.585408Z 0 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2018-02-26T08:19:40.101086Z 0 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB.
2018-02-26T08:19:40.101086Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2018-02-26T08:19:40.101086Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2018-02-26T08:19:40.101086Z 0 [Note] InnoDB: Waiting for purge to start
2018-02-26T08:19:40.163591Z 0 [Note] InnoDB: 5.7.11 started; log sequence number 100862486308
2018-02-26T08:19:40.163591Z 0 [Note] InnoDB: Loading buffer pool(s) from C:\ProgramData\MySQL\MySQL Server 5.7\Data\ib_buffer_pool
2018-02-26T08:19:40.163591Z 0 [Note] Plugin 'FEDERATED' is disabled.
2018-02-26T08:19:40.491749Z 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
2018-02-26T08:19:40.491749Z 0 [Note] Server hostname (bind-address): '*'; port: 3306
2018-02-26T08:19:40.491749Z 0 [Note] IPv6 is available.
2018-02-26T08:19:40.491749Z 0 [Note] - '::' resolves to '::';
2018-02-26T08:19:40.491749Z 0 [Note] Server socket created on IP: '::'.
2018-02-26T08:19:40.757400Z 0 [Note] Event Scheduler: Loaded 0 events
2018-02-26T08:19:40.757400Z 0 [Note] C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe: ready for connections.
Version: '5.7.11-log' socket: '' port: 3306 MySQL Community Server (GPL)
2018-02-26T08:19:45.164087Z 0 [Note] InnoDB: Buffer pool(s) load completed at 180226 15:19:45
Suggestions for your my.cnf/ini [mysqld] section
Every x Connection listed in MySQLCalculator.com must be REMOVED from your my.cnf-ini to allow DEFAULTS to serve you.
thread_cache_size=100 # from 10 REFMAN v5.7 5.1.5 for CAP of 100 suggested
innodb_io_capacity=800 # from 200 to enable higher capacity
lock_wait_timeout=300 # from 31536000, who wants to wait ONE Year?
eq_range_index_dive_limit=20 $ from 200 not found in 20, is missing
expire_logs_days=5 # from 0 so you have limited historical logs
key_buffer_size=1M # from 8M you had key_blocks_used of 2
innodb_buffer_pool_instances=8 # from 1 to avoid mutex contention
innodb_buffer_pool_size=8G # from 128M until you need more for data volume
innodb_log_buffer_size=8M # from 134M - can not be > innodb_log_file_size
innodb_lru_scan_depth=128 # from 1024 see REFMAN for why
innodb_page_cleaners=64 # from 1 will be limited to be = innodb_buffer_pool_instances
innodb_print_all_deadlocks=ON # from OFF - check error log DAILY
innodb_read_io_threads=64 # from 4 see dba.stackexchange.com Q 5666 9/12/11
innodb_thread_concurrency=0 # in 5666 Rolando explains these 3 values
innodb_io_threads=64 # from 4 and how the combination enables multi-core
innodb_stats_sample_pages=32 # from 8 for more accurate cardinality
#max_allowed_packet=1G # leading # to disable for DEFAULT size
if you NEED larger size for LOCAL INFILE, in your SESSION,
SET #max_allowed_packet=nnnnnnnnnnnn up to 1G which is the MAX
max_seeks_for_key=32 # from a huge number, do not waste CPU past 32
max_write_lock_count=16 # from a huge number, allow RD after nn LOCKS
wait_timeout=3600 # from 8 hours, not touched in 1 HR release rscrs, log in again
Good luck.
Suggestions for your my.cnf/ini [mysqld] section
#sort_buffer_size=~256K # lead to allow DEFAULT to work for you
max_connections=100 # from 200 since max_used_connection were 48 since start
derived from your original posted information of 2/26/2018.
These changes will lower RAM requirements and we do not know how much RAM you have on your server.
The old and the new MAMP: They don't boot MySQL server. Before the upgrade to MAMP 4, my MySQL server was working properly on OS X 10.11.6 El Capitan.
Now with MAMP is not possible to start the MySQL server (and migrate my old DB).
Note: "Tools > upgrade MySQL databases" is not accessible in the menu bar (remains gray) but no problem with Apache and PHP.
My chmod for all files from /Applications/MAMP/db/ is:
RW admin (group)
RW system
RW _mysql
RW _mysql (group)
RW everyone
and chmod for all files from /Applications/MAMP/tmp/mysql is:
RW admin (group)
RW system
RW everyone
MySQL last log error:
161007 12:20:26 mysqld_safe Starting mysqld daemon with databases from /Applications/MAMP/db/mysql56
2016-10-07 12:20:27 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2016-10-07 12:20:27 0 [Note] /Applications/MAMP/Library/bin/mysqld (mysqld 5.6.28) starting as process 16615 ...
2016-10-07 12:20:27 16615 [Warning] Setting lower_case_table_names=2 because file system for /Applications/MAMP/db/mysql56/ is case insensitive
2016-10-07 12:20:27 16615 [Note] Plugin 'FEDERATED' is disabled.
2016-10-07 12:20:27 16615 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-10-07 12:20:27 16615 [Note] InnoDB: The InnoDB memory heap is disabled
2016-10-07 12:20:27 16615 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-10-07 12:20:27 16615 [Note] InnoDB: Memory barrier is not used
2016-10-07 12:20:27 16615 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-10-07 12:20:27 16615 [Note] InnoDB: Using CPU crc32 instructions
2016-10-07 12:20:27 16615 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-10-07 12:20:27 16615 [Note] InnoDB: Completed initialization of buffer pool
2016-10-07 12:20:27 16615 [Note] InnoDB: Highest supported file format is Barracuda.
2016-10-07 12:20:27 16615 [Note] InnoDB: Log scan progressed past the checkpoint lsn 8276492
2016-10-07 12:20:27 16615 [Note] InnoDB: Database was not shutdown normally!
2016-10-07 12:20:27 16615 [Note] InnoDB: Starting crash recovery.
2016-10-07 12:20:27 16615 [Note] InnoDB: Reading tablespace information from the .ibd files...
2016-10-07 12:20:27 16615 [Note] InnoDB: Restoring possible half-written data pages
2016-10-07 12:20:27 16615 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 8280376
2016-10-07 12:20:27 16615 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
2016-10-07 12:20:27 16615 [Note] InnoDB: 128 rollback segment(s) are active.
2016-10-07 12:20:27 16615 [Note] InnoDB: Waiting for purge to start
2016-10-07 12:20:27 7000007ab000 InnoDB: Assertion failure in thread 123145310351360 in file dict0dict.cc line 3464
InnoDB: Failing assertion: for_table || ref_table
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:20:27 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.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8388608
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 = 68101 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x40000
0 mysqld 0x0000000106f73688 my_print_stacktrace + 72
1 mysqld 0x0000000106c3a9e8 handle_fatal_signal + 952
2 libsystem_platform.dylib 0x00007fff9fa7d52a _sigtramp + 26
3 ??? 0x020061d7b33d5471 0x0 + 144222767128859761
4 libsystem_c.dylib 0x00007fff9f4f66df abort + 129
5 mysqld 0x000000010700ba56 _Z25dict_foreign_add_to_cacheP14dict_foreign_tPPKcb17dict_err_ignore_t + 230
6 mysqld 0x0000000107026dba _ZL17dict_load_foreignPKcPS0_bb17dict_err_ignore_t + 1674
7 mysqld 0x000000010702601b _Z18dict_load_foreignsPKcPS0_bb17dict_err_ignore_t + 1115
8 mysqld 0x0000000107024996 _Z15dict_load_tablePKcm17dict_err_ignore_t + 2246
9 mysqld 0x0000000107026441 _Z21dict_load_table_on_idy17dict_err_ignore_t + 689
10 mysqld 0x0000000107004098 _ZL25dict_table_open_on_id_lowy17dict_err_ignore_t + 184
11 mysqld 0x0000000107003ee3 _Z21dict_table_open_on_idym15dict_table_op_t + 99
12 mysqld 0x000000010717dc75 _ZL24row_purge_parse_undo_recP12purge_node_tPhPbP9que_thr_t + 229
13 mysqld 0x000000010717d88f _ZL9row_purgeP12purge_node_tPhP9que_thr_t + 63
14 mysqld 0x000000010717d741 _Z14row_purge_stepP9que_thr_t + 305
15 mysqld 0x0000000107133d91 _ZL12que_thr_stepP9que_thr_t + 913
16 mysqld 0x00000001071334eb _ZL19que_run_threads_lowP9que_thr_t + 123
17 mysqld 0x00000001071332ee _Z15que_run_threadsP9que_thr_t + 110
18 mysqld 0x00000001071bc15a _Z9trx_purgemmb + 778
19 mysqld 0x00000001071aa673 _ZL12srv_do_purgemPm + 579
20 mysqld 0x00000001071a9be7 srv_purge_coordinator_thread + 679
21 libsystem_pthread.dylib 0x00007fff9328e99d _pthread_body + 131
22 libsystem_pthread.dylib 0x00007fff9328e91a _pthread_body + 0
23 libsystem_pthread.dylib 0x00007fff9328c351 thread_start + 13
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.
161007 12:20:27 mysqld_safe mysqld from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended
I experienced the exact same problem and this is the only location (as of 10 Feb 2017) where I have found it reported as a problem.
If you don't need the content of the databases from MAMP 2, then this is easy:
Verify that MySQL is not running (via MAMP GUI and either Activity Monitor or Terminal process list)
Navigate to /Applications/MAMP/db/mysql56
Remove these three files: ib_logfile0, ib_logfile1, and ibdata1
Restart MySQL Server in MAMP
I found this solution here: http://www.randombugs.com/linux/crash-innodb-table.html. Note that the ibdata file is where InnoDB stores the data from your tables by default (https://serverfault.com/questions/487159/what-is-the-ibdata1-file-in-my-var-lib-mysql-directory) so it would be good to back-up these files before removing them; just in case something doesn't work out, you can restore back to your non-working configuration.
On the other hand, if you need the content of your MAMP 2 databases, then you will have needed to have completed a backup of them in the older/working version, preferably a MySQL dump so that restoration is as easy as copy/paste. Fortunately, I had a backup so in addition to deleting the "ib..." files listed above, I also deleted the directories of the databases that I intended to restore so that I could begin a restore with "CREATE DATABASE...".
I don't know whether this is a bug with MAMP, MySQL, OSX, but this is the solution that worked for me. I was able to restore the databases that I cared about and just didn't worry about losing the others for which I didn't have backed up.
Technical Data:
Old MAMP Version 2.1.2
Old MySQL Version 4.0.10.14
New MAMP Version 4.1.1
New MySQL Version 5.6.35
Mac OS 10.12.3