Ok, I supposed Monty forwarded this to me so I could comment on it.
>
> Michael Widenius wrote:
> > 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
>
> Greetings All:
>
> 2 Parts...
>
> Part 1:
> I reference the above because the Recall project hasn't had any activity
since
> September 2000 and, after wasting 2 1/2 hours building the ACE and Pth
> dependencies want to know if MySQL still has interests in the Recall
project, or
> just the algorithm, and, if so, what is the algorithm? This might seem a
> brain-dead question, but, what the Screenshots on the Recall web-site
display
> looks promising and could have viable uses for a multi-node application;
> specifically a fail-over multi-node; multi-master/slave MySQL
implementation.
> Unfortunately, recall-0.8 cannot be built on any of my systems.
When I started to work on replication I had similar struggles with recall - I
finally got it to work on its own and started to think about how it could
work with MySQL when Monty called me and suggested that we first need to make
it work a simple way - the master keeps the binary log while the slave
connects, reads it, and does the updates. We still plan to use recall in 4.0,
but we will just write an external agent that will issue SQL commands to
elect the master and synchronize the slaves.
>
> Part 2:
> Specifically, I'm building the following high availability configuration. I
> have two networks, and potentially others once the proof of concept is in
> place. The primary site runs several stand-alone MySQL applications for
several
> domains on one server. Mostly web-server logging. So, this server needs to
> update itself.
>
> The second network will have 5 IP addresses and each will run a fully
mirrored
> Apache/MySQL application server. Each will track it's own traffic.
> Additionally, I'd like it to update all other nodes with traffic activity.
> Unique ID's on auto-increment fields aren't a consideration. Each server
will
> simply log the hit and notify each slave that it should update itself. Each
> node should be a master and a slave. If one slave goes down, it will be
> notified by the nearest (network distance; that is) master of the updates it
> needs. Since this slave is also a master, it will need to notify the
nearest
> slave to replicate any data that was saved to the server that just came
back up,
> if any.
>
> On paper it looks simple. Reading the master/slave implementation currently
> available, I don't see that the current state of replication can support
this,
> but, perhaps the above algorithm is similar to the Recall algorithm. If so,
> what's necessary to do this, and, what are the complications in having each
node
> be a slave and master and all nodes listen to each node for updates as well
as
> notifying other nodes when updates are needed?
>
> Thanks for any useful thoughts.
Here is what you can do:
server1 -> server2-> server3 -> server4 -> server5 ->
^ |
| |
---------------------------------------------------
Arrows indicate master-slave relationships
One "gotcha" is that you will have to generate record id yourself -
auto-increment will not work - but this is not very hard - server 1 starts
with 1, for example, server 2 with 2, ..., server 5 with 5, and each time you
add 5 to the sequence number. You can accomplish this with a table that you
*do not* replicate on each server called sequence:
update sequence set id = last_insert_id(id + 5);
insert into log (id, ...) values (last_insert_id(), ...);
To do failover, use CHANGE MASTER TO on the slave of the failed master to
point it to the next machine. The difficult part here is to decide which
log/offset to start at and how to properly insert a recovered server into the
chain - these problems are solvable, I just cannot solve them as I am
composing the e-mail - need some time to think.
--
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
---------------------------------------------------------------------
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
