Help Center > > Best Practices> MySQL> Description of innodb_flush_log_at_trx_commit and sync_binlog

Description of innodb_flush_log_at_trx_commit and sync_binlog

Updated at: Dec 30, 2019 GMT+08:00

The innodb_flush_log_at_trx_commit and sync_binlog are key parameters for controlling the MySQL disk write policy and data security. Different parameter values have different impacts on performance and security.

Table 1 Parameter description

Parameter

Allowed Value

Description

innodb_flush_log_at_trx_commit

0, 1, and 2

Controls the balance between strict ACID compliance for commit operations, and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. When this parameter is set to 0, the content of the InnoDB log buffer is written to the log file approximately once per second and the log file is flushed to disk. The default value of 1 is required for full ACID compliance. With this value, the contents of the InnoDB log buffer are written out to the log file at each transaction commit and the log file is flushed to disk. When this parameter is set to 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second.

sync_binlog

0 to 4,294,967,295

Sync binlog (MySQL flushes binary logs to disks or relies on the OS).

Parameter Description

innodb_flush_log_at_trx_commit:

  • 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.
  • 1: 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.
  • 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.
    • A value of 0 is the fastest choice but less secure. Any mysqld process crash can erase the last second of transactions.
    • A value of 1 is the safest choice because in the event of a crash you lose at most one statement or transaction from the binary log. However, it is also the slowest choice.
    • A value of 2 is faster and more secure than 0. Only an operating system crash or a power outage can erase the last second of transactions.

sync_binlog=1 or N:

By default, the binary log is not every time synchronized to disk. In the event of a crash, the last statement in the binary log may get lost.

To prevent this issue, you can use the sync_binlog global variable (1 is the safest value, but also the slowest) to synchronize the binary log to disk after N binary log commit groups.

Recommended Configurations

Table 2 Recommended configurations

innodb_flush_log_at_trx_commit

sync_binlog

Description

1

1

High data security and strong disk write capability

1

0

High data security and insufficient disk write capability. Standby lagging behind or no replication is allowed.

2

0/N(0<N<100)

Low data security. A small amount of transaction log loss and replication delay is allowed.

0

0

Limited disk write capability. No replication or long replication delay is allowed.

  • When both innodb_flush_log_at_trx_commit and sync_binlog are set to 1, the security is the highest but the write performance is the lowest. In the event of a crash you lose at most one statement or transaction from the binary log. This is also the slowest choice due to the increased number of disk writes.
  • When sync_binlog=N (N>1) and innodb_flush_log_at_trx_commit=2, the MySQL write operation achieves the optimal performance.

Did you find this page helpful?

Submit successfully!

Thank you for your feedback. Your feedback helps make our documentation better.

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?







Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel