Skip to content

Latest commit

 

History

History
98 lines (62 loc) · 8.06 KB

logSystem.md

File metadata and controls

98 lines (62 loc) · 8.06 KB
Raw

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

提出问题？

  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日志的写入是顺序写入的，不用去“找位置”，而直接更新数据到磁盘的话，需要到磁盘中找到位置再写入，肯定前者的效率高。

总结与宣传

以上内容是关于数据库日志系统的讲解，同时解决了我开篇提出的几个数据库日志相关的问题，希望能帮助大家更好的了解学习数据库，如果有问题可以随时关注公众号联系，互相学习哦。