MySQL 45 lecture learning notes (II) execution of SQL update statements

One . Log module ：redo log

Existing problems ：

• Every update operation needs to be written to disk , Then the disk finds the corresponding record , Then update , The whole process IO cost , High cost of discovery .

Solution ：

• WAL technology ,Write-Ahead Logging 

• Write the log , Write the disk again   ---- And Redis On the contrary

Two .WAL technology

• When a record needs to be updated ,InnoDB The engine will write the record first redo log And then update the memory , At this time, the update is completed .
• InnoDB The engine will... At the right time , Update this operation record to disk , This update usually occurs when the system is idle .

3、 ... and . redo log

InnoDB Of red log Is constant , Can be configured as a set of 4 File , The size of each file is 1GB

InnoDB Can guarantee even if The database is restarted abnormally , Before No records submitted will be lost , This ability is called crash-safe.

Four . Log module :binlog

• Server Layer log -binlog（ Archive log ）
• Engine layer , Responsible for storing the corresponding specific matters ,innoDB journal -redo log

Differences between the two ：

• redo log yes InnoDb Engine specific ;binlog yes MySQL Of server Layer , All engines can use .
• redo log It's a physical log , The record is “ What changes have been made on a data page ”,binlog It's a logical log , Record execution statement
• redo log It's circular , The space will be used up ;binlog Yes, it can be added , finger binlog The file will always be appended , The previous log will not be overwritten .

5、 ... and . perform update The internal flow of the statement

1. The actuator looks for the engine first ID=2 This business .ID It's the primary key , The engine uses a tree search directly to find this line , If ID=2 The data page where this line is located is already in memory , Directly back to the actuator , Otherwise, read from the disk into the memory and return .
2. The actuator gets the engine row data , Add the values of a , Then call the engine interface to write
3. The engine updates this new row of data into memory , At the same time, the update operation is recorded to redo log in , here redo log be in prepare state , Then tell the actuator to complete , You can commit a transaction .
4. The actuator generates the binlog, And put binlog Write to disk .
5. The executor calls the engine's commit transaction interface , The engine just wrote redo log Change to submit （commit） state , Update complete .

6、 ... and . Two-phase commit

• Why do I have to submit in two phases ？
• Make the logic of the two logs consistent

  How to restore the database to any second in half a month

    Solution ：

• binlog Will record all logical operations , And adopt " Additional writing " In the form of
• The backup system can save all the data in the last half month binlog, At the same time, the system will backup the whole database regularly
• This periodicity can depend on the importance of the system , It can be backed up once a day , It can also be backed up once a week .

Restore the scene ： One day at two o'clock in the afternoon, I found that there was a mistake to delete the table at twelve o'clock in the afternoon

•   Find the last full backup , Restore to temporary Library ;
• From the point in time of the backup , Will back up binlog Take them out one by one , Put it back to the time before the table was deleted by mistake at noon .
• Table data is fetched from the temporary database , Restore to online library as needed .

The disadvantage of not doing two submissions ：

First write redo log Post write binlog 

• hypothesis redo log finish writing sth. ,binlog Before writing ,musql collapse
• redo log After writing , System crash , So you can recover the data
• binlog I didn't finish writing crash 了 , Now binlog No record of this statement .
• But by binlog Synchronized slave libraries will result in missing commands from the slave libraries .

First write binlog To write redo log

• binlog After writing crash live , however redo log Not yet , The transaction is invalid at this time
• however binlog The log has been recorded
• Then through the binlog Synchronous slave libraries will cause the slave libraries to increase the execution of this command .

• redo log Used to guarantee crash-safe Ability
• innodb_flush_log_at_trx_commit by 1 Ensure that each transaction is redo_log All persist directly to disk ,mysql No data loss after restart .
• sync_binlog This parameter is set to 1 When , For each transaction binlog Will be persisted to the disk mysql After abnormal restart binlog No loss .