bug-gne
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gne]API


From: Hook
Subject: Re: [Bug-gne]API
Date: Thu, 28 Jun 2001 23:06:55 +0800

Rob Scott wrote :
>
> >
> >The former. Trying to produce a tarball from a running database is a
> >non-starter, the only thing that you'd get is corrupt tables (the index
data
> >would always be in memory rather than on disk). You can get replication
to
> >be real time, and it gives you a lot of resilience at very little cost.
>
> yeah exactly.
> but it requires a constant connection, and many sysadmins of possible
> mirrors dont like
> that, they prefer scheduled transfers.
> although, this is better because rather than it having to send ALL the
data
> every 12 h it would just have to send the differences.

Then produce a log file from every transaction which *changes* the database
content. The log file will be a set of SQL statements which can be applied
to bring a slave database up to the same state as the master. Not
replication really, but I've used it where replication isn't practical.

> hmm.
> also, do u know how mysql replication copes with being disconnected for a
> while,
> ie- one of the connections goes down.
> i know things from the db to be replicated are stored in a binary log, but
> how far does that stretch back?
> many binary logs like these ive had experience with only stretch back
about
> an ahour.
> if the connection is out for over an hour, the mirror doesnt get updates
> for over an hour,
> and loses some forever.   the dbs are out of sync and will not do
> replication anymore.

The log keps going until the master/slave get back in contact.

> plus setting up replicators is a bitch.
> basically to make the initial image of our db and the new mirror's db the
> same,
> we would have to freeze our db, tarball the data, wait for the guy the
> other end to get the data
> before we could unfreeze the db.
> this could be got around with a halfway db in a chain though

Hardly. That approach isn't going to work for anything other than a
trivially small database. There are plenty of alternative approaches which
achieve the same effect as replication without necessarily using it.

The Hooker





reply via email to

[Prev in Thread] Current Thread [Next in Thread]