简体   繁体   English

mysqldump / mysqlcheck时MySQL崩溃

[英]MySQL crash while mysqldump / mysqlcheck

everytime I try to backup or check all tables mysql server crashes on Windows server 2012, I am using XAMPP stack for my development environment. 每次我尝试备份或检查Windows Server 2012上mysql服务器崩溃的所有表时,我都在开发环境中使用XAMPP堆栈。 The database crypto has more then 1100+ tables in DB. 数据库密码在DB中具有超过1100多个表。 I am including the logs below. 我包括以下日志。

InnoDB: End of page dump 2017-09-24 13:58:35 7dc InnoDB: uncompressed page, stored checksum in field1 2521749199, calculated checksums for field1: crc32 2344073126, innodb 1121903210, none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 2344073126, innodb 2892594725, none 3735928559, page LSN 0 2936733816, low 4 bytes of LSN at page end 0, page number (if stored to page already) 34, space id (if created with >= MySQL-4.1.1 and stored already) 1767 InnoDB: page type 17855 meaning INDEX InnoDB: Page may be an index page where index id is 1522 InnoDB: (index "PRIMARY" of table "crypto"."300-token") 2017-09-24 13:58:35 2012 [ERROR] InnoDB: It is also possible that your operatingsystem has corrupted its own file cache. InnoDB:页面结束转储2017-09-24 13:58:35 7dc InnoDB:未压缩的页面,在field1中存储校验和2521749199,为field1计算校验和:crc32 2344073126,innodb 1121903210,无3735928559,在field2中存储校验和0,计算校验和对于field2:crc32 2344073126,innodb 2892594725,无3735928559,页面LSN 0 2936733816,页面结束0处LSN的低4个字节,页面号(如果已存储到页面中)34,空间ID(如果使用> = MySQL-4.1创建)。 1并且已经存储)1767 InnoDB:页面类型17855表示INDEX InnoDB:页面可以是索引ID为1522的索引页面InnoDB :(表“ crypto”的索引“ PRIMARY”。“ 300令牌”)2017-09-24 13:58:35 2012 [ERROR] InnoDB:您的操作系统也可能损坏了其自己的文件缓存。 2017-09-24 13:58:35 2012 [ERROR] InnoDB: and rebooting your computer removes the error. 2017年9月24日13:58:35 2012年[错误] InnoDB:重新启动计算机可消除该错误。 2017-09-24 13:58:35 2012 [ERROR] InnoDB: If the corrupt page is an index page you can also try to 2017-09-24 13:58:35 2012 [ERROR] InnoDB: fix the corruption by dumping, dropping, and reimporting 2017-09-24 13:58:35 2012 [ERROR] InnoDB: the corrupt table. 2017-09-24 13:58:35 2012 [错误] InnoDB:如果损坏的页面是索引页,您也可以尝试到2017-09-24 13:58:35 2012 [ERROR] InnoDB:通过转储修复损坏,删除和重新导入2017-09-24 13:58:35 2012 [错误] InnoDB:损坏的表。 You can use CHECK 2017-09-24 13:58:35 2012 [ERROR] InnoDB: TABLE to scan your table for corruption. 您可以使用CHECK 2017-09-24 13:58:35 2012 [ERROR] InnoDB:TABLE扫描表是否损坏。 2017-09-24 13:58:35 2012 [ERROR] InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html about forcing recovery. 2017年9月24日13:58:35 2012年[错误] InnoDB:有关强制恢复,另请参阅http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html 2017-09-24 13:58:35 7dc InnoDB: Assertion failure in thread 2012 in file buf0lru.cc line 2394 InnoDB: Failing assertion: bpage->buf_fix_count == 0 InnoDB: We intentionally generate a memory trap. 2017-09-24 13:58:35 7dc InnoDB:文件buf0lru.cc行2394中的线程2012中的断言失败InnoDB:失败的断言:bpage-> buf_fix_count == 0 InnoDB:我们有意生成内存陷阱。 InnoDB: Submit a detailed bug report to http://bugs.mysql.com . InnoDB:向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. InnoDB:如果反复声明失败或崩溃,甚至在mysqld启动后立即出现InnoDB:,则InnoDB表空间中可能存在InnoDB:损坏。 Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 请参考InnoDB: http : //dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB:关于强制恢复。 170924 13:58:35 [ERROR] mysqld got exception 0x80000003 ; 170924 13:58:35 [错误] mysqld异常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. 硬件故障也可能导致此错误。

