mysql 系列(2) -日志
运行必要的 binlog, redo log, undo log
mysql(WAL)日志优先策略，日志刷盘，数据就不会丢失
更新流程：
文章图片
binlog(归档日志)
【mysql 系列(2) -日志】server层产生的逻辑日志，用来数据复制或闪回
undo log(回滚日志)
采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment。
InnoDB产生的逻辑日志，保证事务的隔离性，原子性
对数据(缓存)的任何更新 都先写undo log
提供回滚和多个行版本控制(MVCC)
redo log(重做日志)
InnoDB产生的物理日志，记录数据页的变化，保证事务的持久性
日志优先于数据，记录redo log 视为数据已更新
存储再4个1G的文件中，循环写入
文章图片
刷盘策略（双1设置保证数据安全）
innodb_flush_log_at_trx_commit 参数
0：异步每秒刷盘
1：每一个事务刷盘
N：每个事务刷盘
sync_binlog 参数
0：自动控制刷盘
1：每一个事务刷盘
N：每个事务刷盘
为什么redo log 一定在binlog 之前(两阶段提交prepare-->commit)
redo log刷盘前：系统崩溃，数据丢失
redo log刷盘后：系统崩溃， 重启后对redo log重放，重写数据页， 重写binlog
若先写binlog 数据会被传送到备库，而此刻redo log 未写 造成数据不一致
由于 redo log 和 binlog 是两个独立的逻辑, 两阶段提交是为了让两份日志之间的逻辑一致。
推荐阅读
- 【欢喜是你·三宅系列①】⑶
- 你不可不知的真相系列之科学
- 人脸识别|【人脸识别系列】| 实现自动化妆
- 2018-06-13金句系列7（金句结构-改编古现代诗词）
- Unity和Android通信系列文章2——扩展UnityPlayerActivity
- py连接mysql
- 2019-01-18Mysql中主机名的问题
- MySql数据库备份与恢复
- 乡野村趣系列之烧仙草
- Java内存泄漏分析系列之二（jstack生成的Thread|Java内存泄漏分析系列之二：jstack生成的Thread Dump日志结构解析）