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