ySQL

的大多数核心服务功能以及所有的内置函数如日期、时间、数学和加密函数等所有跨存储引擎的功能都在这一层实现比如存储过程、触发器、视图等。

引擎层

从头开始写写完一个文件继续写另一个文件写到最后一个文件末尾就又回到第一个文件开头循环写如下面这个图所示。

write

是当前要擦除的位置也是往后推移并且循环的擦除记录前要把记录更新到数据文件里。

write

innodb_flush_log_at_trx_commit这个参数控制

redo

直接持久化到磁盘数据最安全不会因为数据库宕机丢失数据但是效率稍微差一点线上系统推荐这个设置。

redo

cache里这种情况如果数据库宕机是不会丢失数据的但是操作系统如果宕机了page

对于设置2InnoDB

log二进制日志记录保存了所有执行过的修改操作语句不保存查询操作。

如果

MySQL

服务意外停止可通过二进制日志文件排查用户操作或表结构操作从而来恢复数据库数据。

一般来说redo

log用于重启mysql时恢复数据bin

STATEMENT基于SQL语句的复制每一条会修改数据的sql都会记录到master机器的bin-log中这种方式日志量小节约IO开销提高性能但是对于一些执行过程中才能确定结果的函数比如UUID()、

SYSDATE()等函数如果随sql同步到slave机器去执行则结果跟master机器执行的不一样。

ROW基于行的复制日志中会记录成每一行数据被修改的形式然后在slave端再对相同的数据进行修改记录下每一行数据修改的细节可以解决函数、存储过程等在slave机器的复制问题但这种方式日志量较

大性能不如Statement。

举个例子假设update语句更新10行数据Statement方式就记录这条update语句Row方式会记录被修改的10行数据。

MIXED混合模式复制实际就是前两种模式的结合在Mixed模式下MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式也就是在Statement和Row之间选择一种如果sql里有函数或一些在执行时才知道结果的情况会选择Row其它情况选择Statement推荐使用这一种。

binlog写入磁盘机制

写入磁盘这种方式最安全。

还有一种折中方式可以设置为N(N1)表示每次提交事务都write

到page

D:/dev/mysql‐5.7.25‐winx64/data/mysql‐binlog.000007

查看bin‐log二进制文件带查询条件

D:/dev/mysql‐5.7.25‐winx64/data/mysql‐binlog.000007

00:00:00

stop‐position20000binlog日志文件恢复数据

首先bin

log文件将会越来越多不推荐。

但是为了防止删库跑路需要结合数据库备份来设置bin

log保留大于一天。

那么恢复数据库可以用最近的一次全量备份再加上备份时间点之后的binlog来恢复数据。

备份数据库

#恢复整个数据库test为数据库名称需要自己先建一个数据库test查看bin

log日志

TIMESTAMP1674833560/*!*/;注意到上述的两行一个代表位置标识一个代表时间戳可以根据上面两个变量来恢复某一段的数据

根据位置标识恢复

D:/dev/mysql‐5.7.25‐winx64/data/mysql‐binlog.000009

mysql

TIMESTAMP1674833663转成datetime格式

mysqlbinlog

D:/dev/mysql‐5.7.25‐winx64/data/mysql‐binlog.000009

mysql

修改类型的事务提交之后不能立即清除掉这些日志会用于mvcc。

只有当没有事务用到该版本信息时才可以清

错误日志

Mysql还有一个比较重要的日志是错误日志它记录了数据库启动和停止以及运行过程中发生任何严重错误时的相关信息。

通用查询日志记录用户的所有操作包括启动和关闭MySQL服务、所有用户的连接开始时间和截止时间、发给

MySQL

指令等如select、show等无论SQL的语法正确还是错误、也无论SQL执行成功还是失败MySQL都会将其记录下来。

通用查询日志用来还原操作时的具体场景可以帮助我们准确定位一些疑难问题比如重复支付等问题。