I recall recently seeing something in the CVS logs for dbmirror about the sequence replication capability having been added, so you might check on that. On Friday May 14 2004 7:11, Fred Fung wrote: > Thanks for all your comments. > > Is it really true that the sequences in the tables in the Slaves will not > be in sync with those in the Master ? If so then this is a show-stopper > factor for us to consider using dbmirror, as we use sequences as a unique > key in many of the tables in our application. > > What is Slony-I ? Is it a commerical software ? Is there a website I can > read more about it ? > > > Thanks. > > > Fred > > > ----- Original Message ----- > From: "Gregory Wood" <gwood@ewebengine.com> > To: "Andrew Sullivan" <ajs@crankycanuck.ca> > Cc: <pgsql-general@postgresql.org> > Sent: Thursday, May 13, 2004 4:10 PM > Subject: Re: dbmirror > > > Does dbmirror do that? No, it does not. It also doesn't support > > promoting a slave database to a master; that has to be done manually, > > so I wouldn't consider that too big a problem. > > > > Worse in my opinion is that sequences don't get updated... so a slave > > that tries to do an insert on a replicated table (for example, when it > > gets manually promoted to master) will find the sequence not where the > > master left it, but where it was loaded. Every sequence has to be > > manually updated before the database is usable. > > > > dbmirror was never intended to be anything but a poor man's > > replication... and it worked remarkably well for that purpose. Now it's > > time to look forward to Slony-I :) > > > > Greg > > > > Andrew Sullivan wrote: > > > On Wed, May 12, 2004 at 05:53:05PM -0700, Gregory S. Williamson wrote: > > >>Fred -- > > >> > > >>Yes, the slave database(s) can be safely used in a R/O mode, > > > > > > Does it also block write transactions in those slaves? The ability > > > for clients to write into the slave replicated tables is a problem, > > > because it makes promoting a slave node somewhat risky. > > > > > > Slony-I has a trick to solve this problem, BTW. > > > > > > A > > > > ---------------------------(end of > > broadcast)--------------------------- TIP 3: if posting/reading through > > Usenet, please send an appropriate subscribe-nomail command to > > majordomo@postgresql.org so that your message can get through to the > > mailing list cleanly > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org