Hi!

>>>>> "Jeremy" == Jeremy D Zawodny <[EMAIL PROTECTED]> writes:

Jeremy> On Wed, Jan 24, 2001 at 10:04:36AM -0800, Steven Roussey wrote:
Jeremy> I'm not sure that this discussion belongs here anymore, so I'll set
Jeremy> the reply-to and hope the list software respects it.

>> What about scaling read _and_ write performance? Is there a plan for
>> allowing multiple master replication, or some other method of
>> clustering?

Jeremy> Well, you can do that today (sort of) with 2-way replication, but that
Jeremy> depends on your implementation. The biggest issue, of course, is how
Jeremy> to resolve conflicts. Ideally there could be some user-supplied logic
Jeremy> to do that (maybe an add on foo.so can be used--in the same way that
Jeremy> you can build a UDF today and tell the server about it).

>> Also related is how do we provide failover? If one machine goes down
>> and repliction is active, then the slave can become the
>> failover. But how do we bring the other server backup and take over
>> master status?

Jeremy> Isn't that what the first entry here:

Jeremy>     http://www.mysql.com/doc/T/O/TODO_future.html

Jeremy> is about?

Jeremy> Obviously it doesn't hint at the actual implementation. And I'm sure
Jeremy> several of us would like to understand it once it is figured out. It
Jeremy> has come up more than once in recent discussions here. We have folks
Jeremy> wondering how it will fit in with the way we'd like to see fail-over
Jeremy> work.

We plan to use the following algorithm on top of our current
replication code to achieve this:

http://www.fault-tolerant.org/recall/

Regards,
Monty

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to