日志的重要性
- 日志绝对是数据库的核心. 持久化的日志记录了各种重要的信息.
- 数据的恢复需要依赖日志。 慢查询sql语句需要用到慢查询日志。以及错误日志中保存着mysqld数据库服务端在启动过程中发生的重大错误信息...
数据库重要组成
本质上来说是一个文件系统 (两大重要组成部分如下)
- 数据库，数据表对应文件 （.frm 表结构文件） (.ibd 索引数据文件)
- 日志文件. logfile
日志的分类
- 错误日志
错误日志是 MySQL 中最重要的日志之一，它记录了当 mysqld 启动和停止时，以及服务器在运行过程 中发生任何严重错误时的相关信息.当数据库出现任何故障导致无法正常使用时，可以首先查看此日志。
- 查询日志
普通查询日志和慢查询日志. 最主要的还是慢查询日志
设置慢查询时间, 开启慢查询日志, 然后可以通过慢查询日志来分析执行计划来知晓耗时的sql查询操作, 进而进行添加索引优化.
那么此时我们可以把表分成n个小表，比如订单表按年份分成多个小表等。
慢查询日志的临界时间, 单位s秒
- 二进制日志
二进制日志(BINLOG)记录了所有的 DDL(数据定义语言)语句和 DML(数据操纵语言) 语句，但是不包括 数据查询语句。语句以“事件”的形式保存，它描述了数据的更改过程。 此日志对于灾难时的数据恢复起 着极其重要的作用。
对于二进制日志, 我们做不到直接的查看, 直接查看看到的也只是一堆乱码, 所以对于二进制日志想要明文的查看, 我们需要借助一定的工具. --- mysqlbinlog工具
- 很明显我并没有开启二进制日志, 所以我需要在my.cnf配置文件中配置一下, 开启二进制日志相关配置, 同时重启mysqld
不晓得大家开启二进制日志的过程如何，我开启的过程可谓是颇为曲折.
- 权限问题. 要确认你有足够的权限访问my.cnf配置文件 chmod 644 /etc/my.cnf
- 我没有修改权限之前出现了如此的错误, 导致我配置文件加上的log-bin没有发挥作用
mysql: [Warning] World-writable config file '/etc/my.cnf' is ignored.说白了就是/etc/my.cnf文件所写的配置被忽略了
没有上述这个警告之后， 我再次进入my.cnf配置文件添加上如下三行配置就OK了
sudo vim my.cnf
log-bin=mysql-bin #设置二进制日志路径(系统默认设置)
server-id=1 #选取服务器
expire_logs_days=7 #每过七天清理一次日志
写完之后 systemctl restart mysqld.service; #重启mysqld服务
再次show variables like '%log_bin%'; 完美, 它终于开启了.
查看二进制日志: show binary logs; || show master logs;
分析二进制文件的工具, 我们直接看二进制日志看到的就是一堆乱码, 所以我们需要借助通过mysqlbinlog工具（mysql原生自带的工具）可以快速解析大量的binlog日志文件
语法格式如下:
mysqlbinlog --no-defaults --database=db_name --base64-output=decode-rows
-v --start-datetime='start time' --stop-datetime='end time'
mysql-bin.000001 | more--database=数据库名称, 指定数据库.
base64-output: 指定解码方式, 为base64译码形式
start-datetime and stop-datetime: 指定查看二进制日志的时间段, 不指定默认查看全部时间段更改.
mysql-bin.000001 指定解析查看的二进制日志
可以看到如上这样一条插入语句
- @1 @2 @3指的是三个字段
- server id: 表示我们在my.cnf中配置的id, 标识
- at 400 指的是事务在binlog中记录的位置
二进制日志的两个重要的应用场景：主从复制、数据恢复
对于日志的开启, 我们需要在my.cnf数据库配置文件中书写日志文件相应的配置. 然后进行mysqld的restart重启操作即可
systemctl restart mysqld.service;
- undo log 和 redo log
redo log 和 undo log日志
数据落盘
- 定义: 将内存缓冲区中的数据刷新到磁盘上的操作叫做数据落盘, 数据落盘才是真正的持久化. 才是持久化的核心关键
- 磁盘上的数据才是掉电之后还在的. 内存上的数据都是临时的.
- 缓冲区的概念：缓冲区完全就是减少和磁盘交互的次数. 提高效率. 平衡CPU和磁盘硬件交互的速度差异性。
redo log：重做日志, 用于记录事务操作的变化， 确保事务的持久性. redo log事务开始就开始记录。不论是否提交都会记录下来, 在提交的时候将一次完整的事务刷新到磁盘上. 当数据库出现异常的时候 (掉电等等) 就会根据redo log物理日志恢复到掉电前的时刻, 保证数据的完整性.
redo log buffer 持久化到磁盘上的时机：commit时刻 或者 定时数据落盘
数据落盘是异步落盘的》 并非是同步实时刷新落盘的, 而是一种另外开启新的线程专门用于异步数据落盘的. -----》 另外开启的线程作用: 要么通过轮询，或者定时检测什么事件进行处理. 此处就是关注数据落盘,
下图是借鉴的别人的.
undo log: 回滚日志
undo log 版本链条: 功能： 1.事务回滚操作 2. MVCC的RC和RR隔离级别下面的readview快照读 （RC: 每一条select语句都产生新的快照数据readview. readview快照数据可根据最新版本更新。 RR: 一个事务创建一个readview, 并且是按照第一次select*的数据产生的. 故而重复度不变, 每次都是最开始的readview快照.）
事务回滚场景:
1. 事务执行过程中出现了error错误，进行回滚操作
2. 掉电后的数据恢复, 先redo log恢复, 再undo log 回滚
数据更新操作到持久化的过程.
怎么说： 脏数据在写入脏数据缓冲区之前首先需要先完成redo log undo log日志相关的缓存操作.
然后redo log在合适（commit 或者1s）的时机完成数据落盘.
- 明确第一点: 持久化核心是redo log，重做日志的事情. undo log的持久化也只是基于redo log实现的. 将undo log的跟新信息写入到redo log中.
所以: 持久化保存最重要的是redo log日志, undo log的持久化也是基于redo log的.
自然写日志肯定就是先写redo log日志缓存, 然后就是写的sql究竟是什么, 与什么是强相关的?
肯定是先写old 老数据恢复相关的, 再写新数据恢复相关的. 所以写redo log缓存的时候先写undo log相关的. 再写sql操作新数据恢复相关的 redo log
日志记录是从什么时候开始的?
事务开启即开始记录相应的日志记录到内存缓冲区.
undo log 进行数据落盘了吗? undo log数据落盘的时机是什么?
MySQL中的Undo Log严格的讲不是Log，而是数据，因此他的管理和落盘都跟数据是一样的
上述回答我是借鉴的知乎上的一则回答. 所以既然跟数据落盘管理机制一样，自然落盘也就是
undo log和脏页按照checkpoint进行落盘。
说白了undo log先于数据落盘的办法采取的是记录相应的redo log用于undo log先于数据的落盘保证. 也是对于undo log和数据掉电未持久化到磁盘上恢复的保证.
Mysql的undo log的落盘机制是什么样的？ - 知乎
掉电了, 宕机了，如何实现掉电前的脏数据页的恢复?
- 重启
- 使用redo log恢复数据（恢复脏页数据）
- 使用undo log进行事务回滚 (回滚还未commit但是通过redo log操作恢复的数据)
事务执行COMMIT操作时，会将本事务相关的所有redo log都进行落盘，只 有所有redo log落盘成功，才算COMMIT成功. 否则需要进行rollback操作. 也就是使用undo log事务回滚。
小总结:
- 事务进行过程中，每次DML sql语句执行，都会记录undo log和redo log，然后更新数据形成脏数据页
- 先写日志缓存, 再写数据缓存
- 先写undo log旧数据恢复相关的redo log, 再写新数据恢复相关的redo log
- 先写好内存上的缓冲区缓存. 真正的数据落盘, 都是另外开启线程在一定的时机将数据落盘到磁盘上. 脏数据的落盘并不那么紧要, 只要redo log日志实现了落盘. 就完成了真正的持久化, 哪怕脏数据页还没有数据落盘掉点了. 下一次启动还可以根据redo log恢复数据, 以及undo log回滚回到掉电之前的结果