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

提出问题？

1. 服务器数据库异常重启了会形成什么样的影响？
2. 不当心删除了数据库怎么办，或者不当心删除了数据库表中数据怎么办？
3. 一条更新语句在数据库系统内部执行时与数据库日志系统有什么联系？
4. 数据库备份，是天天一备比较好，仍是每周一备比较好？ 接下来在讲解日志系统的同时，回答上面的几个问题。

日志系统详解：

redo日志(重作日志)

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

redo中的环状结构

结构图：

write pos是当前记录的位置，一边写一边后移，环状结构，写到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日志有哪些不一样？ 其实上面好多都提到过，再次总结一遍，加深印象。

1. redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，全部的引擎均可以使用。
2. redo log是物理日志，记录的是某个数据页上作了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，好比“给ID=2这一行的c字段加一”
3. redo log是环状结构，循环写，空间固定会用完，用完后须要擦除；binlog是能够追加写入的。“追加写”是只belog文件写到必定大小后会切换到下一个，并不会覆盖之前的日志。

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

数据库语句：

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 仍可恢复。

如何查看这两种日志

关于日志系统的一些误区和疑问

• 你们会不会想有了redo日志就能够了，为何还要出现binlog日志呢？

  解答：

  1. redo日志是只要InnoDB引擎才提供的一个内容。
  2. redo日志是环状结构循环写入，而且到了配置的固定大小后会被擦除，误删除数据库或表数据的时候，备份可能会出现没法所有还原。

• 这里有一个问题：若是在擦除和记帐重合那一刻，数据库异常重启了，新的数据库操做会怎么记录，是擦除一部分，记录上，会丢失，仍是等待重启后往上添加数据？

• 关于数据库备份，是一天一备比较好，仍是一周一备份比较好，通常备份文件保留多久？提出问题4解决

  解答：对于数据库备份周期这个问题，须要考虑如下指标：数据存量、增量、备份成本、恢复效率。

  1. 若是数据存量大到一天都无法备份完成，只能一周一次甚至更长时间
  2. 业务数据的增量，若是增量很是大，若是一周备份一次，可能会出现增量备份失败问题，并且恢复时长和成功率也比较困难，则能够考虑一日一备。
  3. 业务比较重要，且对恢复时间的忍耐程度低，以前屡次发生过数据回滚的需求，数据增量还不小，能够考虑一天一备。相反业务实际不重要，出问题能够容忍必定的不可用，增量还很少，能够考虑一周一备份。

  总的来讲就是和项目，需求，场景有不少关系。

• 写入redo日志也是io操做，数据更新直接写入磁盘也是io操做，为何说写入redo日志效率高节省io成本呢？

  解答：redo日志的写入是顺序写入的，不用去“找位置”，而直接更新数据到磁盘的话，须要到磁盘中找到位置再写入，确定前者的效率高。

总结与宣传

以上内容是关于数据库日志系统的讲解，同时解决了我开篇提出的几个数据库日志相关的问题，但愿能帮助你们更好的了解学习数据库，若是有问题能够随时关注公众号联系，互相学习哦。