mysql log system SQL logical logs physical log

The logging system update SQL statement is executed

Update process executed statement

        Update and query execution process flow of statements executed as

        

        note:

        There are operating updated on a time table, and the table associated with the query cache will be cleared

 

        Experiencing analyzer, optimizer, history and actuators storage engines, but also more importantly log module

        Redo log Redo logs

        Bin log archive log

        

        Redolog physical log

            Innodb engine is unique log module

 

Its key point is to update the time to write the log, write disk, when not busy in the task will be a lot of accumulation of update operations performed together IO written to disk

 

InnoDB 's redo log are fixed size, for example may be configured as a set . 4 files, each file is 1GB , then this " pink sheet " in total can be recorded 4GB operation. Written from scratch, it is written to the end back to the beginning of the write cycle, as shown in the following chart

write pos is the current record position, while the write side shift, wrote the first 3 numbers after the end of the file back to 0 at the beginning of document. checkpoint is to erase the current location, but also goes back and cycles, should be updated to record data files before erasing records.

 

write pos and checkpoint between the " pink sheet " on the still empty portion, it can be used to record a new operation. If you write pos catch checkpoint , represents the " pink sheet " full, this time can no longer perform a new update, we had to stop to wipe some records, the checkpoint promote it.

 

With the redo log , InnoDB can guarantee reboots even if the database occurs, the previously submitted will be lost this ability is called crash-safe

 

Binlog logical logs

 

        Layer is the service log module

        All engines can be used

        Binlog can additionally recorded is generated by the logical operation of the actuator

 

        Why are there two log module?

Since the beginning of MySQL was not InnoDB engine. MySQL 's own engine is MyISAM , but MyISAM does not crash-safe capability, binlog log can only be used for archiving. The InnoDB is another company to introduce a plug-in MySQL , since only rely on binlog is not crash-safe capability, so InnoDB to use another set of logging system - that is, redo log to achieve the crash-safe capability

 

Both logs Features comparison:

1. redo log InnoDB engine is unique ; binlog is the MySQL Server layer implementation, all engines can be used.
2. physical redo log log record is "data on a page change has been made "; the binlog logical log records the original logic of the sentence, such as "to field ID = c 2 of this line plus one" .
3. redo log is written in circulation, fixed space will run out ; binlog can append written. "Additional write" refers to the binlog file will switch to the next post is written a certain size, and does not overwrite the previous log

 

 

 

Innodb actuator and performing a data update internal processes

1. Engine actuators find someone to take the line ID = 2. ID is the primary key, tree search engine to find the direct use of the line. If ID = 2 data pages where this line already in memory, it is returned directly to the actuator; otherwise, you need to start disk into memory, and back again.

    

2. Actuator to get the engine to the line data, adds 1 to this value, such as the original is N, is now N + 1, to obtain a new line of data, then call this line engine interface to write new data.

 

1. Engine row update these new data in memory, while the update operation to redo log record which, in this case redo log prepare state. Then informed the Executive performs complete, ready to commit the transaction.

 

1. Actuators generate binlog this operation, and the binlog written to disk.

 

1. Execution engine call to commit the transaction interface engine just written to redo log into submission (commit) state, the update is complete.

 

Flowchart is executed,

FIG colored boxes represent in InnoDB performed internally,

Dark boxes represent the implementation of the actuator

Why log requires "two-phase commit?

        Key:

        In redolog the prepare and commit completed between Binlog

        Before binlog redolog ready to memory, but not written to disk

        After binlog redolog was filed in a state ready to be written to disk.

        Redolog and binlog are two separate stages, does not depend

        

        That is, the data modification is completed already in memory, modifying the operation data is also recorded over,

However, the database disk files have not really written.

 

假设当前ID=2的行，字段c的值是0，再假设执行update语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了crash

1. 先写redo log后写binlog。假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。
   但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。
   然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
2. 先写binlog后写redo log。如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了"把c从0改成1"这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。

 

注意

redo log用于保证crash-safe能力。innodb_flush_log_at_trx_commit这个参数设置成1的时候，表示每次事务的redo log都直接持久化到磁盘。这个参数建议你设置成1，这样可以保证MySQL异常重启之后数据不丢失。

 

sync_binlog这个参数设置成1的时候，表示每次事务的binlog都持久化到磁盘。这个参数建议你设置成1，这样可以保证MySQL异常重启之后binlog不丢失。