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
