三、mysql重要日志模块

目录

3.1. redo log

redo log实现分析

Undo Log

3.2. bin log

出现两份日志的原因？

两种日志的不同点

binlog格式

Statement

Row

Mixed

查看与配置binlog格式

与binlog有关参数

---

什么是binlog、redo log

redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用

redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；

binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1

redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

binlog属于逻辑日志，是逻辑操作；

innodb redo属于物理日志，是物理变更。

逻辑日志有个缺点是难以并行，而物理日志可以比较好的并行操作。

1. binlog是MySQL Server层记录的日志， redo log是InnoDB存储引擎层的日志。 两者都是记录了某些操作的日志(不是所有)自然有些重复（但两者记录的格式不同）。

 2. 选择binlog日志作为replication 

3.1. redo log

在mysql中，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。为了解决这个问题，mysql的设计者就用了类似酒店掌柜粉板的思路来提升更新效率。

mysql中经常说到的WAL技术，WAL的全称是Write-Ahead Logging ，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。

具体来说，当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log里面，并更新内存，这个时候更新就算完成 了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。

• 记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是RedoLog已经持久化。系统可以根据RedoLog的内容，将所有数据恢复到最新的状态。
• InnoDB有buffer pool（简称bp）。bp是数据库页面的缓存，对InnoDB的任何修改操作都会首先在bp的page上进行，然后这样的页面将被标记为dirty并被放到专门的flush list上，后续将由master thread或专门的刷脏线程阶段性的将这些页面写入磁盘（disk or ssd）。这样的好处是避免每次写操作都操作磁盘导致大量的随机IO，阶段性的刷脏可以将多次对页面的修改merge成一次IO操作，同时异步写入也降低了访问的时延。然而，如果在dirty page还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是redo log file。这样的技术推迟了bp页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写redo log操作的开销（顺序IO，当然很快），以及数据库启动时恢复操作所需的时间。

redo log实现分析

InnoDB的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB，那么这块“粉板”总共就可以记录4GB的操作。从头开始写，写到末尾就又回到开头循环写，如下图：

 

Undo Log

undo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用UndoLog来实现多版本并发控制(简称：MVCC)。

-事务的原子性(Atomicity)

事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。

3.2. bin log

即二进制日志,它记录了数据库上的所有改变，并以二进制的形式保存在磁盘中；它可以用来查看数据库的变更历史、数据库增量备份和恢复、Mysql的复制（主从数据库的复制）。语句以“事件”的形式保存，它描述数据更改。

因为有了数据更新的binlog，所以可以用于实时备份，与master/slave复制。高可用与数据恢复。

1.恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。

2.在主复制服务器上记录所有将发送给从服务器的语句。

出现两份日志的原因？

最开始mysql里并没有innoDB引擎。mysql自带的引擎是myisam，但是myisam没有crash-safe的能力，binlog日志只能用于归档。而Innodb是另外一个公司以插件形式引入mysql的，既然只依靠binlog是没有crash-safe能力的，所以innodb使用另外一套日志也就是redo log来实现crash-safe能力。

 

两种日志的不同点

---

binlog格式

binlog有三种格式：Statement、Row以及Mixed。从安全性来看，ROW（最安全）、MIXED（不推荐）、STATEMENT（不推荐）。

–基于SQL语句的复制(statement-based replication,SBR)，

–基于行的复制(row-based replication,RBR)，

–混合模式复制(mixed-based replication,MBR)。

 

Statement

每一条会修改数据的sql都会记录在binlog中。在5.6.24中默认格式。

优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。

缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题。

ps：相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。

 

Row

5.1.5版本的MySQL才开始支持row level的复制,它不记录sql语句上下文相关信息，仅保存哪条记录被修改。

优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题.

缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。

ps:新版本的MySQL中对row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。

 

Mixed

从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。

在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

 

查看与配置binlog格式

（1）查看binlog_format

show variableslike'binlog_format;

 

或者通过查看配置文件

whereismy.inicat /etc/my.cnf

（2）修改binlog_format

直接修改set globle binlog_format='MIXED'

或者修改配置文件vi /etc/my.cnf

 

 

与binlog有关参数

log_bin

设置此参数表示启用binlog功能，并指定路径名称。默认是off

log_bin_basename

log_bin_index

设置此参数是指定二进制索引文件的路径与名称

max_binlog_cache_size

此参数表示binlog使用的内存最大的尺寸

binlog_cache_size

此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。

binlog_cache_use：使用二进制日志缓存的事务数量

binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量

max_binlog_size

Binlog最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束。

innodb_flush_log_at_trx_commit = N：

N=0  – 每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上；

N=1  – 每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上；

N=2  – 每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件，但不一定刷新到磁盘上，而是取决于操作系统的调度；

 

sync_binlog =  N：这个参数直接影响mysql的性能和完整性

N>0  — 每向二进制日志文件写入N条SQL或N个事务后，将执行一次fsync之类的磁盘同步指令，同时文件系统将Binlog文件缓存刷新到磁盘；

N=0  — 默认的，性能最高，风险最大。不主动刷新二进制日志文件的数据到磁盘上，而是由操作系统决定。当事务提交后，Mysql仅仅是将binlog_cache中的数据写入Binlog文件，但不执行fsync之类的磁盘同步指令通知文件系统将缓存刷新到磁盘，而让Filesystem自行决定什么时候来做同步，这个是性能最好的。；

 

推荐配置组合：

N=1,1  — 适合数据安全性要求非常高，而且磁盘IO写能力足够支持业务，比如充值消费系统；

N=1,0  — 适合数据安全性要求高，磁盘IO写能力支持业务不富余，允许备库落后或无复制；

N=2,0或2,m(0)

N=0,0  — 磁盘IO写能力有限，无复制或允许复制延迟稍微长点能接受，例如：日志性登记业务；