☰

MySql：过去三周，强大的服务器每天都崩溃

tag-icon • tag-icon mysql ubuntu-16.04
MySql：过去三周，强大的服务器每天都崩溃

我在 Ubuntu 16.x 上运行最新版本 MySql 的 MySQL 服务器每天都会崩溃一两次。有时它会很快（10 分钟）自行修复。有时我必须重新启动并执行 fsck 才能让一切再次运行。

什么原因造成这个情况？

到目前为止我尝试过的事情：

  • RAM 从 1.5GB 增加至 5GB。
  • 硬件升级：主板、处理器、RAM（DDR4），但这没有帮助（它运行的是 7 年前的处理器，现在运行的是第 7 代酷睿 I5）。
  • 设置 UFW 防火墙以确保它不是由攻击 MySQL 或其他服务的机器人引起的。
  • 在 my.cnf 中，将 innodb_buffer_pool_size 从 128MB 更改为 500MB。没有帮助，但仍然在原地
  • 我已经运行：mysqlcheck -u root -p --auto-repair --optimize --all-databases 多次。没有帮助
  • 在 my.cnf 中，将 mysql max_connections 从 151 减少到 80，并重新启动 mysql。没有帮助
  • 将 apache MaxRequestWorkers 从 150 减少到 100。没用。仍然崩溃。
  • 我已经有 1GB 的交换文件了。留下它。
  • 搜索了 Apache2 日志、SysLog 以及任何其他看似合适的日志，但没有发现任何引起我注意的内容。
  • 关闭服务器并尝试将虚拟机移动到另一个驱动器，但由于文件错误而失败。
  • 我最近怀疑这是由坏块引起的，但运行坏块似乎在完成 25% 时触发了崩溃。在 fsck 期间，我看到了以下内容：fsck 严重介质错误，dev sda，扇区 147306432

以下是典型的 mysql 错误日志：

