[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.

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


reply via email to

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