Todd, This is great information! And we're already feeding this into plans related to replication.
One question regarding this-- you specifically mention this is the case for MySQL 5.0. Is it also the case for 5.1 or is the situation different for 5.1? I remember seeing some mention in the 5.1 release notes regarding performance and replication. Thanks, --Van > -----Original Message----- > From: Todd Farmer [mailto:t...@fivefarmers.com] > Sent: Thursday, July 09, 2009 9:31 PM > To: A good place to start for users or folks new to Mifos. > Subject: Re: [Mifos-users] MySQL > > Hi, > > Adam Feuer wrote, On 7/9/2009 8:00 PM: > > >From my experience (at Amazon and other places) one-direction MySQL > > replication overhead on the master (production) database is > > negligible. The server is only writing binary logs to the network, > > something it already does to disk. This uses only small amounts of > CPU > > and a small amount of network bandwidth. > > > > Also, since reporting load will now go to the slave database as Beth > > says, load on the master should be much lighter. > > > Just agreeing with Adam, here. The major impact isn't replication > (shipping the binary logs to another server), but rather the binary > logging itself (that's the focus of the blog entries in the original > email). If you already have binary logging enabled, setting up > replication is no big deal, performance-wise. > > That said, there are ways to reduce the performance hit that binary > logging entails (disabling XA transactions - not used in most > applications - is a good start, as using a different physical disk for > binary logs). > > One performance element which sometimes hits people new to MySQL > replication is actually the performance of the slave. It's important > to > have a machine that is at *least* as powerful as the master. This is > because MySQL replication (in 5.0 and earlier) takes the DML statements > being issued by multiple client threads, which the slave then executes > in a single thread. If you have 5 different long-running DML > statements > affecting different tables, they can execute simultaneously on the > master, but are executed serially on the slave. And any statement > which > is slow on the master will be similarly slow on the slave - the > statement still has to go through the exact same process on the slave > as > it did on the master (parsing, optimizing, locking, execution, etc.). > > People sometimes fall into a trap where they assume that the master is > doing all the heavy lifting, and the slave can be a less powerful > machine. This isn't true - it's doing all the work the master is > doing, > except in a single thread while the master might have work spread > across > multiple concurrent threads. Plus it has to deal with the read volume > that has been offloaded to the slave. > > Best regards, > > Todd Farmer > > > ----------------------------------------------------------------------- > ------- > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited > time, > vendors submitting new applications to BlackBerry App World(TM) will > have > the opportunity to enter the BlackBerry Developer Challenge. See full > prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Mifos-users mailing list > Mifos-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mifos-users ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Mifos-users mailing list Mifos-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mifos-users
