On 4/11/07, David Binger  wrote:
> > I suppose some kind of mechanism could be worked out to handle
> > switching
> > a "mirror" into "master" mode in the event that the master file were
> > irretrievably lost and a mirror needed to be used as a backup.
>
> It will be hard to tell automatically whether the loss of the master
> file
> is temporary or permanent.

This is a problem I'm having now, though with MySQL since my Durus
database is read-only.  Basically we have a web site for sharing
information between responders during disasters, so high availability
is important.  It also contains past incidents for reference.  There
are some 300 users scattered across the country.  We're setting up a
remote autonomous server with an empty database that people can use if
there's a power outage or earthquake at the main site.  But
transferring the records back and forth seems like a mountain of work.
 It's easy enough to rsync the tables and 2 GB of attachment files
nightly, but if we put that on the remote site:

(1) There'll be a gap covering the partial day before the main site went down
(2) When the new server comes back, it's easy to copy over new records
but hard to identify old records that have changed, especially since
the most recent change may be on either server.
(3) If people get confused and modify data on the on the remote site
when the main site is running, the changes will be (1) where nobody
expects to look, and (2) overwritten at the next sync.

I could set up master-slave databases but that's not really what I
want.  I want the master to update the slave during normal times, the
slave to run autonomously when the master is down, and the slave to
update the master (ideally automatically) when it comes back up.  So
it's more of a "two cooperating masters" thing.  But figuring out how
identify and copy records both directions automatically makes my head
spin.  I suppose I could put a timestamp field in every table and
trust that that and the primary key will tell me which records to
merge, if that's reliable enough. And it wouldn't work with Durus
because Durus doesn't have automatically-updated timestamp fields.

We're leaning toward the "second empty site plus static backup" to
start with just because it's simple and reliable, and easy to verify
that it is reliable.

--
Mike Orr