MySQL
江湖救急 mysql 启动不起
墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网
我也要 关注 + 加入社区150514 13:17:52 [Note] Plugin 'FEDERATED' is disabled.
150514 13:17:52 [Note] Plugin 'InnoDB' is disabled.
150514 13:17:52 [ERROR] Unknown/unsupported storage engine: INNODB
150514 13:17:52 [ERROR] Aborting
150514 13:17:52 [Note] D:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete
150514 13:19:20 [Note] Plugin 'FEDERATED' is disabled.
150514 13:19:20 InnoDB: The InnoDB memory heap is disabled
150514 13:19:20 InnoDB: Mutexes and rw_locks use Windows interlocked functions
150514 13:19:20 InnoDB: Compressed tables use zlib 1.2.3
150514 13:19:20 InnoDB: Initializing buffer pool, size = 10.0G
150514 13:19:21 InnoDB: Completed initialization of buffer pool
150514 13:19:21 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1532524876909
150514 13:19:21 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1532530119680
InnoDB: Doing recovery: scanned up to log sequence number 1532535362560
InnoDB: Doing recovery: scanned up to log sequence number 1532540605440
InnoDB: Doing recovery: scanned up to log sequence number 1532543344508
150514 13:19:28 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 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
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 2255, file name .\binLog.000493
150514 13:20:07 InnoDB: Waiting for the background threads to start
150514 13:20:08 InnoDB: 1.1.6 started; log sequence number 1532543344508
150514 13:20:08 [Note] Recovering after a crash using binLog
150514 13:20:08 [Note] Starting crash recovery...
150514 13:20:08 [Note] Crash recovery finished.
150514 13:20:08 [Note] Event Scheduler: Loaded 1 event
150514 13:20:08 [Note] D:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.11-log' socket: '' port: 3306 MySQL Community Server (GPL)
150514 13:20:10 InnoDB: Assertion failure in thread 6936 in file ..\..\..\mysql-5.5.11\storage\innobase\trx\trx0purge.c line 828
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
150514 13:20:10 - mysqld got exception 0xc0000005 ;
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=524288000
read_buffer_size=131072
max_used_connections=0
max_threads=100
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 = 1754624 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...
000000013F7BFCFC mysqld.exe!my_osmaperr()
000000013F7BFED0 mysqld.exe!my_osmaperr()
000000013F7C0091 mysqld.exe!my_osmaperr()
000000013F844B29 mysqld.exe!my_osmaperr()
000000013F844C28 mysqld.exe!my_osmaperr()
000000013F824B39 mysqld.exe!my_osmaperr()
000000013F825140 mysqld.exe!my_osmaperr()
000000013F8252CF mysqld.exe!my_osmaperr()
000000013F7C04B6 mysqld.exe!my_osmaperr()
000000013F7AE1E1 mysqld.exe!my_osmaperr()
000000013F7AE722 mysqld.exe!my_osmaperr()
0000000076AD59ED kernel32.dll!BaseThreadInitThunk()
0000000076E4C541 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.
InnoDB: Thread 7200 stopped in file ..\..\..\mysql-5.5.11\storage\innobase\os\os0sync.c line 474
InnoDB: Thread 6612 stopped in file ..\..\..\mysql-5.5.11\storage\innobase\os\os0sync.c line 813
150514 13:17:52 [Note] Plugin 'InnoDB' is disabled.
150514 13:17:52 [ERROR] Unknown/unsupported storage engine: INNODB
150514 13:17:52 [ERROR] Aborting
150514 13:17:52 [Note] D:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete
150514 13:19:20 [Note] Plugin 'FEDERATED' is disabled.
150514 13:19:20 InnoDB: The InnoDB memory heap is disabled
150514 13:19:20 InnoDB: Mutexes and rw_locks use Windows interlocked functions
150514 13:19:20 InnoDB: Compressed tables use zlib 1.2.3
150514 13:19:20 InnoDB: Initializing buffer pool, size = 10.0G
150514 13:19:21 InnoDB: Completed initialization of buffer pool
150514 13:19:21 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1532524876909
150514 13:19:21 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1532530119680
InnoDB: Doing recovery: scanned up to log sequence number 1532535362560
InnoDB: Doing recovery: scanned up to log sequence number 1532540605440
InnoDB: Doing recovery: scanned up to log sequence number 1532543344508
150514 13:19:28 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 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
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 2255, file name .\binLog.000493
150514 13:20:07 InnoDB: Waiting for the background threads to start
150514 13:20:08 InnoDB: 1.1.6 started; log sequence number 1532543344508
150514 13:20:08 [Note] Recovering after a crash using binLog
150514 13:20:08 [Note] Starting crash recovery...
150514 13:20:08 [Note] Crash recovery finished.
150514 13:20:08 [Note] Event Scheduler: Loaded 1 event
150514 13:20:08 [Note] D:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.11-log' socket: '' port: 3306 MySQL Community Server (GPL)
150514 13:20:10 InnoDB: Assertion failure in thread 6936 in file ..\..\..\mysql-5.5.11\storage\innobase\trx\trx0purge.c line 828
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
150514 13:20:10 - mysqld got exception 0xc0000005 ;
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=524288000
read_buffer_size=131072
max_used_connections=0
max_threads=100
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 = 1754624 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...
000000013F7BFCFC mysqld.exe!my_osmaperr()
000000013F7BFED0 mysqld.exe!my_osmaperr()
000000013F7C0091 mysqld.exe!my_osmaperr()
000000013F844B29 mysqld.exe!my_osmaperr()
000000013F844C28 mysqld.exe!my_osmaperr()
000000013F824B39 mysqld.exe!my_osmaperr()
000000013F825140 mysqld.exe!my_osmaperr()
000000013F8252CF mysqld.exe!my_osmaperr()
000000013F7C04B6 mysqld.exe!my_osmaperr()
000000013F7AE1E1 mysqld.exe!my_osmaperr()
000000013F7AE722 mysqld.exe!my_osmaperr()
0000000076AD59ED kernel32.dll!BaseThreadInitThunk()
0000000076E4C541 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.
InnoDB: Thread 7200 stopped in file ..\..\..\mysql-5.5.11\storage\innobase\os\os0sync.c line 474
InnoDB: Thread 6612 stopped in file ..\..\..\mysql-5.5.11\storage\innobase\os\os0sync.c line 813
...全文
相关推荐
flask搭建微电影网站代码
flask搭建微电影网站的源码，可用，江湖救急类型的，分享一下
运营平台一键安装版：从Docker部署到多渠道分发实战
在数字化转型浪潮中，企业运营效率的提升离不开自动化工具的支撑。自动化运营平台的核心原理在于通过技术手段整合多渠道资源、标准化工作流程，其技术价值体现在大幅降低人工操作成本、提升内容分发的一致性与时效性。这类平台典型的应用场景包括社交媒体矩阵管理、私域流量运营和跨平台营销活动执行。本文聚焦于一个实现了“一键安装”的运营中台解决方案，该方案通过Docker容器化技术封装复杂环境，结合异步任务队列和智能重试机制，为运营团队提供开箱即用的内容分发与用户管理能力，帮助团队快速响应市场变化，实现从“手动挡”到“自动挡”
MATLAB 模拟 28 GHz 8×8 均匀矩形阵列的数字波束成形.zip
1.版本：matlab2014a/2019b/2024b 2.附赠案例数据可直接运行。 3.代码特点：参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象：计算机，电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
数据处理之增删改练习作业图片
数据处理之增删改练习作业
【多源数据融合】基于Dempster-Shafer理论的信念对数相似度测量及其在多源数据融合中的应用（Matlab代码实现）
内容概要：本文系统阐述了基于Dempster-Shafer（DS）证据理论的信念对数相似度测量方法，并将其应用于多源不确定信息的融合问题中。该方法通过构建基本概率分配函数（BPA），引入对数相似度准则来量化不同证据间的冲突与一致性，有效克服了传统Dempster组合规则在高冲突情境下的反直觉推理缺陷。文章详细论述了DS理论的数学基础、信念函数与似然函数的定义、焦元的识别与处理机制，并结合Matlab实现了完整的算法仿真流程，验证了该方法在提升融合结果鲁棒性与准确性方面的优越性能。该技术适用于传感器网络数据融合、故障诊断、模式识别及复杂系统决策支持等存在高度不确定性与信息冲突的实际场景。; 适合人群：具备一定数理逻辑基础和Matlab编程能力，从事人工智能、数据融合、自动化控制、模式识别、故障诊断及智能决策系统等领域的研究生、科研人员与工程技术人员。; 使用场景及目标：①解决多传感器或多专家系统中因信息来源差异导致的证据冲突问题；②提升复杂环境下状态感知与目标识别的可靠性与精确度；③为不确定性推理与证据理论研究提供可复现、可验证的算法实现范例； 阅读建议：建议读者首先掌握D-S证据理论的基本概念，重点理解BPA构造、信任度与似然度计算过程，结合文中Matlab代码深入剖析相似度计算与证据融合的实现细节，可通过调整仿真参数对比不同融合策略的效果，以全面把握该方法的优势与适用条件。
