Mark, On Tue, Mar 23, 2010 at 4:55 AM, MARK CALLAGHAN <mdcal...@gmail.com> wrote:
> On Mon, Mar 22, 2010 at 7:52 PM, Jeremy Zawodny <jer...@zawodny.com> > wrote: > > > > Latency. Specifically I want muli-threaded replication so I can better > take > > advantage of mutli-core slaves. I'm willing to assume the "risk" > associated > > with saying "yes, I'm sure that each of these logical dbs are logically > > separate, and no statements will cross them." > > Paul started it, so I will add another plug. > > Are your slaves IO bound? If so, have you tried mk-slave-prefetch? I > think it can fix the replication lag problems for IO bound slaves. It > needs more people to test and use it. It can be used right now. > I actually did use mk-slave-prefetch a year or so ago but ended up proving to myself that we were not I/O bound in the worst case. We were then (and still currently are, pending a few ALTER TABLEs) bound on index updates for over-indexed tables in InnoDB. > I don't know if it good enough yet. We have sponsored a lot of work on > it because we think it can be good enough. > Yeah, for cases where your cache just needs to be warmed ahead of the work, I think it's a great tool. > It won't do anything for workloads with crazy and gigantic joins or > deletes/updates with full-table scans on large tables. Those problems > require education, not faster replication. > Indeed. I'm still trying to fix the over-indexing nightmare that pre-dates me. I should show slides at a conference sometime to illustrate the effects of heavily indexed tables on replication (or general update) throughput. The numbers shocked me at first. Jeremy
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
