我的服务器似乎在以前不会崩溃的负载下崩溃/重新启动。
我该如何解决这个问题？
VPS 运行的是 Centos 6.x，8GB 内存
- Mysql 在以前不可能发生的负载下崩溃/重新启动。
- 崩溃后，日志中弹出此错误：
InnoDB: Unable to lock ./ibdata1, error: 11。这可能是因为 mysql 从崩溃中恢复并在尚未完全死机时尝试重新启动吗？
我不确定这是否与崩溃有关，因为它在数据库尝试重新启动时显示。有几行：
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
然后日志继续：
141207 18:58:06 [ERROR] Plugin 'InnoDB' init function returned error.
141207 18:58:06 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
141207 18:58:06 [ERROR] Failed to initialize plugins.
141207 18:58:06 [ERROR] Aborting
141207 18:58:06 [Note] /usr/libexec/mysqld: Shutdown complete
141207 18:58:06 mysqld_safe Number of processes running now: 1
141207 18:58:06 mysqld_safe mysqld process hanging, pid 15456 - killed
141207 18:58:06 mysqld_safe mysqld restarted
141207 18:58:06 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141207 18:58:06 InnoDB: Initializing buffer pool, size = 6.0G
141207 18:58:06 InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
141207 18:58:06 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: Last MySQL binlog file position 0 14626, file name /var/lib/mysql/mysql-bin.000892
141207 18:58:06 InnoDB: Started; log sequence number 3 2358701171
141207 18:58:06 [Note] Recovering after a crash using /var/lib/mysql/mysql-bin
141207 18:58:06 [Note] Starting crash recovery...
141207 18:58:06 [Note] Crash recovery finished.
141207 18:58:06 [Note] Event Scheduler: Loaded 0 events
141207 18:58:06 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
似乎没有太多信息可以解释为什么 mysql 现在这么弱。考虑到没有对 my.cnf 进行任何更改或其他操作，我认为这不是配置问题。
我应该在哪里寻找有关此问题的更准确的数据？或者我可以进行更“硬”的重置来让一切恢复正常吗？
编辑-最新日志
在运行当前崩溃的负载之前（以前它可以正常处理），清理我的日志文件并重新启动服务器。
这是日志文件的最新输出，所有内容来自后我在运行任务之前执行了重启。据我所知，没有任何线索可以解释崩溃的原因，对吗？
141207 20:50:34 mysqld_safe Number of processes running now: 0
141207 20:50:34 mysqld_safe mysqld restarted
141207 20:50:35 InnoDB: Initializing buffer pool, size = 5.0G
141207 20:50:35 InnoDB: Error: cannot allocate 5368725504 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 36878736 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
141207 20:50:49 InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 3 2681111025
141207 20:50:49 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 3 2686353408
InnoDB: Doing recovery: scanned up to log sequence number 3 2691596288
InnoDB: Doing recovery: scanned up to log sequence number 3 2696839168
InnoDB: Doing recovery: scanned up to log sequence number 3 2702082048
InnoDB: Doing recovery: scanned up to log sequence number 3 2707324928
InnoDB: Doing recovery: scanned up to log sequence number 3 2712567808
InnoDB: Doing recovery: scanned up to log sequence number 3 2717810688
InnoDB: Doing recovery: scanned up to log sequence number 3 2723053568
InnoDB: Doing recovery: scanned up to log sequence number 3 2728296448
InnoDB: Doing recovery: scanned up to log sequence number 3 2733539328
InnoDB: Doing recovery: scanned up to log sequence number 3 2738782208
InnoDB: Doing recovery: scanned up to log sequence number 3 2739356250
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 237115 row operations to undo
InnoDB: Trx id counter is 0 15792384
141207 20:50:50 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 157660, file name /var/lib/mysql/mysql-bin.000902
InnoDB: Starting in background the rollback of uncommitted transactions
141207 20:51:07 InnoDB: Rolling back trx with id 0 15789484, 237115 rows to undo
InnoDB: Progress in percents: 1141207 20:51:07 InnoDB: Started; log sequence number 3 2739356250
141207 20:51:07 [Note] Recovering after a crash using /var/lib/mysql/mysql-bin
141207 20:51:07 [Note] Starting crash recovery...
141207 20:51:07 [Note] Crash recovery finished.
2 3 4141207 20:51:07 [Note] Event Scheduler: Loaded 0 events
141207 20:51:07 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
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 100
InnoDB: Rolling back of trx id 0 15789484 completed
141207 20:51:11 InnoDB: Rollback of non-prepared transactions completed
141207 20:51:20 [ERROR] /usr/libexec/mysqld: Table './bck_wpdb/bck_statpress' is marked as crashed and should be repaired
141207 20:51:20 [Warning] Checking table: './bck_wpdb/bck_statpress'
141207 20:52:19 [ERROR] /usr/libexec/mysqld: Table './mdi_db1/mdi_statpress' is marked as crashed and should be repaired
141207 20:52:19 [Warning] Checking table: './mdi_db1/mdi_statpress'
答案1
此日志条目是最可能出现的问题的关键：
141207 20:50:34 mysqld_safe Number of processes running now: 0
如果在此行之前没有包含堆栈跟踪的极其详细的日志消息块，则 MySQL 实际上并未崩溃……内核正在终止它，因为另一个进程（例如 Web 服务器）正在对系统内存提出大量要求。为了减轻压力并避免即将发生的系统范围崩溃或锁定，内核会寻找要终止的进程。
$ cat /var/log/messages | egrep -i 'mysql|oom|kernel'
跟踪系统日志的踪迹。您很可能需要控制您的网络服务器。
上述日志条目之后的所有内容都只是 MySQL 尝试重新启动自身并从被终止中恢复。在严重内存短缺的情况下，它将无法立即重新启动，因为根本没有足够的系统内存可用：
141207 20:50:35 InnoDB: Error: cannot allocate 5368725504 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 36878736 bytes. Operating system errno: 12
在 Linux 中，错误 12 确实是“内存不足”。而且，再说一遍，这不是 MySQL 说内存不足，而是内核说的。
值得注意的是，对于 8GB 服务器来说，5,368,725,504 字节似乎是一个非常大的缓冲池，除非服务器正在执行没有什么除了运行 MySQL 之外。共享工作负载的主观经验法则是为缓冲池分配不超过 50% 的系统内存。
您在此处分配的内存量由 MySQL 声明和持有，其他进程无法使用。通常，对于此特定参数，越大越好……但只能在基于可用资源的合理范围内。