Comments on: MySQL replication and the sync_binlog option http://www.deshong.net/2009/05/mysql-sync-binlog/ Tue, 30 Mar 2010 09:05:20 +0000 hourly 1 http://wordpress.org/?v=3.0-RC1-15022 By: Brian DeShong http://www.deshong.net/2009/05/mysql-sync-binlog/comment-page-1/#comment-138 Brian DeShong Thu, 28 May 2009 12:48:54 +0000 http://www.deshong.net/?p=217#comment-138 @Marc: I've got the 2nd edition of the book, actually. I'll dig around it a bit more, though, thanks! And yeah, I considered that the volume of writes during normal usage will be low enough that having sync_binlog set to 1 may be a good move. I'll probably leave it at 0 during my initial migration, then set it back to 1 once we're up and running. A plan such as this is relatively low-risk, so I'm thinking that may be best. Thanks! @Marc: I’ve got the 2nd edition of the book, actually. I’ll dig around it a bit more, though, thanks!

And yeah, I considered that the volume of writes during normal usage will be low enough that having sync_binlog set to 1 may be a good move. I’ll probably leave it at 0 during my initial migration, then set it back to 1 once we’re up and running. A plan such as this is relatively low-risk, so I’m thinking that may be best.

Thanks!

]]> By: Marc Gear http://www.deshong.net/2009/05/mysql-sync-binlog/comment-page-1/#comment-137 Marc Gear Thu, 28 May 2009 09:19:02 +0000 http://www.deshong.net/?p=217#comment-137 My copy of "High Performance MySQL" (the 2nd Edition) goes into more detail and clearly states the the performance tradeoff of sync_binlog. I'd really recommend the second edition. You got a big leap in performance for your migration by turning this off, however you might consider turning it back on (and accepting the performance hit) for ongoing replication. You're not likely to have the same sort of volume of DML queries during normal server operation than you do during an RDBMS migration. My copy of “High Performance MySQL” (the 2nd Edition) goes into more detail and clearly states the the performance tradeoff of sync_binlog. I’d really recommend the second edition.

You got a big leap in performance for your migration by turning this off, however you might consider turning it back on (and accepting the performance hit) for ongoing replication. You’re not likely to have the same sort of volume of DML queries during normal server operation than you do during an RDBMS migration.

]]> By: domas http://www.deshong.net/2009/05/mysql-sync-binlog/comment-page-1/#comment-136 domas Thu, 28 May 2009 08:17:31 +0000 http://www.deshong.net/?p=217#comment-136 haha, you know, people who run MySQL, properly make sure they have reliable I/O caching layer underneath :) waiting for disk flushes to happen is somewhat 198x stuff. haha, you know, people who run MySQL, properly make sure they have reliable I/O caching layer underneath :) waiting for disk flushes to happen is somewhat 198x stuff.

]]> By: Brent Theisen http://www.deshong.net/2009/05/mysql-sync-binlog/comment-page-1/#comment-135 Brent Theisen Thu, 28 May 2009 02:53:27 +0000 http://www.deshong.net/?p=217#comment-135 Sounds like the write policy on your RAID controller is set to "Write Through" instead of "Write Back". If your RAID controller has a battery and RAM you should really use write back and turn Mysql sync_binlog back to 1. If your controller doesn't have a battery then using Write Back is pretty risk. Good luck. Sounds like the write policy on your RAID controller is set to “Write Through” instead of “Write Back”. If your RAID controller has a battery and RAM you should really use write back and turn Mysql sync_binlog back to 1. If your controller doesn’t have a battery then using Write Back is pretty risk. Good luck.

]]>