[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gne]API
From: |
Rob Scott |
Subject: |
Re: [Bug-gne]API |
Date: |
Thu, 28 Jun 2001 13:00:09 +0100 |
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.
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.
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
main db->mirror master
| | |
m m m
m - mirror
hope u dont have a proportional font :)
then only the mirror master would have to be frozen.
The Hooker
?????
wtf?!!!!
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