Re: Synchronize Backup to another remote database

jnasby@pervasive.com ("Jim C. Nasby") writes:
> On Tue, May 16, 2006 at 09:35:57AM +0800, kah_hang_ang@toray.com.my wrote:
>> Currently we want to upgrade postgresql to 8.1.3 but our current postgresql
>> database (v7.2.2) is use in the production line so we can't stop the
>> current database.
>> So is there any way to synchronize backup the current postgresql database
>> to another remote postgresql database without interrupt our current
>> postgresql database?
>
> You could maybe, possibly, theoretically hack Slony to run against 7.2.
> I know someone did this to get slony to run on 7.3. You'd want to use
> an old version of Slony, which means you'd only be able to go from 7.2
> to 7.4. But once you were on 7.4, you could use the most recent Slony to
> go from 7.4 to 8.1.

Actually, the hack was on version 7.2.

-----------------------------------------------------------------------
<http://linuxfinances.info/info/faq.html#AEN44224>

 This is approximately what you need to do:

    * Take the 7.3 templates and copy them to 7.2 -- or otherwise hardcode the version your using to pick up the 7.3
templates
    * Remove all traces of schemas from the code and sql templates. I basically changed the "." to an "_".
    * Bunch of work related to the XID datatype and functions. For example, Slony creates CASTs for the xid to xxid and
back-- but 7.2 cannot create new casts that way so you need to edit system tables by hand. I recall creating an
OperatorClass and editing several functions as well. 
    * sl_log_1 will have severe performance problems with any kind of data volume. This required a number of index and
querychanges to optimize for 7.2. 7.3 and above are quite a bit smarter in terms of optimizations they can apply. 
    * Don't bother trying to make sequences work. Do them by hand after the upgrade using pg_dump and grep.

Of course, now that you have done all of the above, it's not
compatible with standard Slony now. So you either need to implement
7.2 in a less hackish way, or you can also hack up slony to work
without schemas on newer versions of PostgreSQL so they can talk to
each other.

Almost immediately after getting the DB upgraded from 7.2 to 7.4, we
deinstalled the hacked up Slony (by hand for the most part), and
started a migration from 7.4 to 7.4 on a different machine using the
regular Slony. This was primarily to ensure we didn't keep our system
catalogues which had been manually fiddled with.

All that said, we upgraded a few hundred GB from 7.2 to 7.4 with about
30 minutes actual downtime (versus 48 hours for a dump / restore
cycle) and no data loss.
-----------------------------------------------------------------------

I'm not sure what to suggest with regards to Slony-I versioning; newer
versions have cleaned out some bugs, so I'd tend to think that version
1.1.5 might be the "best" starting point.

But it's possible that there have been changes between the 1.0 and 1.1
series that would make life more difficult for users of PostgreSQL
7.2...

After fighting through this, it would be worthwhile keeping the
modified code and SQL scripts; that could make life easier for others
that want to do this.  We'd not be keen on letting this code into the
"main line," but if it could help others running elderly versions,
having some sort of release for 7.2 would be nice...

> Another possibility is using a command-based replicator, like
> pgmirror, or what Continuent offers. But you need to understand the
> drawbacks of such a method.

Indeed...
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://cbbrowne.com/info/languages.html
"Much of this software was user-friendly, meaning that it was intended
for users who did not know anything about computers, and furthermore
had absolutely no intention whatsoever of learning."
-- A. S. Tanenbaum, "Modern Operating Systems, ch 1.2.4"