序文
MySQLマスタースレーブレプリケーションを構成する場合、必要な構成パラメーターに加えて、innodb_flush_log_at_trx_commit
とsync_binlogの2つのパラメーターが構成されることがよくあります。このパラメーターの役割を見てみましょう。
innodb_flush_log_at_trx_commit
トランザクションをコミットするときは、REDOログをディスクに書き込みます。いわゆるREDOログは、データに加えた変更を記録するものです。たとえば、名前フィールドの値を「id = 10」に変更した場合、これはログです。トランザクションをコミットする場合は、特定の戦略に従って、REDOログをREDOログバッファからディスクファイルにフラッシュします。現時点では、この戦略はinnodb_flush_log_at_trx_commitを介して構成されており、いくつかのオプションがあります。
値は0です。トランザクションがコミットされると、REDOログバッファー内のデータはすぐにディスクファイルにフラッシュされませんが、InnoDBのメインスレッドは毎秒ディスクにフラッシュされます。この時点で、トランザクションをコミットできます。その結果、mysqlがダウンし、メモリ内のすべてのデータが失われます。
値は1です。トランザクションをコミットするときは、REDOログをメモリからディスクファイルにフラッシュする必要があります。トランザクションが正常にコミットされる限り、REDOログはディスク上にある必要があります。オペレーティングシステムの「遅延書き込み」機能のため、この時点でのフラッシュはオペレーティングシステムのバッファにのみ書き込まれるため、同期操作により、ハードディスクに永続化する必要があることが保証されます。
値2：トランザクションをコミットするとき、ディスクファイルを直接入力するのではなく、ディスクファイルに対応するosキャッシュキャッシュにREDOログを書き込みます。osキャッシュのデータをディスクファイルに書き込むのに1秒かかる場合があります。
トランザクションの耐久性を実際に保証できるのは1つだけであることがわかりますが、更新操作fsync（）はブロックされ、完了するまで戻らないため、ディスクへの書き込み速度が非常に遅いことがわかります。 MySQLのパフォーマンスは明らかに低下します。トランザクションの損失を気にしない場合は、0と2でより高いパフォーマンスを実現できます。
# 查询
select @@innodb_flush_log_at_trx_commit;
sync_binlog
このパラメーターは、バイナリログをディスクに書き込むプロセスを制御します。
このパラメータの有効な値は0、1、Nです：
0：默认值。事务提交后，将二进制日志从缓冲写入磁盘，但是不进行刷新操作（fsync()），此时只是写入了操作系统缓冲，若操作系统宕机则会丢失部分二进制日志。
1：事务提交后，将二进制文件写入磁盘并立即执行刷新操作，相当于是同步写入磁盘，不经过操作系统的缓存。
N：每写N次操作系统缓冲就执行一次刷新操作。
このパラメーターを1より大きい値に設定すると、データベースのパフォーマンスが向上しますが、データが失われるリスクも伴います。
バイナリログファイルにはデータ回復が含まれます。マスターとスレーブの間で最大の一貫性を実現する場合は、このパラメーターを1に設定する必要がありますが、パフォーマンスがある程度低下します。