Previous article we said that the execution of a sql query. If you have not read the previous article can look at the article, today we talk about a process executed sql update.
update scores set score=c+10 where id=1
Sql id is above a fraction of 1 to 10 plus.
Then its execution flow is what is it? Borrowing on the articles of the map, as follows:
I am here to talk about this again simple process, first of all clients to connect mysql server, sql statement executed after the connection, the need to go through the implementation process sql parser come it is necessary to do an update operation, followed through the optimizer decides to use it id the index, and then through the actuator through the index to find the line, the last update operation.
These are updated throughout the entire process operation too. Having said that you'd think had finished, but I regret to tell you that's just the beginning.
Because the update and query operations are not the same, the update operation involves two very important log module. redo log (redo logs) and bin log (archive log). The two say today is the focus.
First we have to know what these two logs are? And then you have to know that they are doing?
redo log InnoDB engine is unique, it belongs to the physical log, mainly for the record "change has been made on a data page," and its recording space is fixed and will run out.
bin log belongs server layer holdings, mainly re actuators logging, so mysql all engines can use it. bin log belongs logical logs, it statement and row modes, statement is recorded in the sql statement executed, updates the contents recorded row line, so that two records, one before updating the content, is an additional updates after. The default mode is the mode row. In addition bin log is appended written to the log, the log file is written to a certain size and they will switch to the next continue to write the log, and does not overwrite the previous log file.
These are the concepts and the role of these two logs, so now we have to talk about their recording process. Let's look at a picture below, fill color yellow for the operation of the actuator, the fill color to blue engine operation InnoDB
Figure a bit long, but it should be easy to understand. Then step by step analysis now.
1, the first actuator will take the engine to find this data id = 1;
2, because the id is the primary key, so use the tree to find a row of data. But the engine to go to find whether there is the memory page data;
3, if the data is returned directly to the actuator; if not it will go to the disk data read into memory, and returns the data to the actuator.
4, the actuator will perform the operation C + 10;
5, the actuator generates a new row of data;
6, then call write ports InnoDB engine, the updated data into the memory;
7, InnoDB engine is written redo log logs mark state prepare, and told the actuator has been updated data is completed, the transaction can be submitted at any time;
8, the actuator the operation of writing this bin log, and the bin log is written to disk;
9, the last execution engine calls to commit the transaction interface engine to change the status of the redo log commit, so far the entire update operation is completed.
Maybe you see here you will emerge a few questions?
1, redo log space is fixed, then it will not run out of it?
First, do not worry about redo log will run out of space, because it is recyclable. E.g. redo log log configured as a set of four files, each respectively 1G. Write it flow as shown below:
Figure above two fill color, yellow and red, yellow marked check point, which indicates the current position of the redo log is erased, the red marked write pos, which indicates the position of the current record in the redo log. When the redo log is full, it will stop, no data is written, it will erase redo log operation, of course, before erasing the logs will write data to disk, the data persistence. So as to keep the accuracy of the data.
2, why should these two log it? Because in the absence of the InnoDB engine is no redo log log.
InnoDB redo log because the engine can be guaranteed even if the database is down suddenly or abnormal restart, previously submitted data is not lost. Let's call this ability crash-safe.
3, when the mysql server during execution suddenly goes down, the data will not be lost?
The answer is no. Why so sure? We can see from the second chart. For example, the following situations:
1, is down, then the original data is not sent before the change is written redo log, because the transaction has not been submitted.
2. If, after the write redo log, before writing down bin log, the original data still will not change, because the database is restarted, because the records of both logs are not synchronized, so there will be no new data are generated.
3, before the redo log generated commit is down, restart the database after data becomes the updated data, because this time the redo log and bin log has a record, so the database is restarted will conduct commit myself, so this time data is updated the data.
We use the redo log mainly need to ensure that crash-safe capability, innodb_flush_log_at_trx_commit this parameter is set to 1, it represents each redo log transactions directly persisted to disk. I suggest you set this parameter to 1. This ensures that data is not lost after the abnormal restart MySQL.
sync_binlog this parameter is set to 1, each transaction represents the binlog have persisted to disk. I also suggest you this parameter is set to 1, so you can ensure MySQL binlog is not lost after the abnormal restart.
Well, today said that, if the wrong place to write welcome to point out that the discussion we learn together.