table of Contents
Preface
When we configure MySQL master-slave replication, in addition to the necessary configuration parameters, these two parameters are often configured: innodb_flush_log_at_trx_commit
and sync_binlog. Let's take a look at the role of this parameter.
innodb_flush_log_at_trx_commit
When committing the transaction, write the redo log to the disk. The so-called redo log is to record what changes you have made to the data. For example, if you change the value of the name field to "id=10", this is a Log. If we want to commit a transaction, then we will flush the redo log from the redo log buffer to the disk file according to a certain strategy. At this time, this strategy is configured through innodb_flush_log_at_trx_commit, and it has several options.
The value is 0: When the transaction is committed, the data in the redo log buffer is not flushed to the disk file immediately, but the main thread of InnoDB is flushed to the disk every second. At this time, you may commit the transaction, and as a result, mysql is down, and then all the data in the memory is lost.
Value is 1: When committing a transaction, you must flash the redo log from memory to the disk file. As long as the transaction is successfully committed, the redo log must be on the disk. Note that because of the "delayed write" feature of the operating system, the flashing at this time is only written to the operating system's buffer, so the synchronization operation can ensure that it must be persisted to the hard disk.
Value 2: When committing the transaction, write the redo log into the os cache cache corresponding to the disk file instead of directly entering the disk file. It may take 1 second to write the data in the os cache to the disk file. .
It can be seen that only 1 can really guarantee the durability of the transaction, but because the refresh operation fsync() is blocked and does not return until it is completed, we know that the speed of writing to the disk is very slow, so the performance of MySQL will be obvious decline. If you don't care about transaction loss, 0 and 2 can achieve higher performance.
# 查询
select @@innodb_flush_log_at_trx_commit;
sync_binlog
This parameter controls the process of writing binary logs to disk.
The valid values of this parameter are 0, 1, N:
0：默认值。事务提交后，将二进制日志从缓冲写入磁盘，但是不进行刷新操作（fsync()），此时只是写入了操作系统缓冲，若操作系统宕机则会丢失部分二进制日志。
1：事务提交后，将二进制文件写入磁盘并立即执行刷新操作，相当于是同步写入磁盘，不经过操作系统的缓存。
N：每写N次操作系统缓冲就执行一次刷新操作。
Setting this parameter to a value above 1 will improve the performance of the database, but it will also be accompanied by the risk of data loss.
Binary log files involve data recovery, and if you want to achieve maximum consistency between master and slave, you should set this parameter to 1, but it will also cause a certain performance loss.