1. Undo log
Undo : means to cancel, with the purpose of undoing the operation, returning to the operation in a specified state.
Undo Log : Before the database transaction is committed, the mirror of the transaction modification data (that is, the old version before modification) is stored in the undo log. When the transaction rolls back or the database crashes, the undo log can be used, that is, the old version data , Undo the impact of uncommitted transactions on the database. .
-
For the insert operation, the undo log records the PK (ROW_ID) of the new data, and it is directly deleted when it is rolled back;
-
For delete/update operations, the undo log records the old data row, which will be restored directly when rolled back;
-
They are stored in different buffers.
Undo Log is a product of achieving atomicity of transactions.
Undo Log achieves transaction atomicity : During transaction processing, if an error occurs or the user executes a ROLLBACK statement, MySQL can use the backup in Undo Log to restore the data to the state before the transaction started.
InnoDB found that it can implement multi-version concurrency control based on Undo Log.
Undo Log is used to implement multi-version concurrency control in the MySQL InnoDB storage engine.
Undo Log implements multi-version concurrency control : Before the transaction is submitted, Undo Log saves the version data before it is submitted, and the data in Undo Log can be used as a snapshot of the old version of the data for other concurrent transactions to perform snapshot reading.
Regarding how Undo log implements MVCC, please refer to the previous article: Thorough MySQL (9): MVCC multi-version concurrency control
二，Redo log
Redo : As the name suggests, it is redo. Reproduce the operation for the purpose of restoring the operation.
Redo Log : Refers to any data operated in the transaction, and the latest data is backed up to one place (Redo Log).
Redo Log persistence : It is not written with the commit of the transaction, but is written to the Redo Log during the execution of the transaction. The specific placement strategy can be configured.
Redo Log is a product that emerged to achieve transaction durability.
Redo Log achieves transaction persistence : Prevents dirty pages in the buffer pool from being written into the IBD file of the table at the point of failure. When the MySQL service is restarted, redo logs are performed according to the Redo Log to achieve The non-disk data of the transaction is persisted.
Once the transaction is successfully committed and the data is persisted from the buffer pool to the IBD file of the table, the corresponding transaction data record in the Redo Log loses its meaning at this time, so the writing of the Redo Log is the log file circular writing The process, that is, the process of overwriting.
Persistent configuration of Redo Log
Specify the Redo Log to be recorded in two files {datadir}/ib_logfile1 and ib_logfile2, which can be stored in the specified directory through innodb_log_group_home_dir.
Redo Buffer persistence to Redo Log strategy , by setting the value of Innodb_flush_log_at_trx_commit:
-
Value 0: Submit Redo buffer -> Redo Log OS cache -> flush cache to disk every second, and transaction data within one second may be lost.
-
Value 1 (default value): Redo Buffer -> Redo Log OS cache -> flush cache to disk, the safest and worst-performing method for each transaction commit
-
Value 2: Redo Buffer -> Redo log OS cache is executed every second of transaction commit -> flush cache to disk operation
Three, binlog
binlog is used to record the write operation (not including query) information performed by the database, and it is stored in the disk in binary form. Binlog is the logical log of mysql (it can be simply understood as recording sql statements), and it is recorded by the Server layer. The mysql database using any storage engine will record the binlog log.
1. Binlog usage scenarios
In practice, the binlog two primary usage scenarios, namely master copy from and restore data .
- Master-slave replication: Open binlog on the Master side, and then send the binlog to each Slave side, and the Slave side will replay the binlog to achieve master-slave data consistency.
- Data recovery: recover data by using the mysqlbinlog tool.
2. Timing of binlog flashing
For the InnoDB storage engine, biglog will only be recorded when the transaction is committed. At this time, the record is still in memory, so when is the biglog flushed to the disk? mysql controls the flashing timing of biglog through the sync_binlog parameter, the value range is 0-N:
- 0: No mandatory requirement, the system will determine when to write to the disk by itself;
- 1: Write binlog to disk every time you commit;
- N: Binlog will be written to disk every N transactions.
As can be seen from the above, the safest setting for sync_binlog is 1, which is also the default value for MySQL versions after 5.7.7. But setting a larger value can improve database performance. Therefore, in actual situations, you can also increase the value appropriately, sacrificing certain consistency to obtain better performance.
3. Binlog log format
The binlog log has three formats, namely STATMENT, ROW and MIXED.
Before MySQL 5.7.7, the default format was STATEMENT, and after MySQL 5.7.7, the default value was ROW. The log format is specified by binlog-format.
STATMENT : SQL statement-based replication (statement-based replication, SBR), each SQL statement that will modify the data will be recorded in the binlog.
Advantages: There is no need to record the changes of each line, which reduces the amount of binlog and saves IO, thereby improving performance;
Disadvantages: In some cases, the master-slave data will be inconsistent, such as executing sysdate(), slepp(), etc.
ROW : Row-based replication (RBR), does not record the context information of each SQL statement, only records which data has been modified.
Advantages: There will be no problems in which stored procedures, functions, or triggers cannot be correctly copied under certain specific circumstances;
Disadvantages: a large number of logs will be generated, especially when the alter table causes the log to skyrocket
MIXED : Mixed-based replication (MBR) based on the two modes of STATMENT and ROW. General replication uses the STATEMENT mode to save the binlog. For operations that cannot be replicated in the STATEMENT mode, use the ROW mode to save the binlog.