]> granicus.if.org Git - postgresql/commit
Attached is a patch that provides *VERY* limited support for multiple
authorBruce Momjian <bruce@momjian.us>
Wed, 25 Jun 2003 01:17:44 +0000 (01:17 +0000)
committerBruce Momjian <bruce@momjian.us>
Wed, 25 Jun 2003 01:17:44 +0000 (01:17 +0000)
commitb24a0293cc867ec0ad0a924ae976cc6ab9d12f90
treee4b4646f101b5a7c612a732411401a6d00b11b2f
parente1be2ee831f2cc2754156bb923efc5818e98ec75
Attached is a patch that provides *VERY* limited support for multiple
slave
servers.  I haven't tested it very well, so use at your own risk (and I
recommend against using it in production).

Basically, I have a central database server that has 4 summary tables
inside
it replicated to a remote slave (these database tables are for my mail
server
authentication, so these are replicated to another server tuned for many
connections, and so I don't have postgres connections opened straight to
my
back-end database server).

Unfortunately, I also wanted to implement a replication database server
for
hot-backups.  I realized, too late, that the replication process is
pretty
greedy and will try to replicate all tables marked as a
"MasterAddTable".

To make a long story, I made a patch to RServ.pm and Replicate that
allows you
to specify, on the command line, a list of tables that you want to
replicate...it'll ignore all others.

I haven't finished, since this has to be integrated with CleanLog for
instance, but this should (and does) suffice for the moment.

I have yet to test it with two slaves, but at least my mail server
replication
database now works (it was failing every time it tried to replicate, for
a
variety of reasons).

Anyone have any suggestions on how to improve on this?  (or, if someone
more
familiar with this code wants to take the ball and run with it, you're
welcome to).

--
Michael A Nachbaur <mike@nachbaur.com>
contrib/rserv/RServ.pm
contrib/rserv/Replicate.in