2

我有一个包含 InnoDB 表的数据库，其中一个 InnoDB 表被标记为损坏（我知道数据丢失等）。但是，当我重新启动 MySQL 时，它不会崩溃。

我预计它会崩溃，但事实并非如此。（我之前读过如果innodb表损坏，mysql服务器将停止）

它现在不应该崩溃吗？

innodb 是我的默认数据库引擎。

4

1 回答 1

2

损坏的表不一定会导致崩溃。不过，您应该修复表，如果可能的话，从备份中重新加载表。对损坏的表进行操作充其量是不稳定的，无论如何，正如您已经发现的那样，它不会给您正确的结果。

不要相信系统没有“爆炸”这一事实——一个数据库有几个中间状态。你现在所处的那个很可能是“我还没有爆炸，我正在等待腐败传播和污染其他表的数据”。如果您知道该表已损坏，请立即行动。

关于修复 InnoDB 表，请参阅如何修复 InnoDB 表？.

要验证 InnoDB 表是否损坏，请参阅https://dba.stackexchange.com/questions/6191/how-do-you-identify-innodb-table-corruption。

检测腐败

为此，您需要进行验收测试，该测试将检查大量数据并为其提供一份干净的健康证明——或不这样做。将表导出到 SQL 并查看它是否可能，和/或对元组基数和/或关系进行检查......你明白我的意思。在预计没有人写入的表上，因此任何修改都等于损坏，磁盘文件的 MD5 可能会更快。

为了使事情更高效（例如在生产系统中），您可以考虑文件快照、数据库复制，甚至是高可用性。这些方法将检测程序损坏（例如流氓更新），但可能无法检测到主服务器上的某些硬件损坏（给出错误否定：从服务器上的检查成功，并且主服务器上的数据仍然损坏）或可能会在从站中发生意外（失败并引发误报，因为主站上的数据实际上是未受污染的）。

监控系统重要统计数据非常重要（而且高效），既可以捕捉即将发生的故障的最初症状（例如使用 SMART），也可以为取证调查提供数据（“有趣的是，每次数据库发生故障时，它总是在系统负载突然达到峰值——如果我们找出造成这种情况的原因会怎样？”）。

当然，还要依靠完整和充分的备份（并且不时地运行测试恢复。去过那里，做到了，把我的屁股交给了我）。

腐败原因[与原始问题无关]

损坏源因软件设置而异。当然，一般来说，一定有什么东西 侵入了链条并造成了严重破坏。server memory representation-writer process-OS handle-journaling-IOSS-OS cache-disk-disk cache-internal file layout

不正确的系统关闭可能会在多个级别上造成混乱，从而阻止数据在管道的任何阶段写入。

最后阶段对磁盘上的文件进行人工处理（使用自己的管道，服务器对此一无所知）。

存在其他更深奥的可能性：

  • 硬盘本身的细微固件/硬件故障，
    • 由于磁盘磨损或有缺陷的固件甚至有缺陷的固件更新，意外且可能无法恢复（我似乎记得几年前，日立的声学管理更新可以针对稍微不同的模型运行。更新磁盘后“认为”它有比实际更多的缓存，并且写入缓存中不存在的区域当然直接进入天堂）。
    • “故意的”并且可能可以恢复：有时可能会使用hdparm. 如果每个组件都适合该级别的性能并且知道它或者至少能够发出信号，那么将磁盘设置为最高性能就很好。有时，您收到的所有“警告”都是系统故障。
  • 进程空间或 IOSS 损坏：在 Apache 安装中看到了这种情况，可能由于 suid root 的 CGI，access.log 文件充满了应该进入用户浏览器的 GIF 图像流。修复了，什么也没发生，但如果它是一个更重要的文件而不是日志......？此类问题可能难以诊断，您可能需要检查所有日志文件以查看某些应用程序是否注意到或做了任何不良行为。
  • 硬盘扇区重定位：传说中的发生，我自己从未见过，但现代硬盘有“备用”扇区，它们将交换有缺陷的扇区以保持“零缺陷”表面。除了如果有缺陷的扇区碰巧不再可读并被替换为空扇区，则净效果与该扇区突然归零相同。您可以使用 SMART 报告（hddhealth或smartctl）轻松检查这一点。

当然，还存在更多其他可能性，具体取决于设置。谷歌搜索文件损坏发现数百万页；添加到查询中的有用术语是文件系统（ext4，NTFS，brtfs，...），硬盘制造商和型号，操作系统，软件问题，安装的其他软件。

于 2012-11-06T19:15:43.330 回答