☰

MySQL 突然重启

tag-icon • tag-icon mysql
MySQL 突然重启

请查看下面的日志并找出 MySQL 突然重启的原因？

110324 17:19:37 - mysqld 收到信号 11；这可能是因为您遇到了错误。也可能是此二进制文件或它所链接的某个库已损坏、构建不当或配置错误。此错误也可能由硬件故障引起。我们将尽力收集一些信息，希望这些信息有助于诊断问题，但由于我们已经崩溃，肯定出了问题，这可能会失败。

key_buffer_size=2097152 read_buffer_size=2093056 max_used_connections=155 max_connections=800threads_connected=105 mysqld 有可能使用最多 key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3275641 K 字节的内存，希望这样没问题；如果不行，请减少等式中的某些变量。

thd=0x21525240 尝试回溯。您可以使用以下信息找出 mysqld 死机的位置。如果此后没有看到任何消息，则表明出现了严重错误...无法确定线程，fp=0x46946088，回溯可能不正确。堆栈范围完整性检查正常，回溯如下：（无）fp=0x21525240 的新值完整性检查失败，终止堆栈跟踪！请阅读 http://dev.mysql.com/doc/mysql/en/using-stack-trace.html 并按照有关如何解决堆栈跟踪的说明进行操作。已解决的堆栈跟踪对诊断问题更有帮助，因此请解决它尝试获取一些变量。某些指针可能无效并导致转储中止... thd->query at 0x2aab98514ee0 是无效指针 thd->thread_id=3133802 手册页位于 http://www.mysql.com/doc/en/Crashing.html 包含可帮助您找出导致崩溃的原因的信息。

当前正在运行的进程数：0 110324 17:19:37 mysqld 已重新启动 110324 17:19:37 [警告] 复制启动选项的语法已弃用，并将在 MySQL 5.2 中删除。请改用“CHANGE MASTER”。110324 17:19:38 InnoDB：数据库未正常关闭！InnoDB：开始崩溃恢复。 InnoDB：从 .ibd 文件中读取表空间信息... InnoDB：从双写 InnoDB：缓冲区中恢复可能半写的数据页... 110324 17:19:42 InnoDB：根据 InnoDB 处的检查点开始日志扫描：日志序列号 75 131221842。InnoDB：正在进行恢复：扫描到日志序列号 75 132702399 110324 17:19:43 InnoDB：开始将一批日志记录应用到数据库... InnoDB：进度百分比：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：应用批处理已完成 InnoDB：在 MySQL 复制从属中，最后一个主 binlog 文件 InnoDB：位置 0 232，文件名为 lalithamba-bin.003081 InnoDB：最后一个 MySQL binlog 文件位置 0 31496822，文件名 /data/db/MySql_5.0.41/log/mysql_repl_log/amritamba-bin.009607 110324 17:19:49 InnoDB：已启动；日志序列号 75 132702399 110324 17:19:49 [注意] 使用 /data/db/MySql_5.0.41/log/mysql_repl_log/amritamba-bin 在崩溃后恢复 110324 17:19:50 [注意] 开始崩溃恢复... 110324 17:19:50 [注意] 崩溃恢复完成。 110324 17:19:51 [注意] /usr/local/mysql/bin/mysqld：准备好连接。版本：'5.0.41-log' 套接字：'/data/db/MySql_5.0.41/mysql.sock' 端口：3306 MySQL 社区服务器 (GPL) 110324 17:56:48 [注意] /usr/local/mysql/bin/mysqld: 正常关闭

110324 17:56:50 InnoDB：正在开始关机... 110324 17:56:53 InnoDB：关机完成；日志序列号 75 132702778 110324 17:56:53 [注意] /usr/local/mysql/bin/mysqld：关机完成

110324 17:56:53 mysqld 结束

110324 17:56:56 mysqld 已启动 110324 17:56:56 [警告] 复制启动选项的语法已弃用，并将在 MySQL 5.2 中删除。请改用“CHANGE MASTER”。110324 17:56:58 InnoDB：已启动；日志序列号 75 132702778 110324 17:56:58 [注意] /usr/local/mysql/bin/mysqld：已准备好连接。版本：'5.0.41-log' 套接字：'/data/db/MySql_5.0.41/mysql.sock' 端口：3306 MySQL 社区服务器 (GPL) 110324 17:57:20 [注意] 从属 SQL 线程已初始化，在日志'lalithamba-bin.003081'的位置 31228372 处开始复制，中继日志'/data/db/MySql_5.0.41/log/mysql_repl_log/amritamba_mysql_relaylog.005857' 位置：31228514 110324 17:57:20 [注意] 从属 I/O 线程：已连接到主服务器'[电子邮件保护]:3306'，在日志'lalithamba-bin.003081'的位置 31228372 处开始复制

答案1

你的内存统计数据接近疯狂：

key_buffer_size=2097152
read_buffer_size=2093056
max_used_connections=155
max_connections=800
threads_connected=105 

It is possible that mysqld could use up to  key_buffer_size + 
(read_buffer_size +  sort_buffer_size)*max_connections = 
3 275 641 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

这意味着在崩溃时，您的 mysqld 很可能已被 OOM 终止程序或操作系统中的类似机制终止。如果是这种情况，则内核消息日志（而不是 MySQL 日志）中将包含更多信息，其时间戳与崩溃消息相同或相似（110324 17:19:37 = 2011 年 3 月 24 日，当地时间 17:19:37）。

另外，您应该认真检查一下 MySQL 配置。不仅仅是内存问题，您的复制配置也会产生启动警告，而且您使用的版本 (5.0.41) 已经严重过时（当前版本比 5.5 早两个主要版本）。您使用的 MySQL 版本于 2007 年 5 月 1 日发布，距今已有近 4 年。

这在任何生产配置中都是不适用的。

相关内容