2017-04-20T18:43:46.958430Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费了 11791ms。设置可能不是最佳的。（在此期间，flu shed=92 和 evicted=0。）
2017-04-20T18:44:11.989905Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费了 6822ms。设置可能不是最佳的。（在此期间，flushed=8 和 evicted=0。）
2017-04-20T18:44:49.145162Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费了 5021ms。设置可能不是最佳的。 （在此期间，flu hed=0 且 evicted=0。）
2017-04-20T18:45:22.322429Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费 26338ms。设置可能不是最佳的。（在此期间，flu shed=10 且 evicted=0。）
2017-04-20T18:45:53.926808Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费 4510ms。设置可能不是最佳的。（在此期间，flu hed=0 且 evicted=0。）
2017-04-20T18:46:03.097400Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费 5384ms。这些设置可能不是最佳的。（在此期间，flu hed=13 和 evicted=0。）
2017-04-20T18:46:39.247467Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费了 14848ms。这些设置可能不是最佳的。（在此期间，flu shed=8 和 evicted=0。）
2017-04-20T18:47:16.271672Z 0 [注意] InnoDB：page_cleaner：1000ms 预期循环花费了 29107ms。这些设置可能不是最佳的。 (在此期间，flu shed=8 且 evicted=0。)
2017-04-20T18:47:53.669557Z 0 [注意] InnoDB: page_cleaner: 1000ms 预期循环耗时 5969ms。设置可能不是最佳的。 (在此期间，flus hed=37 且 evicted=0。)
2017-04-20T18:50:23.879411Z 0 [注意] InnoDB: page_cleaner: 1000ms 预期循环耗时 37671ms。设置可能不是最佳的。 （在此期间，flu shed=6 且 evicted=0。）
2017-04-20T18:55:07.190725Z 0 [警告] 更改的限制：max_open_files：1024（请求 5000）2017-04-20T18:55:07.235759Z 0 [警告] 更改的限制：table_open_cache：431（请求 2000）
2017-04-20T18:55:10.486670Z 0 [警告] 带有隐式 DEFAULT 值的 TIMESTAMP 已弃用。请使用 --explicit_defaults_for_times tamp 服务器选项（有关更多详细信息，请参阅文档）。
2017-04-20T18:55:11.563578Z 0 [注意] /usr/sbin/mysqld (mysqld 5.7.17-0ubuntu0.16.04.2) 作为进程 24701 启动...
2017-04-20T18:55:21.979225Z 0 [注意] InnoDB: PUNCH HOLE 支持可用
2017-04-20T18:55:21.979250Z 0 [注意] InnoDB: 互斥锁和 rw_locks 使用 GCC 原子内置函数
2017-04-20T18:55:21.979253Z 0 [注意] InnoDB: 使用事件互斥锁 2017-04-20T18:55:21.979256Z 0 [注意] InnoDB: GCC 内置 __atomic_thread_fence() 用于内存屏障
2017-04-20T18:55:21.979259Z 0 [注意] InnoDB: 压缩表使用 zlib 1.2.8
2017-04-20T18:55:21.979262Z 0 [注意] InnoDB: 使用 Linux 原生 AIO 2017-04-20T18:55:22.004800Z 0 [注意] InnoDB: 池数量：1 2017-04-20T18
:55:22.060762Z 0 [注意] InnoDB: 使用 CPU crc32 指令
2017-04-20T18:55:22.104584Z 0 [注意] InnoDB: 初始化缓冲池，总大小 = 128M，实例 = 1，块大小 = 128M
2017-04-20T18:55:24.184701Z 0 [注意] InnoDB: 已完成缓冲池初始化
2017-04-20T18:55:24.210160Z 0 [注意] InnoDB：如果 mysqld 执行用户被授权，则可以更改页面清理线程优先级。请参阅 setpriority() 的手册页。2017-04-20T18
:55:26.405242Z 0 [注意] InnoDB：支持的最高文件格式是 Barracuda。
2017-04-20T18:55:27.508456Z 0 [注意] InnoDB：日志扫描已超过检查点 lsn 35288448161
2017-04-20T18:55:27.508478Z 0 [注意] InnoDB：正在进行恢复：扫描至日志序列号 35288448170
2017-04-20T18:55:27.508630Z 0 [注意] InnoDB：正在进行恢复：扫描至日志序列号 35288448170 2017-04-20T18
:55:27.508634Z 0 [注意] InnoDB：数据库未正常关闭！
2017-04-20T18:55:27.508637Z 0 [注] InnoDB：开始崩溃恢复。
2017-04-20T18:56:16.516761Z 0 [注] InnoDB：已删除临时表空间数据文件：“ibtmp1”
2017-04-20T18:56:16.516785Z 0 [注] InnoDB：为临时表创建共享表空间
2017-04-20T18:56:16.516817Z 0 [注] InnoDB：将文件“./ibtmp1”大小设置为 12 MB。物理写入文件已满；请稍候...
2017-04-20T18:56:16.621736Z 0 [注意] InnoDB：文件'。/ibtmp1'大小现在为 12 MB。2017-04-20T18
:56:16.622203Z 0 [注意] InnoDB：找到 96 个重做回滚段。96 个重做回滚段处于活动状态。2017-04-20T18
:56:16.622211Z 0 [注意] InnoDB：32 个非重做回滚段处于活动状态。
2017-04-20T18:56:16.622565Z 0 [注释] InnoDB: 正在等待清除开始
2017-04-20T18:56:16.672708Z 0 [注释] InnoDB: 5.7.17 已启动；日志序列号 35288448170
2017-04-20T18:56:16.672708Z 0 [注释] InnoDB: page_cleaner: 1000ms 预期循环耗时 52462ms。设置可能不是最佳的。 （在此期间，flushed=0 且 evicted=0。）
2017-04-20T18:56:16.673192Z 0 [注意] InnoDB：从 /var/lib/mysql/ib_buffer_pool 加载缓冲池
2017-04-20T18:56:16.702959Z 0 [注意] 插件‘FEDERATED’已被禁用。2017-04-20T18
:56:16.851553Z 0 [错误] 函数‘archive’已存在
2017-04-20T18:56:16.851568Z 0 [警告] 无法加载名为‘archive’且 soname 为‘ha_archive.so’的插件。
2017-04-20T18：56：16.851574Z 0 [错误] 函数“blackhole”已存在
2017-04-20T18:56:16.851575Z 0 [警告] 无法加载名为“blackhole”且 soname 为“ha_blackhole.so”的插件。
2017-04-20T18:56:16.851578Z 0 [错误] 函数“federated”已退出 2017-04-20T18:56:16.851579Z 0 [警告] 无法加载名为“federated”且 soname 为“ha_federated.so”的插件。
2017-04-20T18:56:16.851582Z 0 [错误] 函数“innodb”已存在 2017-04-20T18:56:16.851583Z 0 [警告] 无法加载名为“innodb”且 soname 为“ha_innodb.so”的插件。
2017-04-20T18:56:17.044733Z 0 [警告] 由于以下 SSL 库错误，无法设置 SSL：没有证书和私钥，SSL 上下文不可用
2017-04-20T18:56:17.044754Z 0 [注意] 服务器主机名（绑定地址）：'0.0.0.0'；端口：3306
2017-04-20T18：56：17.044761Z 0 [注] - '0.0.0.0' 解析为 '0.0.0.0'；
2017-04-20T18：56：17.044779Z 0 [注] 在 IP '0.0.0.0' 上创建服务器套接字。 2017-04-20T18：56：18.483575Z 0 [注] 事件调度程序：已加载 0 个事件
2017-04-20T18：56：18.483706Z 0 [注] 执行 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' 以获取使用弃用分区引擎的表列表。 您可以使用启动选项 '--disable-partition-engine-check' 跳过此检查。
2017-04-20T18：56：18.483716Z 0 [注] 非本地分区表列表的开始
2017-04-20T18：56：25.478293Z 0 [注] InnoDB：缓冲池加载于 170420 13：56：25 完成
2017-04-20T18：56：26.091240Z 0 [注] 非本地分区表列表的结束
2017-04-20T18：56：26.091423Z 0 [注] /usr/sbin/mysqld：已准备好连接。版本：'5.7.17-0ubuntu0.16.04.2' 套接字：'/var/run/mysqld/mysqld.sock' 端口：3306 (Ubuntu)
2017-04-20T18：56：26.155810Z 4 [错误] /usr/sbin/mysqld：表'。/example/wp_options'被标记为崩溃，应修复
2017-04-20T18：56：26.155889Z 5 [错误] /usr/sbin/mysqld：表'。/example/wp_options'被标记为崩溃，应修复
2017-04-20T18：56：26.156037Z 4 [警告]检查表：'。/example/wp_options'
2017-04-20T18：56：35.816730Z 4 [错误] /usr/sbin/mysqld：表'./example/wp_usermeta'被标记为崩溃，应修复
2017-04-20T18：56：35.816875Z 4 [警告]检查表：'./example/wp_usermeta'

