[Top][All Lists]
[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
- Re: [Bug-gne]API, (continued)
- Re: [Bug-gne]API, Rob Scott, 2001/06/27
- Re: [Bug-gne]API, Rob Scott, 2001/06/27
- Re: [Bug-gne]API, Hook, 2001/06/27
- Re: [Bug-gne]API, Tom Chance, 2001/06/27
- Re: [Bug-gne]API, Tom Chance, 2001/06/27
- Re: [Bug-gne]API, Tom Chance, 2001/06/28
Re: [Bug-gne]API, Tom Chance, 2001/06/28
Re: [Bug-gne]API, Tom Chance, 2001/06/28
Re: [Bug-gne]API, Tom Chance, 2001/06/28
Re: [Bug-gne]API, Tom Chance, 2001/06/28
Re: [Bug-gne]API, Tom Chance, 2001/06/28