Link to the original text of this article: https://blog.csdn.net/xzk9381/article/details/114872585
When a company developer executes an insert statement in a test environment, it takes more than 10 seconds to execute successfully. Check the database performance, data volume, deadlock and other information of the test environment, all abnormalities are found. Finally, the problem was solved by modifying the log writing method.
1. Modification
Modify the /etc/my.cnf file and change innodb_flush_log_at_trx_commit = 1 to 0, but this will take the risk of possible loss of data that is not stored in the database within 1 second after the database crashes. The description of this parameter in the MySQL documentation is as follows:
If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. When the value is 1 (the default), the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file. When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.
2. Parameter description
- 0: The log buffer will be written to the log file once per second, and the flush (flush to disk) operation of the log file will be performed at the same time. In this mode, when the transaction is committed, the write operation to the disk will not be actively triggered
- 1: MySQL will write the log buffer data into the log file and flush (flush to disk) every time a transaction is submitted. This mode is the system default
- 2: MySQL will write the log buffer data to the log file every time a transaction is submitted, but the flush (flush to disk) operation will not be performed at the same time. In this mode, MySQL will perform a flush (flush to disk) operation every second
3. Matters needing attention
When set to 0, this mode is the fastest, but not very safe. The crash of the mysqld process will cause the loss of all transaction data in the last second.
When set to 1, this mode is the safest, but also the slowest one. When the mysqld service crashes or the server host crashes, the binary log can only lose at most one statement or one transaction.
When set to 2, this mode is faster and safer than 0. Only when the operating system crashes or the system is powered off, all transaction data in the last second may be lost.
The two parameters innodb_flush_log_at_trx_commit and sync_binlog are key parameters that control the MySQL disk write strategy and data security. When both parameters are set to 1, the write performance is the worst. The recommended approach is innodb_flush_log_at_trx_commit=2, sync_binlog=500 or 1000.
Link to the original text of this article: https://blog.csdn.net/xzk9381/article/details/114872585