mysql关于ib_logfile事务日志和binary log二进制日志的区别

总结

1、ib_logfile类似oracle的online redo log，包含commit和uncommit的数据

2、binary log类似oracle的online redo log和arcHive redo log,但是只有commit的数据

statement 格式的 binlog，最后会有 COMMIT；
row 格式的 binlog，最后会有一个 XID event

3、为什么Mysql有binlog，还要redo log？因为mysql是多存储引擎的，不管使用那种存储引擎，都会有binlog，而不一定有redo log。而redo log 事务日志ib_logfile文件是InnoDB存储引擎产生的

4、ib_logfile是循环使用，binary log不是循环使用，在写满或者重启之后，会生成新的binary log文件

5、两种日志记录的内容差不多类似，都是事务对应DML、DDL的信息，只是作用不同，内容可能重复，比如一个DML记录在了ib_logfile也记录在了binary log

6、ib_logfile作为异常宕机后启动时恢复使用

7、binary log作为数据恢复使用，主从复制搭建使用

8、两种日志写入磁盘的触发点不同，二进制日志只在事务提交完成后进行一次写入，重做日志在事务提交会写入每隔1秒也会写入。Mysql为了保证master和slave的数据一致性，就必须保证binlog和InnoDB redo日志的一致性（因为备库通过二进制日志重放主库提交的事务，如果主库commit之前就写入binlog，一旦主库crash，再次启动时会回滚事务。但此时从库已经执行，则会造成主备数据不一致）。所以必须保证二进制日志只在事务提交完成后进行一次写入

9、在主从复制结构中，要保证事务的持久性和一致性，对两种日志的相关变量设置为如下最为妥当：sync_binlog=1(即每提交一次事务同步写到磁盘中)；innodb_flush_log_at_trx_commit=1(即每提交一次事务都写到磁盘中)。这两项变量的设置保证了：每次提交事务都写入二进制日志和事务日志，并在提交时将它们刷新到磁盘中

10、innodb中，表数据刷盘的规则只有一个：checkpoint。但是触发checkpoint的情况却有几种（1.重用redo log文件；2.脏页达到一定比例）

11、ib_logfile作为redo log记录的是“做了什么改动”，是物理日志，记录的是"在某个数据页上做了什么修改"；

       binary log记录的是这个语句的原始逻辑，分两种模式，statement格式记录的是sql语句，row格式记录的是行的内容，记录更新前和更新后的两条数据。

使用下面的方法查看ib_logfile里的内容

[root@mydb ~]# strings /var/lib/mysql/ib_logfile0

使用下面两种方法查看binary log的内容

mysqlbinlog mysql-bin.000002

mysql> show binlog events in 'mysql-bin.000002';

mysql> show binlog events in 'mysql-bin.00002' from 504769752 limit 30,30;
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
选项解析：
IN 'log_name'   指定要查询的binlog文件名(不指定就是第一个binlog文件)
FROM pos        指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
LIMIT [offset,] 偏移量(不指定就是0)
row_count       查询总条数(不指定就是所有行)

ib_logfile

官方文档https://dev.mysql.com/doc/refman/5.7/en/glossary.html

A set of files, typically named ib_logfile0 and ib_logfile1, that fORM the redo log. Also sometimes referred to as the log group. These files record statements that attempt to change data in InnoDB tables. These statements are replayed automatically to correct data written by incomplete transactions, on startup following a crash.

This data cannot be used for manual recovery; for that type of operation, use the binary log.

一组文件，通常名为ib_logfile0和ib_logfile1，构成重做日志。 有时也称为日志组。 这些文件记录了尝试更改InnoDB表中数据的语句。 在崩溃后启动时，会自动重播这些语句以更正由不完整事务写入的数据。

此数据不能用于手动恢复; 对于该类型的操作，请使用二进制日志。

binary log

官方文档Https://dev.mysql.com/doc/refman/5.7/en/binary-log.html

The binary log contains “events” that describe database changes such as table creation operations or changes to table data. It also contains events for statements that potentially could have made changes (for example, a DELETE which matched no rows), unless row-based logging is used. The binary log also contains information about how long each statement took that updated data. The binary log has two important purposes:

For replication

Certain data recovery operations require use of the binary log.After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup.

二进制日志包含描述数据库更改的“事件”，例如表创建操作或对表数据的更改。 它还包含可能已进行更改的语句的事件（例如，不匹配任何行的DELETE），除非使用基于行的日志记录。 二进制日志还包含有关每个语句获取更新数据的时间长度的信息。 

二进制日志有两个重要目的：

用于复制

某些数据恢复操作需要使用二进制日志。备份恢复后，将重新执行备份后记录的二进制日志中的事件。 这些事件使数据库从备份点更新。

The binary log is not used for statements such as SELECT or SHOW that do not modify data.

二进制日志不用于不修改数据的SELECT或SHOW等语句

checkpoint

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_checkpoint

As changes are made to data pages that are cached in the buffer pool, those changes are written to the data files sometime later, a process known as flushing. The checkpoint is a record of the latest changes (represented by an LSN value) that have been successfully written to the data files.

当对缓冲池中缓存的数据页进行更改时，这些更改将在稍后的某个时间写入数据文件，这一过程称为刷新。 检查点是已成功写入数据文件的最新更改（由LSN值表示）的记录。

sharp checkpoint

The process of flushing to disk all dirty buffer pool pages whose redo entries are contained in certain portion of the redo log. Occurs before InnoDB reuses a portion of a log file ; the log files are used in a circular fashion. Typically occurs with write-intensive workloads.

将重做条目包含在重做日志的某些部分中的所有脏缓冲池页面刷新到磁盘的过程。 在InnoDB覆盖重用日志文件之前发生 ; 日志文件以循环方式使用。 通常发生写入密集型工作负载。

flush

To write changes to the database files , that had been buffered in a memory area or a temporary disk storage area. The InnoDB storage structures that are periodically flushed include the redo log, the undo log, and the buffer pool.

Flushing can happen because a memory area becomes full and the system needs to free some space , because a commit operation means the changes from a transaction can be finalized, or because a slow shutdown operation means that all outstanding work should be finalized. When it is not critical to flush all the buffered data at once, InnoDB can use a technique called fuzzy checkpointing to flush small batches of pages to spread out the I/O overhead.

将发生在内存区域或临时磁盘存储区域中缓冲的 更改写入数据库文件 。 定期刷新的InnoDB存储结构包括重做日志，撤消日志和缓冲池。

刷新可能是因为 内存区域已满并且系统需要释放一些空间 ，因为提交操作意味着可以最终确定事务的更改，或者因为慢速关闭操作意味着应该最终完成所有未完成的工作。 当一次刷新所有缓冲数据并不重要时，InnoDB可以使用一种称为 模糊检查点 的技术来刷新小批量页面以分散I / O开销。