> However, as far as performance, your answer seems to imply that "build it > and make sure that it works, then measure the performance in > your environment, and try to improve it if it is a problem," am I > understanding you correctly?
I haven't answered anything yet since I was trying to understand your question, and the title of your email first mislead me into thinking you wanted to measure the performance of replication, not the side effects of it :) But my answer would have been what you just wrote (are you reading my mind??). Regarding the improvements, you can tell replication to buffer less data with replication.source.size.capacity which defaults to 64MB. Which reminds me... currently there's no way to tell replication to slow down, it will just try to read/push as fast as it can. Shouldn't be too hard to add some sort of throttling. J-D > Thank you, > Mark > > On Mon, Mar 7, 2011 at 12:06 PM, Jean-Daniel Cryans <[email protected]> > wrote: >> >> Mark, >> >> By "performance implications" you mean the side effects it has on >> things like throughput and latency on the master cluster? You're >> wondering how much of a hit that cluster will take once replication is >> enabled? >> >> verifyrep only does what its name says, it verifies the replication >> was done correctly between two tables for a time range and it's not >> really fancier than that :) Here we have a cron job that checks a >> table at random every 30 minutes for a 1 hour window to make sure >> things work correctly. >> >> J-D
