Help Center> Relational Database Service> Best Practices> RDS for MySQL> Description of innodb_flush_log_at_trx_commit and sync_binlog
Updated on 2022-09-21 GMT+08:00

Description of innodb_flush_log_at_trx_commit and sync_binlog

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

Table 1 Parameter description

Parameter

Allowed Values

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. The default value is 1. For details, see Parameter Description.

sync_binlog

0 to 4, 294, 967, 295

Sync binlog (RDS for 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 is set to N (N>1) and innodb_flush_log_at_trx_commit is set to 2, the RDS for MySQL write operation achieves the optimal performance.