The sequences do not update automatically on the slave(s) in the version we are running ... we do have a cron job that kicks off every few minutes and updates them based opn the current value of their respective columns, which so far has been all we needed. G
Slony-I does replicate sequences in a way that could be considered a compromise. The whole replication process is done in a way that the slaves "leap" from one consistent state into another, and these consistent states are about 10 seconds apart. The sequences get adjusted to a value equal or greater than what is "compatible" with that current sync status, so that a failover would not cause duplicate values.
That way, sequences still retain all their concurrency advantages while being adjusted continuously to avoid problems on failover. The mechanism has of course the usual gap-problem, since a sequences value can be adjusted higher than the rows that actually get replicated in that replication round.
They get properly adjusted to exact values on a controlled switchover, where the master and slave cooperate and the old master assumes a fully synchroized slave status when the switchover is complete.
Jan
-----Original Message----- From: Fred Fung [mailto:fred.fung@versaterm.com] Sent: Fri 5/14/2004 6:11 AM To: pgsql-general@postgresql.org Cc: Subject: Re: dbmirror 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 4: Don't 'kill -9' the postmaster
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
