下面的OSX MariaDb实例（通过Brew安装）上的错误转储和conf。在我的mac冻结并在数据库运行时重新启动之前，该数据库工作正常。
现在，当我尝试启动mysql.server时，出现以下错误： mysqld_safe使用/ usr / local / var / mysql中的数据库启动mysqld守护程序 错误！
我已经检查了多余的.pid文件并删除了它们（尝试其他操作（如以安全模式启动并对表损坏进行数据库检查后，通过了检查））。
我的.cnf文件：
# 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.