答案1

最后两个要点表明了问题所在。您的坏块怀疑似乎是有根据的。

  • 尝试移动虚拟机时出现文件错误
  • 坏块每次都会在大约相同的位置崩溃。

在服务器运行时，将数据库转储到主机操作系统上的一个文件中。由于服务器崩溃了，并且您不知道当服务器崩溃时它到底访问了哪个表、数据库或记录，因此请花时间分别转储每个数据库，甚至每个表。希望坏块不会出现在您的数据中，而是出现在系统试图使用的某个文件中。无论如何，如果其中一个转储触发了崩溃，如果您想仔细检查两次，那么请将该表或数据库视为可疑，并尽可能手动检查它。

然后创建一个新的VM，在不同的物理磁盘，并安装所有必要的安装。导入转储数据，包括任何可疑数据的检查版本。对所有表进行一些随机数据完整性检查，尤其是针对从任何可疑转储构建的表。然后进行您认为合适的任何级别的测试，以确保新的 VM 和数据库正常运行并具有有效数据。

将新 VM 设为“实时”服务器，淘汰旧 VM，并开始备份/恢复包含崩溃服务器 VM 的其余物理驱动器。一旦您从该磁盘检索了所有或所有可用数据，您就可以确定其健康状况（可疑）以及您是否愿意信任它以进一步用于重要数据。也许可以将其用作放置目录/tmp或其他临时结构的地方，或用作交换空间，从而释放另一个（可能良好的）磁盘上的空间以用于重要数据。

相关内容