MYSQL被杀死了，从错误日志文件中看起来就像是在innodb崩溃恢复过程中。目前，如果我重新启动MYSQL，它会持续大约5或10分钟，然后被杀死。
我已经MySQLTuner运行，看看是否有任何有用的东西，而且唯一的建议是增加innodb_buffer_pool_size。我做到了，但它似乎没有帮助。
以下是错误日志文件从最后一次被杀死时的片段。
180307 17:35:02 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 1121705399
180307 17:35:02 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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
180307 17:35:02 InnoDB: Waiting for the background threads to start
180307 17:35:03 InnoDB: 5.5.44 started; log sequence number 1121705399
180307 17:35:03 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
180307 17:35:03 [Note] - '127.0.0.1' resolves to '127.0.0.1';
180307 17:35:03 [Note] Server socket created on IP: '127.0.0.1'.
180307 17:35:03 [Note] Event Scheduler: Loaded 0 events
180307 17:35:03 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.44-0+deb7u1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
Killed
180307 17:40:01 mysqld_safe Number of processes running now: 0
180307 17:40:01 mysqld_safe mysqld restarted
180307 17:40:01 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
180307 17:40:01 [Note] /usr/sbin/mysqld (mysqld 5.5.44-0+deb7u1) starting as process 24344 ...
180307 17:40:01 [Note] Plugin 'FEDERATED' is disabled.
180307 17:40:01 InnoDB: The InnoDB memory heap is disabled
180307 17:40:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180307 17:40:01 InnoDB: Compressed tables use zlib 1.2.7
180307 17:40:01 InnoDB: Using Linux native AIO
180307 17:40:01 InnoDB: Initializing buffer pool, size = 2.0G
Killed
180307 17:40:02 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Mysqltuner报告是：
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.44-0+deb7u1
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in InnoDB tables: 888M (Tables: 24)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 24
-------- Performance Metrics -------------------------------------------------
[--] Up for: 22s (113 q [5.136 qps], 41 conn, TX: 19K, RX: 7K)
[--] Reads / Writes: 100% / 0%
[--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 597.8M (7% of installed RAM)
[OK] Slow queries: 0% (0/113)
[OK] Highest usage of available connections: 0% (1/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/97.0K
[!!] Query cache efficiency: 0.0% (0 cached / 71 selects)
[OK] Query cache prunes per day: 0
[OK] Temporary tables created on disk: 20% (54 on disk / 267 total)
[OK] Thread cache hit rate: 97% (1 created / 41 connections)
[OK] Table cache hit rate: 90% (65 open / 72 opened)
[OK] Open file limit used: 4% (48/1K)
[OK] Table locks acquired immediately: 100% (62 immediate / 62 locks)
[!!] InnoDB data size / buffer pool: 888.0M/128.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
Variables to adjust:
query_cache_limit (> 1M, or use smaller result sets)
innodb_buffer_pool_size (>= 888M)
和SHOW GLOBAL STATUS输出：https://pastebin.com/A2Zrsu8m
和SHOW GLOBAL VARIABLES输出：https://pastebin.com/DPp7WC99
任何关于在哪里寻找或如何进一步诊断此问题的建议都将不胜感激。
答案 0 :(得分：1)
对my.cnf / ini [mysqld]部分的建议
key_buffer_size=1M # from 16M MyISAM will be used very little, if at all
innodb_buffer_pool_size=2G # from 128M and will be 1/4 of total RAM appx
innodb_log_file_size=1G # from 5M which is LESS than buffer-size = BAD
innodb_print_all_deadlocks=ON # from OFF - review error log daily
log_warnings=2 # from 1 to know when connections were rejected and possibly why.
max_allowed_packet=1M # from 16M RAM could be REQD per CONNECTION
如果您的SESSION需要超过1M MAP SET @ max_allowed_packet = 1000000000不允许使用1G缩写。 INfile大小的最大值。
并且为了更快地了解为什么它在不到15分钟内崩溃，
general_log=ON # from OFF so you have a total track prior to the crash.
如果由于这些ini更新而运行20分钟，则必须关闭 通用日志之前你有一个完整的硬盘驱动器！ 让我发布。请发帖 A）完整的Mysqltuner报告 B）ulimit -a所以我们可以验证你的open_files_limit不再是可用的80％ C）iostat -x在繁忙的时间，因此我们知道当时达到的IOPS。
如果仍然崩溃，请发帖 最后400行GENERAL_LOG 最后500行ERROR_LOG 转发显示全球变量。 当CRASHED，SHOW GLOBAL STATUS无法收集时。
感谢你今天早些时候的帖子，允许进行此分析。