【发布时间】：2016-06-20 13:53:10
【问题描述】：
我现在真的很困惑如何从我的 ibdata1 中获取当前结果的正确页码。大多数文档都包含并指示这样做：
启用此监视器后，我们必须查看 MySQL 错误日志 (/var/log/mysql/error.log) 才能找到损坏表的页面索引： 表：名称数据库/sp_account，id 0 85，列 23，索引 2，appr.rows 220 ... 索引：名称 PRIMARY，id 0 215，字段 1/22，uniq 1，类型 3 根页面 401，appr.key vals 220，叶子页面 3，大小页面 4 ... 在此输出中，它表明我们必须查看位于提取页面的 0-215 子目录中的页面（即 pages-1328713071/FIL_PAGE_INDEX/0-215/）。 然后，我们必须将页面文件合并为一个： 查找 pages-1328713071/FIL_PAGE_INDEX/0-215/ -type f -name '*.page' |排序-n | xargs 猫 > 合并文件但是，我这里是这样的：
表：名称 db/tablename，id 512，标志 29，列 16，索引 9，appr.rows 0 列：id：DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4； createdAt: DATA_FIXBINARY DATA_BINARY_TYPE len 5;更新时间：DATA_FIXBINARY DATA_BINARY_TYPE len 5； nid：DATA_VARMYSQL 长度 765； ngroup：DATA_VARMYSQL 长度 765；游览：DATA_VARMYSQL len 765；值：DATA_VARMYSQL 长度 765；行动：DATA_VARMYSQL 长度 765； IP地址：DATA_VARMYSQL len 765；浏览器：DATA_VARMYSQL len 765； isMonitoring：DATA_INT DATA_BINARY_TYPE len 1； isEmbedded：DATA_INT DATA_BINARY_TYPE len 1；公司 ID：DATA_INT DATA_BINARY_TYPE len 4； DB_ROW_ID：DATA_SYS prtype 256 len 6； DB_TRX_ID：DATA_SYS prtype 257 len 6； DB_ROLL_PTR：DATA_SYS prtype 258 len 7； 索引：名称 PRIMARY，id 586，字段 1/15，uniq 1，类型 3 根页面 3，appr.key vals 100，叶子页面 1，大小页面 1如果您会注意到文档中第一个的 PRIMARY KEY id 值是 id 0 215，那么我的结果中只有这个 id 586。
请帮助我，任何帮助都非常感谢。
干杯，
【问题讨论】：
-
有什么帮助吗？我尝试不使用 ibdata 并执行丢弃和导入表空间，但出现错误消息： Mar
iaDB [mydbrecover]> alter table import tablespace;显示警告； ERROR 1030 (HY000): 从存储引擎得到错误-1 +--------+------+--------- -------------+ |水平 |代码 |留言 | +--------+------+---------------------------------- + |错误 | 1030 |从存储引擎得到错误-1 | +--------+------+---------------------------------- + 1 行（0.00 秒）
-
我写了这个工具，并不能真正理解你的问题。试着解释整个故事，也许我能帮上忙
-
@akuzminsky - 感谢您对此的重视。好吧，根据文档，当我启用或创建用于监视 InnoDB 的表时，我需要检查它以确定有助于我们修复它的索引页面。根据我读到的内容，他在 INDEX id 0 215 上找到了它，然后他用它来创建一个已经合并的文件。然后解析合并后的文件，输出为txt文件。所以，就我而言，输出是这个 INDEX: name PRIMARY, id 586, fields 1/15, uniq 1, type 3 所以只有 586 如果是这种情况，我该如何使用它和正确的流程是什么？
-
那个文档太旧了。使用表监视器获取 table/index_id 是没有意义的。因为如果您删除了一个表，它将无法用于表监视器。如果表损坏，则无法启动 MySQL。
-
因此您需要不同的方式来了解 index_id。哪一个完全取决于您的失败，但您在原始问题中没有提到这一点
标签： mysql linux innodb disaster-recovery