I was pretty happy with myself with setting up some fairly complicated MySQL circular replication the other night.Â I did it far after peak hours so as not to disturb any visitors if it caused any problems.Â Â Everything appeared to be working great until I started watching things the next morning.
I started to notice that the main MySQL server seemed to be running really slow.Â Â One process that we have usually completes in a couple hours, ended up taking well over 16 hours to complete.Â Â I spent the whole day troubleshooting it, which got me familiar with all sorts of handy tools.Â Â ‘mytop‘ is a handy version of ‘top’ for MySQL queries.Â I got familiar with iostat for watching disk I/O performance.
In the end, after a whole day of troubleshooting it came down to the ‘sync_binlog‘ setting that I had enabled because I read some howto that mentioned it was useful for the replication master.Â My understanding now of the setting is that it causes the operating system to tell the disk to sync the file to disk after each write to the binary log (every UPDATE, INSERT, or DELETE). Â The idea is that when the data is sync’d to disk, the drive physically writes it to the drive, instead of keeping it in a cache.Â Â My application does a ton, of inserts, so it was killing performance.
One thought on “Poor Performance After Enabling Repliction Due to sync_binlog”
Looking up the definition of sync_binlog in http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html, I saw that it mentions the use of battery-backed cache.
Jeremy Cole talked about this in this URL : http://www.mysqlperformanceblog.com/2006/05/27/jeremy-cole-on-mysql-replication/
Read carefully and have fun with it !!!