[prev in list] [next in list] [prev in thread] [next in thread] 

List:       inet-access
Subject:    Re: Redundant MySQL
From:       Bennett Todd <bet () rahul ! net>
Date:       2000-02-29 16:51:59
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

2000-02-29-01:21:45 Ivan Kohler:
> > In theory, it would only need to be able to reach the master
> > server, which would keep all the other slaves in sync. If the
> > slave can not reach the master server, I'd expect that it would
> > keep a queue of all updates to the master. Or something.
>
> "Or something" turns out to be a _very_ complex problem when
> you have disconnected "slave" databases updating the same
> data.  I can tell you one thing; I certainly wouldn't want to
> trust my "mission-critical" data to a system kludged ontop of
> a non-replicating database by someone who wasn't aware of the
> complex issues surrounding two-way database replication.

I agree 100% with all of that.f

> Despite my free software bias, I think if you need this sort of
> functionality you should be looking at the commercial database
> solutions that include two-way replication support.

Look yes. But make sure you _test_, _carefully_. Commercial
databases happily boast about their live database replication
technology, and enjoy the protective cover that most people won't
even try it, and of those few that do most will just quietly give up
when they can't make it work properly.

If you want strictly passive one-way database replication, and
you are content with a design where _either_ server failing takes
_all_ database access offline until you manually reset one or both
servers and then manually restart all clients, then you can get that
from commercial database replication. If you want bi-directional
replication, or high-availability automatic live failover, do it at
the application level, starting right from the conceptual design of
data flows (hint: think in terms of records which are timestamped
transactions, and application code that always deduces a view of
the current state of the system by analyzing the recent history of
transactions).

> > Assuming one slave gets out of sync with the master because of
> > connection loss, when the connection comes back, both servers
> > would unload a queue of updates, using timestamp or something
> > like that to keep everything in order.
>
> And when multiple slave servers' updates have dependancies on
> their out-of-date data?  Solving this probem is NOT as trivial as
> syncing clock and doing updates in the correct order.

Indeed. Applications can be designed, from the very beginning, to
make this easy. Without application-specific design you won't get
safe reconciliation after detatched operation of master and slave.

- -Bennett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4u/oNL6KAps40sTYRAllXAJ4zpOTO2g4nf0Fe8i4VwGnkoHRICQCeJqgT
fnah8aLsRmJS4h91q+/MPqo=
=DSkG
-----END PGP SIGNATURE-----
-
Send 'unsubscribe' in the body to 'list-request@inet-access.net' to leave.
Eat sushi frequently.   inet@inet-access.net is the human contact address.

[prev in list] [next in list] [prev in thread] [next in thread]