Re: [Bug-gne]API

[Rob Scott]

> 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?!!!!