https://juejin.cn/post/6860252224930070536
https://blog.csdn.net/weixin_34236572/article/details/112366986
逻辑日志：存储sql语句
物理日志：存储的是数据页内容（mysql数据最终存储的地方），
其记录就是数据页变更
binlog ：二进制日志 在server层 该二进制日志存储的就是相应的sql语句（默认）
使用场景：主从复制 数据恢复
binlog在server层，只有在事务提交的时候才会进行记录，如何进行刷盘？？
通过sync_binlog控制：
0：不强制系统自主选择
1：每次commit都刷盘 （mysql5.7默认）
N：n次commit 进行刷盘
binlog日志格式：
1.statement ： 按照sql语句的方式记录，不需要记录每一行变化提高性能
2.row：基于行的复制
redolog：保证了事务的四大特性中的持久性（记：底层所以保证。引擎层）
mysql中的write ahead loging技术：先写日志再写磁盘
redolog就是先写缓冲再写磁盘
用户空间
内核
磁盘
redolog三种写方式
1.先写用户空间缓存，然后异步（拷贝内核同步磁盘）
2.写用户同步靠内，异步写磁盘
3.同步写用户拷贝内核写磁盘（性能差）
二者的区别：
大小：redolog 是 innodb自有，大小固定，binlog可以一直产生
实现：redo是innodb所以支持事务，bin是server所以不是事务
记录方式：redo是循环记录，圈的方式，会覆盖之前的。binlog末尾追加，回生成新文件不追加
使用场景：**crash-safe（突然宕机快速恢复）：：：必须是redo；bin是主从复制，数据恢复
二者相辅相成：
binlog只是归档使用，没有crash-safe能力
所以要有redolog但是不能只有redo他是innodb特有的；
但是redolog数据会被覆盖，要换引擎，数据大量恢复还是要binlog（server的）
undolog 使用mvcc ： 版本连：保证数据的原子性，对数据库的操作，要么全部成功要么全部失败
整个复制过程无论Log的传输过程，还是回放过程，都是单线程的。而并行复制，就是把回放环节并行化了
Binlog本身是全局有序的，如果用多线程传输，还要重新排序和重组，可能得不偿失。
所谓并行回放，就是一次性从RelayLog中拿出多个事务，并行地执行；
1.不同库的事务可以并行，不同表的事务可以并行，不同行的事务可以并行。
2.commid如果在一个事务还没有结束之前，另外一个事务也开始进入提交阶段，说明这两个事务是在并行的，它们操作的是肯定是不同的数据记录。所以可以并行
