<强> 总结
1,ib_logfile类似甲骨文的联机重做日志,包含提交和uncommit的数据
2、二进制日志类似甲骨文的联机重做日志和归档重做日志,但是只有提交的数据
格的声明式的binlog,最后会有提交;
行格式的binlog,最后会有一个XID事件
3,为什么MySQL有binlog,还要重做日志?因为MySQL是多存储引擎的,不管使用那种存储引擎,都会有binlog,而不一定有重做日志。而重做日志事务日志ib_logfile文件是InnoDB存储引擎产生的
4,ib_logfile是循环使用,二进制日志不是循环使用,在写满或者重启之后,会生成新的二进制日志文件
5,两种日志记录的内容差不多类似,都是事务对应DML、DDL的信息,只是作用不同,内容可能重复,比如一个DML记录在了ib_logfile也记录在了二进制日志
6,ib_logfile作为异常宕机后启动时恢复使用
7、二进制日志作为数据恢复使用,主从复制搭建使用
8,两种日志写入磁盘的触发点不同,二进制日志只在事务提交完成后进行一次写入,重做日志在事务提交会写入每隔1秒也会写入.MySQL为了保证主人和奴隶的数据一致性,就必须保证binlog和InnoDB重做日志的一致性(因为备库通过二进制日志重放主库提交的事务,如果主库提交之前就写入binlog,一旦主库崩溃,再次启动时会回滚事务。但此时从库已经执行,则会造成主备数据不一致)。所以必须保证二进制日志只在事务提交完成后进行一次写入
9日,在主从复制结构中,要保证事务的持久性和一致性,对两种日志的相关变量设置为如下最为妥当:sync_binlog=1(即每提交一次事务同步写到磁盘中);innodb_flush_log_at_trx_commit=1(即每提交一次事务都写到磁盘中)。这两项变量的设置保证了:每次提交事务都写入二进制日志和事务日志,并在提交时将它们刷新到磁盘中
10日,innodb中,表数据刷盘的规则只有一个:检查站。但是触发检查点的情况却有几种(1。重用重做日志文件;2。脏页达到一定比例)
11日,ib_logfile作为重做日志记录的是“做了什么改动”,是物理日志,记录的是“在某个数据页上做了什么修改“;
,,,,二进制日志记录的是这个语句的原始逻辑,分两种模式,声明格式记录的是sql语句,行格式记录的是行的内容,记录更新前和更新后的两条数据。
使用下面的方法查看ib_logfile里的内容
root@mydb ~ #/var/lib/mysql/ib_logfile0字符串
使用下面两种方法查看二进制日志的内容
mysqlbinlog mysql-bin.000002
mysql>显示binlog事件& # 39;mysql-bin.000002& # 39;;
mysql>显示binlog事件& # 39;mysql-bin.00002& # 39;从504769752限制30、30;
mysql>显示binlog事件(& # 39;log_name& # 39;][从pos][限制[抵消,]row_count];
选项解析:
在& # 39;log_name& # 39;,,指定要查询的binlog文件名(不指定就是第一个binlog文件)
从pos ,,,,,,指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
限制(偏移量,)偏移量(不指定就是0)
row_count ,,,,,查询总条数(不指定就是所有行)
ib_logfile
官方文档https://dev.mysql.com/doc/refman/5.7/en/glossary.html
一组文件,通常叫ib_logfile0 ib_logfile1,形成了重做日志。有时也称为日志组。这些文件记录语句,试图改变InnoDB表中的数据。这些语句自动重播到正确的数据写的不完整的交易,在启动时崩溃。
这些数据不能用于手动恢复;对于这种类型的操作,使用二进制日志。
一组文件,通常名为ib_logfile0和ib_logfile1,构成重做日志。有时也称为日志组。这些文件记录了尝试更改InnoDB表中数据的语句。在崩溃后启动时,会自动重播这些语句以更正由不完整事务写入的数据。
此数据不能用于手动恢复;对于该类型的操作,请使用二进制日志。
