MYSQL日志 redo_log更新流程 bin_log以及bin_log数据恢复

Redo_log写入策略

Redo log的Innodb_flush_log_at_trx_commit::

这个参数有三个取值

取值为0：每次事务提交时，只是把redo_log留在 redo log buffer中，宕机会丢失数据；

取值为1（默认值）：每次事务提交时都会将redo_lo直接持久化到磁盘中，数据最安全，不会因为数据库宕机而丢失数据，线上系统推荐这个设置；

设置为2：每次事务提交时把 redo log写入到操作系统的缓存page cache里面，这种情况如果数据库宕机了，数据是可以进行恢复的，但是如果操作系统宕机，如果此时 page cache里的数据还没来德基写入磁盘文件中的话，机会丢失数据。

Redo log更新的大概流程，

先更新redo log buffer,然后判断级别是否为0，为零直接提交事务，不为零，先写入 os(操作系统)的page cache缓存中，然后判读是否为2，为2则直接提交事务，为1则再调用fxync持久化到磁盘中后，再进行提交事务；

Innodb有一个后台线程，每隔一秒就会把redolog buffer中的日志，调用系统操作函数write写道文件系统的page info 中，然后调用操作系统函数fxync持久化到磁盘中；

Page cache

相当于系统缓存和磁盘文件之间的中转站，因为内存的修改速度是很快的，但是磁盘修改就相对慢一点，这个也可以看成一个缓冲区；

同样，cpu和内存之间，cpu的修改速度远大于内存，cpu中也同样有一个缓冲区；

Innodb_flush_log_at_trx_commit参数的修改

Bin_log日志

Bin_log二进制日志记录保存了所有执行过的修改操作语句，不记录保存操作，如果MySQL服务意外停止，或者数据库更新出现生产问题，则我们可以通过日志文件来排查，用户对数据或者表结构的操作，从而来恢复数据库数据；

启动bin_log会影响性能，但是如果需要有时候能够恢复丢失数据，或者搭建了主从同步库，则必须要开启bin_log日志；

主从同步分为半同步和全同步，全同步就是指从库进行持久化完成，半同步指bin_log日志同步到从库即可；

Bin_log日志在mysql配置文件中的配置

如下，如果没有配置，则都会有默认值

Bin_log的bin_log_format可以设置日志格式

Bin_log的写入磁盘机制，和redo_log相似

Linux查看MySQL配置文件，可以

1.Which mysql 得到一个路径a

2.进入路径a，输入命令mysql --verbose --help |grep -A 1 ‘Default options’

3.然后就能得到几个my.cnf配置地址，配置生效优先级别，就是从前到后优先级递减

bin_log日志文件位置与格式

配置完成后，重启数据库，会在配置好的目录文件中得到两种类型文件

 Show variables like ‘%log_bin%’查看数据库的binlog配置

Sql_log_bin默认是开启的，只是有些时候，可能需要测试，主从同步异常的情况，可以修改为OFF；

MySQL提供的查看bin_log日志文件工具：

不用登陆数据库，这个mysql插件，后边为日志地址；

Bin_log如何做数据恢复

首先先理解一个概念，偏移量，就是记录在日志文件中的位置，

回放：根据日志文件中之前执行的语句，再执行一次

所以，当我们有了bin_log日志文件，而且找到了我们之前执行的记录，就可以通过回放之前的操作来恢复数据，

通过执行

Mysqlbinlog --no-defaults --starts-position=需要执行语句的开始偏移量 --stop-position=需要执行语句的结束偏移量 --database=数据库名 binlog文件位置+binlog文件名 | mysql -u用户名 -p密码 -v数据库名

执行输出日志不报错，就算执行完成

当然也可以根据时间戳来进行恢复，

Mysqlbinlog --no-defaults --starts-datetime=需要执行语句的开始时间 --stop-datetime=需要执行语句的结束时间 --database=数据库名 binlog文件位置+binlog文件名 | mysql -u用户名 -p密码 -v数据库名

生产情况bin_log使用

生产情况下，对数据的数据保护，一般是通过dump备份和bin_log来保证数据不丢失