Mysql Innodb数据库误删除了文件,怎么恢复?
发布网友
发布时间：2022-04-24 18:53
共5个回答
懂视网
时间：2022-04-08 01:19
ib_logfile正如你所说，它是INNODB的REDO、UNDO日志，并不是备份用的日志。
MYSQL可以通过BINLOG来恢复，但这个ib_logfile没什么恢复的作用，它主要是在事务中起一个前滚或后滚的作用。
mysql的innodb中事务日志ib_logfile
事务日志或称redo日志，在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数，调节
开启几组日志来服务于当前mysql数据库,mysql采用顺序，循环写方式，每开启一个事务时，
会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);
作用:在系统崩溃重启时，作事务重做；在系统正常时，每次checkpoint时间点，会将之前写入事务
应用到数据文件中。
引入一个问题：在m/s环境中,innodb写完ib_logfile后,服务异常关闭，会不会主库能用ib_logfile恢复数据，而
binlog没写导致从库同步时少少这个事务？从而导致主从不一致;
redo日志写入方式：
1.ib_logfile写入当前事务更新数据，并标上事务准备trx_prepare
2.写入bin-log
3.ib_logfile当前事务提交提交trx_commit
恢复方式:
如果ib_logfile已经写入事务准备,那么在恢复过程中，会依据bin-log中该事务是否存在恢复数据。
假设:
1）结束后异常,因没有写入bin-log，从库不会同步这个事务，主库上，重启时，在恢复日志中这个
事务没有commit，即rollback这个事务.
2）结束后异常，这会bin-log已经写入，从库会同步这个事务。主库依据恢复日志和bin-log，也正常恢复此事务
综上描述:bin-log写入完成，主从会正常完成事务；bin-log没有写入，主从库rollback事务;不会出现主从库不一致问题.
相关参数（全局&静态）:
innodb_log_buffer_size
innodb_log_file_size
innodb_log_files_in_group
innodb_log_group_home_dir
innodb_flush_log_at_trx_commit
innodb_log_buffer_size:事务日志缓存区,可设置1M~8M,默认8M,延迟事务日志写入磁盘,
把事务日志缓存区想象形如"漏斗"状,会不停向磁盘记录缓存的日志记录,而何时写入通过参数
innodb_flush_log_at_trx_commit控制,稍后解释,启用大的事务日志缓存,可以将完整运行大事
务日志，暂时存放在事务缓存区中,不必(事务提交前)写入磁盘保存,同时也起到节约磁盘空间占用;
innodb_log_file_size:控制事务日志ib_logfile的大小,范围5MB~4G；所有事务日志ib_logfile0+
ib_logfile1+..累加大小不能超过4G，事务日志大，checkpoint会少,节省磁盘IO，但是大的事务日
志意味着数据库crash时，恢复起来较慢.
引入问题:修改该参数大小，导致ib_logfile文件的大小和之前存在的文件大小不匹配
解决方式：在干净关闭数据库情况下，删除ib_logfile，而后重启数据库，会自行创建该文件;
innodb_log_files_in_group:DB中设置几组事务日志，默认是2；
innodb_log_group_home_dir:事务日志存放目录，不设置，ib_logfile0...存在在数据文件目录下
innodb_flush_log_at_trx_commit：控制事务日志何时写盘和刷盘，安全递增：0,2,1
事务缓存区:log_buffer;
0:每秒一次事务缓存区刷新到文件系统，同时文件系统到磁盘同步，但是事务提交时，不会触发log_buffer到文件系统同步；
2:每次事务提交时,会把事务缓存区日志刷新到文件系统中去，且每秒文件系统到磁盘同步;
1:每次事务提交时刷新到磁盘，最安全;
适用环境:
0:磁盘IO能力有限,安全方便较差,无复制或复制延迟可以接受，如日志性业务，mysql损坏丢失1s事务数据;
2:数据安全性有要求，可以丢失一点事务日志，复制延迟也可以接受，OS损坏时才可能丢失数据;
1:数据安全性要求非常高，且磁盘IO能力足够支持业务，如充值消费，敏感业务;
mysql的innodb中事务日志ib_logfile
标签：
热心网友
时间：2022-04-07 22:27
- 恢复策略
前面说到未提交的事务和回滚了的事务也会记录Redo Log，因此在进行恢复时,这些事务要进行特殊的的处理.有2中不同的恢复策略：
A. 进行恢复时，只重做已经提交了的事务。
B. 进行恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些未提交的事务。
- InnoDB存储引擎的恢复机制
MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点：
A. 在重做Redo Log时，并不关心事务性。 恢复时，没有BEGIN，也没有COMMIT,ROLLBACK的行为。也不关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log，这些内容只是被当作要操作的数据的一部分。
B. 使用B策略就必须要将Undo Log持久化，而且必须要在写Redo Log之前将对应的Undo Log写入磁盘。Undo和Redo Log的这种关联，使得持久化变得复杂起来。为了降低复杂度，InnoDB将Undo Log看作数据，因此记录Undo Log的操作也会记录到redo log中。这样undo log就可以像数据一样缓存起来，而不用再redo log之前写入磁盘了。
包含Undo Log操作的Redo Log，看起来是这样的：
记录1: <trx1, Undo log insert <undo_insert …>>
记录2: <trx1, insert …>
记录3: <trx2, Undo log insert <undo_update …>>
记录4: <trx2, update …>
记录5: <trx3, Undo log insert <undo_delete …>>
记录6: <trx3, delete …>
C. 到这里，还有一个问题没有弄清楚。既然Redo没有事务性，那岂不是会重新执行被回滚了的事务？确实是这样。同时Innodb也会将事务回滚时的操作也记录到redo log中。回滚操作本质上也是对数据进行修改，因此回滚时对数据的操作也会记录到Redo Log中。
一个回滚了的事务的Redo Log，看起来是这样的：
记录1: <trx1, Undo log insert <undo_insert …>>
记录2: <trx1, insert A…>
记录3: <trx1, Undo log insert <undo_update …>>
记录4: <trx1, update B…>
记录5: <trx1, Undo log insert <undo_delete …>>
记录6: <trx1, delete C…>
记录7: <trx1, insert C>
记录8: <trx1, update B to old value>
记录9: <trx1, delete A>
一个被回滚了的事务在恢复时的操作就是先redo再undo，因此不会破坏数据的一致性.
- InnoDB存储引擎中相关的函数
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()
热心网友
时间：2022-04-07 23:45
既然只有前5、6天的备份，那还原的话也只能还原到前5、6天的情况了。
个人认为：重要的数据备份的频率最好调高一点，以免出现问题时造成不必须的损失。
热心网友
时间：2022-04-08 01:20
热心网友
时间：2022-04-08 03:11
