MySQL important parameters innodb_flush_log_at_trx_commit and sync_binlog
innodb_flush_log_at_trx_commit
The main control innodb data log buffer is written to the log file to disk and flush points, respectively 0,1,2 three values. This parameter controls the process redo logs written to disk. We know that InnoDB uses "Write Ahead Log" strategy to avoid data loss problems, which rely redo logs to ensure data can be recovered from the loss. Therefore, InnoDB redo log persistence is very important. The default value of this parameter 1
You first need to know roughly mysql log steps:
log_buff> mysql write (write)> log_file> OS refresh (flush)> disk
innodb_flush_log_at_trx_commit of parameters:
0 (write latency, real-time brush): log_buff - every 1 second> log_file - Real-time> Disk
. 1 (real writing brush real): log_buff - Real-time> log_file - Real-time> Disk
2 (real-time writing brush delay): log_buff - real-time> log_file - every 1 second> disk
# 查询
select @@innodb_flush_log_at_trx_commit;
Valid values for this parameter are 0,1,2:
0: When a transaction is committed, not to redo log buffer is written to disk, but on the main thread of execution InnoDB flushed to disk every second. So if MySQL downtime occurs, then you may lose part of the transaction.
1: When the transaction commits, the redo log buffer will be written to disk, and immediately refresh (fsync ()). Note that because "delayed write" feature of the operating system, then brush into the buffer just written to the operating system, so you can perform synchronous operation guaranteed persisted to the hard disk.
2: When the transaction commits, will redo log buffer is written to disk, but does not refresh operation immediately, so just write to the buffer of the operating system. At this point if the operating system downtime occurs even without synchronization, also part of the data may be lost.
You can see, only one can truly guarantee the durability of transactions, but due to the refresh operation fsync () is blocked, until after the return, we know to write disk speed is very slow, so MySQL performance will be significantly decline. If you do not care about lost transactions ,, 0 and 2 can achieve higher performance.
sync_binlog
This parameter controls the process binary logs written to disk.
The valid values for this parameter 0, 1, N:
0: default. After the transaction is committed, the binary log is written from the buffer disk, but does not refresh operation (fsync ()), but this time write the operating system buffer, if the operating system is down-part binary log will be lost.
1: After the transaction commits, the binary file is written to disk and perform a refresh operation immediately, the equivalent of a synchronous write to the disk without the operating system cache.
N: N times each write buffer on the operating system to perform a refresh operation.
This parameter is set to 1 or greater value will improve the performance of the database, but will be accompanied by the risk of data loss.
Binary log files related to the recovery of data, as well as between the master and slave wants to get the most consistency, you should set this parameter to 1, but it can also cause some performance loss.
innodb_flush_log_at_trx_commit
The main control innodb data log buffer is written to the log file to disk and flush points, respectively 0,1,2 three values. This parameter controls the process redo logs written to disk. We know that InnoDB uses "Write Ahead Log" strategy to avoid data loss problems, which rely redo logs to ensure data can be recovered from the loss. Therefore, InnoDB redo log persistence is very important. The default value of this parameter 1
You first need to know roughly mysql log steps:
log_buff> mysql write (write)> log_file> OS refresh (flush)> disk
innodb_flush_log_at_trx_commit of parameters:
0 (write latency, real-time brush): log_buff - every 1 second> log_file - Real-time> Disk
. 1 (real writing brush real): log_buff - Real-time> log_file - Real-time> Disk
2 (real-time writing brush delay): log_buff - real-time> log_file - every 1 second> disk
# 查询
select @@innodb_flush_log_at_trx_commit;
Valid values for this parameter are 0,1,2:
0: When a transaction is committed, not to redo log buffer is written to disk, but on the main thread of execution InnoDB flushed to disk every second. So if MySQL downtime occurs, then you may lose part of the transaction.
1: When the transaction commits, the redo log buffer will be written to disk, and immediately refresh (fsync ()). Note that because "delayed write" feature of the operating system, then brush into the buffer just written to the operating system, so you can perform synchronous operation guaranteed persisted to the hard disk.
2: When the transaction commits, will redo log buffer is written to disk, but does not refresh operation immediately, so just write to the buffer of the operating system. At this point if the operating system downtime occurs even without synchronization, also part of the data may be lost.
You can see, only one can truly guarantee the durability of transactions, but due to the refresh operation fsync () is blocked, until after the return, we know to write disk speed is very slow, so MySQL performance will be significantly decline. If you do not care about lost transactions ,, 0 and 2 can achieve higher performance.
sync_binlog
This parameter controls the process binary logs written to disk.
The valid values for this parameter 0, 1, N:
0: default. After the transaction is committed, the binary log is written from the buffer disk, but does not refresh operation (fsync ()), but this time write the operating system buffer, if the operating system is down-part binary log will be lost.
1: After the transaction commits, the binary file is written to disk and perform a refresh operation immediately, the equivalent of a synchronous write to the disk without the operating system cache.
N: N times each write buffer on the operating system to perform a refresh operation.
This parameter is set to 1 or greater value will improve the performance of the database, but will be accompanied by the risk of data loss.
Binary log files related to the recovery of data, as well as between the master and slave wants to get the most consistency, you should set this parameter to 1, but it can also cause some performance loss.