Effect of --flush-logs on a slave mysqldump?
Point to be considered whether your --flush logs ( Closes current binary log &amp; opens new binary log with consecutive number ) will be beneficial or not :

One thing that you are using --single-transaction option (It is useful only with transactional tables such as InnoDB, because then it dumps the consistent state of the database at the time when START TRANSACTION was issued without blocking any applications). This means a snapshot of current database is taken for backup where data modification during this timestamp is not considered in backup &amp; can be retrived from binary logs.

To check the write operation is performed during backup activity on database, you can verify by no of binary logs written during that time.

If write operation intensity is more during this time, then you can afford to start replication from last file written during backup completion.


To overcome this thing,

Measure no of binary logs written during backup time. ( Hope backup time is preferred where less write operation are performed on db).

If No of Binary logs are more during backup time :
Take before backup binary logs reading from master &amp; can be used for starting replication ( Probably there may duplicate error, need to skip it) as data consistency is concerned.


mysql -uuser -pXXX -h192.168.XX.XX -e 'show master status' &gt; before_rd.sql

time mysqldump  -uuser -pXXx -h192.168.XX.XX --force --all-databases --max_allowed_packet=360M --lock-tables=false --triggers --routines &gt; backup_$dd.sql 2&gt; bkp_mep_$dd.log

mysql -uuser -pXXX -h192.168.XX.XX -e 'show master status' &gt; after_rd.sql


If No of Binary logs are less or none during backup time :
Take after backup binary logs reading from master &amp; can be used for starting replication ( -- flush-logs can be used ) as data consistency is maintained.