日志系统
mysql采用了wal(Write-Ahead Logging)技术.先写日志再写磁盘,保证了crash-safe
redo log(物理日志)
(InnoDB 引擎特有的日志)
redo log记录了"在某个数据页做了什么修改",记录改动
日志文件有限(可配置一定大小),所以日志模块维护两个位置(write pos 和 checkpoint),总的日志内容维护像是 循环队列(循环写入) ,write pos记录写入日志的位置,一边写一边后移,checkpoint维护要擦除的位置,擦除之前要更新到数据文件.
binlog(逻辑日志)
数据库server提供的日志
binlog 记录的是数据库语句执行的原始逻辑,binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。
binlog可以追加写,文件写到一定大小后会切换到下一个,并不会覆盖以前的日志.具有归档的功能(redo log不具备).宕机恢复并不依赖binlog
两阶段提交
mysql> update T set c=c+1 where ID=2;
- 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
- 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
- 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成
小结
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个
参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
我还跟你介绍了与 MySQL 日志系统密切相关的“两阶段提交”。两阶段提交是跨系统维
持数据逻辑一致性时常用的一个方案，即使你不做数据库内核开发，日常开发中也有可能会用到。
一天一备份和一周一备份
最坏情况就是需要一天和一周的binlog
指标(RTO)
RTO是指灾难发生后,从IT系统宕机导致业务停顿之刻开始,到IT系统恢复至可以支持各部门运作,业务恢复运营之时,此两点之间的时间段.
RTO是用成本来保证的,具体需求具体估计.
