Speaking before the redolog and binlog, first to talk about the process of implementation of a mysql statement.
1, client write requests to the connector, the connector is responsible for managing the connection, verify the permissions;
2, then the parser is responsible for reviewing grammar, if this statement has been executed, in the cache, then to write from the cache;
3, cache does not, then it is to optimize the part. Responsible for optimizing the sql read and write, select index;
4, followed by the actuator, responsible for operating the engine, and returns the result.
Next step is to get to the point, talk about how the fourth step is executed.
redo log
The query is not the same, the update process also involves two important log module, the protagonist of which is exactly what we want to talk about today: redo log (redo logs) and bin log (archive log).
innodb update operation is not written directly to disk, but the first log, that is, redo log, and then wait until the db less busy time to brush on the disk. This ensures efficient write operations mysql. Why would such a design? Because every update operation must first query, there are disk io, modify the data found in the brush into the disk, but also a io, each time to do so will be very slow, so I have to record in memory, and then recorded in the redo-log in, and then follow the strategy brush into the disk. This technique is called WAL technology. If only because the words recorded in the memory, mysql crash may result in changes to data loss. So redo log to ensure that the innodb the crash-safe. (Note: mysql is no redo log, which is unique to innodb mysql but in most cases will now choose innnodb..) After mysql crash, recovery will read data from the redo log in.
But redo log is limited in size, such as setting up redo log 4 Ge 1G, then the third time will be filled with coverage of the 0's log files.
bin log
redo log is a log in the storage engine level, responsible for storing and crash recovery. bin log is a log server layer.
Why are there two log it?
Because only rely bin log is not crash safe capability. And there is a redo log size limit.
redo log and bin log there are several differences are as follows:
1, belongs to a different layer, bin log is the server layer, redo log is a log storage layer, only innodb only.
2, redo log is limited in size, is written in the cycle, and no such limitation binlog;
3, redo log physical log record is "on a data page change has been made", bin log is logical log, recording original logic statements, such as do add this line to count id = 3 an operation.
Then look at the process to execute an update statement:
1, first found in this line or multi-line data;
2, then the modified data is written to memory, and write changes redo log, this time in the prepare phase redo log and tells the actuators can be submitted;
3, the server returns to the actuator ok, recorded in the original statement binlog ok after receipt of the actuator, is written to disk;
4, after completion of recording binlog, actuator tells the engine layer, a layer corresponding to the engine redo log commit state change from state prepare.
This is 2PC.
If we want to restore the database to a certain point in time, such as Tuesday, the Tuesday before to find the most recent full backup, then the backup execution time of Tuesday's binlog, get a temporary database.
Can not do two-phase commit, and these two steps into independence to do it? Consider the following two possible scenarios (the columns of a row count from 0 into 1):
1, do first redo log, write-bin log
If successful the first to write redo log, not written binlog to collapse, and this time the count column has been changed to 1, while data recovery, using a bin log, bin log is missing from this one operation, then appeared with bin log out of the recovery and the current db db ratio, there has been inconsistent.
2, do first if bin log, then write redo log
If the finish bin log, redo log not written, it collapses, db when the crash to say there is no count = 1 this modification. The recovered with bin log db in this line is recorded, so there have been inconsistent.
So, update and bin log for the redo log do 2PC is still very necessary.
In addition. There is a redo log configuration items innodb_flush_log_at_trx_commit set to 1, ensure that the time after each transaction redo log can be updated to disk. This does not appear to be lost.
innodb_flush_log_at_trx_commit = 0 indicate disk writes per second. In this way it is possible to lose up to 1 second of data.
When set to 2, represents a time after the transaction redo log buffer is written os buffer, then the second is to call fsync () writes os buffer in the logs to the log file on disk. In this case, the system collapse if the data will be lost one second, if mysql collapse, it will not lose data.
sync_binlog also recommended set to 1, indicating that each binlog after the transaction is persisted to disk, so you can ensure binlog mysql after the abnormal restart without losing records.
Most have a question, write the log also write disks directly update the data also write to disk, the disk is write, efficiency is not the same as you? Such a redo log innodb not bother you? Because the redo log is added in the form of a disk write, so efficiency is very high, and modify data in the database is then written, the efficiency is much lower.