MySQL 重要参数 innodb_flush_log_at_t
2019-05-16 本文已影响0人
风亡小窝
innodb_flush_log_at_trx_commit
该参数控制重做日志写入磁盘的过程。我们知道 InnoDB 使用“Write Ahead Log”策略来避免数据丢失问题，即依靠重做日志来保证数据能在丢失后进行恢复。因此，InnoDB 重做日志的持久化非常重要。
该参数的有效值有 0、1、2：
- 0: 事务提交时，不将重做日志缓冲写入磁盘，而是依靠 InnoDB 的主线程每秒执行一次刷新到磁盘。因此如果 MySQL 发生宕机，那么就有可能丢失一部分事务。
-
1: 事务提交时，会将重做日志缓冲写入磁盘，并且立即刷新（
fsync()）。注意，因为操作系统的“延迟写”特性，此时的刷入只是写到了操作系统的缓冲区中，因此执行同步操作才能保证一定持久化到了硬盘中。 - 2: 事务提交时，会将重做日志缓冲写入磁盘，但是不会立即进行刷新操作，因此只是写到了操作系统的缓冲区。此时若操作系统发生宕机而没有即使的同步，也可能会丢失一部分数据。
影响
- 当设置为0，该模式速度最快，但不太安全，mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
- 当设置为1，该模式是最安全的，但也是最慢的一种方式。在mysqld 服务崩溃或者服务器主机crash的情况下，binary log 只有可能丢失最多一个语句或者一个事务。。
- 当设置为2，该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
sync_binlog
该参数控制着二进制日志写入磁盘的过程。
该参数的有效值为0 、1、N：
-
0：默认值。事务提交后，将二进制日志从缓冲写入磁盘，但是不进行刷新操作（
fsync()），此时只是写入了操作系统缓冲，若操作系统宕机则会丢失部分二进制日志。 -
1：事务提交后，将二进制文件写入磁盘并立即执行刷新操作，相当于是同步写入磁盘，不经过操作系统的缓存。
-
N：每写N次操作系统缓冲就执行一次刷新操作。
影响
二进制日志文件涉及到数据的恢复，以及想在主从之间获得最大的一致性，那么应该将该参数设置为1，但同时也会造成一定的性能损耗。
通常，会将这两个参数都设置成1来保证数据的安全，但是如果在某些情况下性能更重要，那么可以考虑将其设为其他值来获得最大的性能。
