mysql - Maria DB 拒绝开始
问题描述
下面在 OSX MariaDb 实例(通过 Brew 安装)上进行错误转储和配置。在我的 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.
解决方案
推荐阅读
- c++ - 我试图了解模板类是如何工作的,但我不断遇到编译问题
- html - 如何将两个html元素放在同一行的相对两侧
- sql - 在数组中搜索一个值并返回该值
- list - 在创建 PDF 时颤动 Table.fromTextArray 迭代列表
- spring-boot - 如何在 kotlin spring boot 中使用补丁映射
- python - “未解析的外部符号” - 将 Cython 扩展与 Windows 上的 C 库链接时出错
- ios - 核心数据中的重复对象
- python - 将日期时间字段转换为另一个时区并在 Python 中添加新列
- arrays - 字符串大小和地址间距的指针数组不匹配
- android - 序言中不能有内容。在构建我的 android 项目时出现此错误