To report this bug, see https://mariadb.com/kb/en/reporting-bugs 要报告此错误,请参阅https://mariadb.com/kb/zh/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.1.22-MariaDB key_buffer_size=16777216 read_buffer_size=262144 max_used_connections=1 max_threads=1001 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787106 K bytes of memory Hope that's ok; 服务器版本:10.1.22-MariaDB key_buffer_size = 16777216 read_buffer_size = 262144 max_used_connections = 1 max_threads = 1001 thread_count = 1 mysqld可能最多使用key_buffer_size +(read_buffer_size + sort_buffer_size)* max_threads = 787106 K的内存,希望没问题; if not, decrease some variables in the equation. 如果不是,则减少方程中的一些变量。

Thread pointer: 0x0 Attempting backtrace. 线程指针:0x0尝试回溯。 You can use the following information to find out where mysqld died. 您可以使用以下信息来找出mysqld在何处死亡。 If you see no messages after this, something went terribly wrong... mysqld.exe!my_parameter_handler() mysqld.exe!my_wildcmp_mb_bin() mysqld.exe!?save_in_result_field@Item@@UAEX_N@Z() mysqld.exe!?save_in_result_field@Item@@UAEX_N@Z() mysqld.exe!?save_in_result_field@Item@@UAEX_N@Z() mysqld.exe!?save_in_result_field@Item@@UAEX_N@Z() mysqld.exe!?save_in_result_field@Item@@UAEX_N@Z() KERNEL32.DLL!BaseThreadInitThunk() ntdll.dll!RtlInitializeExceptionChain() ntdll.dll!RtlInitializeExceptionChain() 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. 如果在此之后看不到任何消息,则说明出现了严重错误…… @ Item @@ UAEX_N @ Z()mysqld.exe!?save_in_result_field @ Item @@ UAEX_N @ Z()mysqld.exe!?save_in_result_field @ Item @@ UAEX_N @ Z()mysqld.exe!?save_in_result_field @ Item @@ UAEX_N @Z()KERNEL32.DLL!BaseThreadInitThunk()ntdll.dll!RtlInitializeExceptionChain()ntdll.dll!RtlInitializeExceptionChain() http://dev.mysql.com/doc/mysql/en/crashing.html上的手册页包含信息应该可以帮助您找出导致崩溃的原因。

I hope someone will help me out Thanks. 我希望有人能帮助我。谢谢。

From this content in your question, "Server version: 10.1.22-MariaDB key_buffer_size=16777216 read_buffer_size=262144 max_used_connections=1 max_threads=1001 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787106 K ...." 从您问题中的此内容开始,“服务器版本:10.1.22-MariaDB key_buffer_size = 16777216 read_buffer_size = 262144 max_used_connections = 1 max_threads = 1001 thread_count = 1 mysqld可能最多使用key_buffer_size +(read_buffer_size + sort_buffer_size)* max_threads = 787106 K ....“

with max_threads=1001 clue above - check for max_connections in your my.ini or .cnf. 上面具有max_threads=1001线索-检查my.ini或.cnf中的max_connections。 Lowering max_connections to = 100 may or may not help get you past the BaseThreadInitThunk() ntdll.dll! 将max_connections降低到= 100可能会或可能不会帮助您摆脱BaseThreadInitThunk()ntdll.dll!

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM