I have a mysql database with 5.6.

  • Binary logs are enabled and it has 5 slaves.

  • GTID mode enabled.

  • Maximum binlog file size is 1GB.

  • sync_binlog = 0

When I check the free -gh

              total        used        free      shared  buff/cache   available
Mem:           117G         79G        1.4G         25M         37G         37G
Swap:            0B          0B          0B

37GB in Cache.

I wanted to check what are all related to Mysql. So I used fincore and I could see from mysql-bin.000557 to mysql-bin.000590 are in the OS Cache.

Total Cache from binlog is 35GB.

Is this expected behavior?

There is no replication lag in the slave. So why mysql needs to cache the old binlogs in Cache?

1 Answer 1


Yes its expected behaviour. MySQL doesn't control what goes in the buff/cache, that's purely down to the OS. It gets reclaimed quite quickly on any new file access or process memory requirement.

Linux can't really tell its not going to be used again soon, but its not doing anything else with the memory so it just uses it (or more correctly, doesn't immediately purge it).

  • Im using sync_binlog = 0, I per my understand, 0 depend on OS cache and 1 will be controlled by MySQL. Is this correct?
    – TheDataGuy
    Commented Sep 15, 2018 at 10:55
  • sync_binlog is a fsync after writing to the binlog, it ensures its immediate persistence on disk if enabled. If not set, the OS will be required to ensure the data is written before its frees the OS cache pages to something else. In both cases the OS cache will remain used as a read cache until needed by something else.
    – danblack
    Commented Sep 15, 2018 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.