删库跑路后真的没有办法弥补了吗？

redo 是引擎层的日志，而且是InnoDB特有的。InnoDB的 redo log 是有固定大小的，比如可以配置为 一组4个文件（logfile-1，logfile-2，logfile-3，logfile-4），每个文件的大小是1GB，那么它总共可以记录4GB的操作。一个环状循环结构，从头开始写，写到末尾又回到开始循环写。

redo中的环状结构

结构图：

是当前记录的位置，一边写一边后移，环状结构，写到3号文件末尾就会回到0号文件开头。checkpoint是当前擦除的位置，也是往后推移并且循环的。注意擦除记录前要把记录更新到数据文件（这里可以联想 粉板 老板正式记账本的例子）

redo日志作用(回答提出问题1)

1. 在 MySQL 中，如果每一次的更新操作都写进磁盘，然后磁盘也找到对应的那条记录，然后再更新，整个过程io成本，查找成本都很高，为了解决这个问题，提升效率，就会用到redo日志，MySQL经常说的的WAL技术， WAL 的全称是 write-Ahead-Logging ，它的关键点就是 先写日志，再写磁盘 。具体说，当有一条记录需要更新的时候，InoDB引擎会先记录到redo log，并更新内存，这时候更新就算完成了。同时InnoDb引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。
2. 正是因为有了redo log ,InnoDB就可以保证即使数据库发生异常重启，之前提交的记录多不会消失，这个能力叫 crash-safe 。只要数据库的物理记录还在redo log中，就是服务器数据库出现问题重启，数据库恢复后，数据记录仍然可以恢复。

binlog日志(归档日志)

Mysql基础架构整体分为两部分：Server层和引擎层，引擎层主要负责存储相关的事宜。上面说到在引擎层有自己的日志，而且只在InnoDB引擎中才有。Server层也有自己的日志，称为binlog(归档日志)。它是采用追写入日志的方式。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

binlog日志作用(回答提出问题2)

只依靠redo日志的crash-safe特性在应对数据库误删，表数据误删等操作时候，有些时候redo日志是无力的，但是binlog日志解决这些问题，因为binlog会记录所有的逻辑操作，并且采用“ 追加写 ”的形式。

举个例子如果公司员工发现某天下午有一个误删表数据操作，要求找回数据，应该怎么做？（注：这里要考虑是在刚备份之后误删除，还是备份之前误删除，下面的例子是在备份之前删除的，找之前删除的数据）

1. 首先，找到最近的一次全量备份，这要看你们公司的数据库是多久备份一次（有的公司是一天，有的公司是一周，而且会定期删除，很多公司只保留最近一个月的数据库备份），拿到备份数据后，把这个备份数据恢复到临时表
2. 然后从备份的时间点开始，将备份的binlog依次取出来，重放到误删表之前的那个时刻
3. 这时候临时库跟误删之前的线上库一样了，然后把表数据从临时数据取出来，按需恢复到线上库去。

redo日志与binlog日志对比

redo日志与binlog日志有哪些不同？ 其实上面好多都提到过，再次总结一遍，加深印象。

环状结构

更新语句执行流程(与日志关系)

数据库语句：

mysql> update Student set c=c+1 where ID=2;

复制代码

通过分析这一条更新语句，画出流程图， 问题3 也就得到解决。

注意流程图的最后三步，这是更新语句和日志关系密切的地方，将redo日志拆成了两个步骤:prepare和commit，它俩的中间是执行器写入binlog。（注:如果不这么做，假如一个日志提交成功的时候，另一个日志提交之前发生了数据库发生了崩溃，但是crash-safe恢复或者误删库恢复的时候可能造成二者数据不统一出现问题。）

开发过程中如何为mysql设置这两种保存日志的配置

• redo log

  innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。

• binlog

  sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 误删除操作（删除表数据，删除库数据） 通过binlog 仍可恢复。