当mysqldump / mysqlcheck时MySQL崩溃

Question

每当我尝试备份或检查Windows server 2012上的所有表mysql服务器崩溃时，我都会在我的开发环境中使用XAMPP堆栈。数据库密码在DB中有更多的1100+表。我把下面的原木包括在内。

InnoDB:页尾转储2017-09-24 13:58:35 7 7dc :未压缩页，在field1 2521749199中存储校验和，计算field1: crc32 2344073126，to 1121903210，to 3735928559，存储在field2 0中的校验和，field2的计算校验和: crc32 2344073126，innodb 2892594725，无3735928559，页LSN 02936733816，页面0处低4字节的LSN，页号(如果已经存储到页号) 34，空间id (如果用>= MySQL-4.1.1创建并已存储) 1767 InnoDB:页面类型17855意味着索引InnoDB: page可能是索引页，其中索引id为1522 InnoDB：(表“加密”的索引“主”)。“300令牌”) 2017-09-24 13:58:35错误InnoDB:您的操作系统也有可能损坏了自己的文件缓存。2017-09-24 13:58:35 2012错误InnoDB:和重新启动您的计算机删除错误。2017-09-24 13:35 2012年错误InnoDB:如果腐败页面是索引页，您也可以尝试2017-09-24 13:58:35 2012错误InnoDB:通过倾倒、丢弃和重新使用2017-09-24 13:58:35修复腐败-09-24 13:58:35错误表:腐败表。您可以使用CHECK 2017-09-24 13:58:35 2012错误InnoDB: TABLE扫描您的表是否损坏。2017-09-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 7 7dc : buf0lru.cc代码行2394 InnoDB中的线程2012断言失败: InnoDB: bpage->buf_fix_count == 0 InnoDB:我们有意生成一个内存陷阱。InnoDB:向http://bugs.mysql.com提交详细的bug报告。InnoDB:如果您遇到重复的断言失败或崩溃，甚至在mysqld启动后立即出现InnoDB：，那么InnoDB表空间中可能会出现InnoDB:损坏。请参阅InnoDB：http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB:关于强制恢复。170924 13:58:35错误mysqld获得了异常0x80000003；这可能是因为您碰到了错误。也有可能这个二进制文件或它所链接的一个库是损坏的、构建不当的或配置错误的。此错误也可能是由于硬件故障造成的。 若要报告此错误，请参阅https://mariadb.com/kb/en/reporting-bugs 我们将尽力收集一些信息，希望能帮助诊断问题，但既然我们已经崩溃，某些事情肯定是错误的，这可能会失败。 服务器版本: 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字节的内存希望，如果没有，可以减少一些变量。 线程指针: 0x0尝试回溯。您可以使用以下信息查找mysqld的死亡地点。如果你在这之后没有看到任何信息，事情就会变得非常糟糕.mysqld.exe!?save_in_result_field@Item@@UAEX_N@Z() mysqld.exe my_parameter_handler() mysqld.exe!my_wildcmp_mb_bin()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的手册页面包含的信息应该可以帮助您找到造成崩溃的原因。

我希望有人能帮助我，谢谢。

Answer 1

从您的问题“服务器版本: 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.。

上面有max_threads=1001提示-检查my.ini或.cnf中是否有max_connections。将max_connections降低到= 100可能会帮助您通过BaseThreadInitThunk() ntdll.dll！