[EMAIL PROTECTED] wrote on 18/06/2004 15:09:58:
> I would need log-bin and log-slave-updates enabled on the slave,
correct?
>
> So to automate the process it would be better to start both servers
> without the Master-host info in the conf file, letting Heartbeat issue
the
> commands on startup to convert one box to slave. During a fail-over,
> heartbeat would take down the master server and issue the "stop slave"
> command on the slave.Would deleting the master.info be needed at this
> point, or would the stop slave be enough to accept writes?
That is what we do. We have an HA system of single master and one or more
slaves in a line. All systems start up with slave threads NOT running. At
startup, the heartbeat does not know which machine was previously master
and which slave(s) in what order. We have a special 1 row, 1 column table
known, for reasons lost in the past, as the Fishbowl value. This is
incremented every time the configuration changes. We therefore read the
fishbowl value from all machines. Only machines with the largest value of
the fishbowl are candidates for becoming master. We then read the slave
status of all the machines which have this value. Reading the name of the
machine to which it is slaved, we should be able to organise them into one
or more chains of consistent master and slave. The longest such chain
becomes the "live" chain, and its head becomes the master. Slave threads
are then started on all the slaves in this chain.
We now have a running system. All writes are directed to the master, reads
can be directed to any slave (because we have designed around transactions
and locking problems).
All machines with less than the maximum fishbowl value, or which form part
of shorter chains, or simply do not have the databases on them (status
when new or repaired machine is added) have the databases dropped and are
regarded as idle. One by one, the idle machines are slaved to the last
slave in the chain and loaded up with LOAD DATA FROM MASTER, then slave
threads started.
The heartbeat continuously monitors all machines. If the master fails, it
is simply necessary to stop the slave thread on the first slave (now
master), increment the fishbowl value on it (which will ripple down to all
remaining slaves) and direct all writes to it. If the ex-master reappears,
it will have an out-of-dated fishbowl value and will therefore have its
database dumped and reloaded.
We do not bother to delete master.info. It will point to a database with
an out-of-date fishbowl, which can be ignored.
> "In theory, a slave will look at the server-id and will not process
> statements where the server-id matches its own server-id"
>
> So is another option to tell the slave to change master to itself?
This sounds a bit dodgy to me. Strictly speaking, if the master is truly
dead, it is not necessary even to stop the slave thread: there is no
reason not to write to the database while slaving IF no conflicting
updates are being replicated from the master. Practically, it is
definitely advisable to do so in case the master is rebooting.
Alec
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
