redo log（重做日志）

物理备份，可以理解为直接将文件拷贝，归属于引擎层

这里重做日志利用的就是WAL技术，全称为Write-Ahead Logging。也就是先记录日志，再写磁盘
这样可以提升效率在忙的时候减少与磁盘的IO进而提升效率。

redo log只存在与InnoDB引擎中

InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB
总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写，如下图所示
Mysql日志 - 图1
write_pos代表当前记录的位置，check_point代表当前擦除的位置。当write_pos = check_point时即代表
已经存满了。

有了redo log，当发生宕机时，可以通过redo log进行恢复不会造成丢失

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

bin log（归档日志）

逻辑备份，可以理解为具体的SQL语句，归属于server层

bin log是逻辑日志，是以追加的形式存储的。当一个文件存储满了之后，会增加另一个文件来存储并不会覆盖之前的内容

两阶段提交

update 语句的执行流程图，图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的
Mysql日志 - 图2
由于bin log和redo log是两个独立的逻辑，所以我们要采用这种两阶段提交。也就类似于事务的概念
从而保证数据的准确性。

我们如果要恢复近期的数据，我们首先要选取一个最近时间点的备份，然后通过bin log进行恢复

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