[Top][All Lists]

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

Re: Large File Revision Control??

From: BCC
Subject: Re: Large File Revision Control??
Date: Thu, 23 Aug 2001 14:31:11 -0700

"Greg A. Woods" wrote:
> First off please note that even though you've posted to what you see as
> a newsgroup, this is (now again) a bi-directional news/mailinglist.  If
> you want any sensible help at all you MUST use a working From: header.
> The value "From: BCC <address@hidden>" is pretty useless to 100% of e-mail 
> users!

> You didn't even include a workable e-mail address in the body of your
> message!

Nope!  Too much spam.

> You REALLY REALLY REALLY want to learn MUCH more about DB replication
> and forget all about any kind of version control system or file-transfer
> application for this!

Actually I know a fair amount about db replication.  The paradigm I
described was simplified for the question.  The reason we cannot use
replication successfully in this case is our master is also our
development machine.  The data is often imported in in the form of text
files, tables are manually deleted on occasion (this is not my doing I
can tell you!).  Replication WILL fail when the binary log records an
update that cannot take place on the slave.. or in fact any event at all
that does not take place successfully.  Then you have to restart the
replication at the proper line number in the binary logs, etc, etc.

Replication is wonderful for mirroring data on a moment to moment basis,
but not for a freeze of the db at a particular (developer determined)
moment.  Our developers want to hack and slash at the db, then when they
feel it is ready, migrate it out to the 'slaves'.  MySQL replication
just could not handle duplicating all the hacks and slashes, and
replication stopped.

PostgreSQL and Oracle are not options ( not my decision there ).

If you still think replication is best for this kind of environment, I
would really love to hear how to do it...


reply via email to

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