mysql5.7 强制 innodb 恢复
要调查数据库页面损坏,您可以使用 select … into outfile. 通常,通过这种方式获得的大部分数据都是完整的。严重的损坏可能导致语句或 后台操作意外退出或断言,甚至导致 前滚恢复崩溃。在这种情况下,您可以使用该 选项来强制启动存储引擎,同时阻止后台操作运行,以便您可以转储表。例如,您可以在重新启动服务器之前将以下行添加到选项文件的部分:
[mysqld] innodb_force_recovery = 1
有关使用选项文件的信息,请参阅 第 4.2.2.2 节,“使用选项文件”。
警告
仅innodb_force_recovery 在紧急情况下设置为大于 0 的值,以便您可以启动innodb和转
储您的表。在这样做之前,请确保您拥有数据库的备份副本,以防需要重新创建它。4 或
更大的值可能会永久损坏数据文件。仅 innodb_force_recovery在您在数据库的单独物理副
本上成功测试设置后,才能在生产服务器实例上使用 4 或更高的设置。强制innodb恢复
时,您应该始终从该值开始, innodb_force_recovery=1并且只在必要时逐步增加该值。
innodb_force_recovery默认为0(正常启动,不强制恢复)。允许的非零值为 innodb_force_recovery1 到 6。较大的值包括较小值的功能。例如,值 3 包括值 1 和 2 的所有功能。
如果您能够以 innodb_force_recovery 3 或更小的值转储您的表,那么您相对安全,只有损坏的单个页面上的一些数据会丢失。4 或更大的值被认为是危险的,因为数据文件可能会永久损坏。值 6 被认为是极端的,因为数据库页面处于过时状态,这反过来可能会给b 树 和其他数据库结构带来更多损坏。
作为安全措施,innodb防止 insert、 update、 或 大于 0delete时的操作 。只读模式下 4 位或更多位的设置。
1 (srv_force_ignore_corrupt)
让服务器即使检测到损坏的 页面也能运行。尝试 跳过损坏的索引记录和页面,这有助于转储表。 select * from tbl_name
2 (srv_force_no_background)
阻止主线程和任何清除线程运行。如果在清除操作期间发生意外退出,此恢复值会阻止它。
3 (srv_force_no_trx_undo)
崩溃恢复后 不运行事务 回滚。
4 (srv_force_no_ibuf_merge)
防止插入缓冲区合并操作。如果它们会导致崩溃,请不要这样做。不计算表 统计信息。此值可能会永久损坏数据文件。使用此值后,准备删除并重新创建所有二级索引。设置 innodb为只读。
5 (srv_force_no_undo_log_scan)
启动数据库时 不查看撤消日志innodb:甚至将不完整的事务视为已提交。此值可能会永久损坏数据文件。设置innodb为只读。
6 (srv_force_no_log_redo)
不执行与恢复相关的重做日志 前滚。此值可能会永久损坏数据文件。使数据库页面处于过时状态,这反过来可能会给 b 树和其他数据库结构带来更多损坏。设置 innodb为只读。
您可以select从表中转储它们。innodb_force_recovery值为 3 或更少时,您可以或 drop表格 create。drop table也支持 innodb_force_recovery大于 3 的值,直到 mysql 5.7.17。从 mysql 5.7.18 开始, drop table不允许使用 innodb_force_recovery大于 4 的值。
如果您知道给定表导致回滚时意外退出,则可以将其删除。如果遇到由于批量导入失败而导致的失控回滚alter table,您可以终止 mysqld 进程并设置 innodb_force_recovery为 3在不回滚的情况下启动数据库,然后drop是导致失控回滚的表。
如果表数据中的损坏阻止您转储整个表内容,则带有子句的查询可能能够转储损坏部分之后的表部分。 order by primary_key desc
innodb_force_recovery 如果start 需要 一个高值innodb,则可能存在损坏的数据结构,这可能导致复杂查询(包含where、order by或其他子句的查询)失败。在这种情况下,您可能只能运行基本select * from t 查询。
到此这篇关于mysql 强制innodb恢复innodb_force_recovery详解的文章就介绍到这了,更多相关mysql innodb恢复innodb_force_recovery内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
发表评论