Andrew Sullivan wrote:
> On Tue, Jun 02, 2009 at 10:30:45AM -0500, Sean Staats wrote:
>   =

>> I created a new replication cluster.  It turns out that starting the  =

>> table IDs at id=3D1 and the sequence IDs at id=3D1001 didn't make any  =

>> difference as slony gave me the same error (sequence ID 1001 has already=
  =

>> been assigned.)  Increasing the log verbosity to 4 doesn't produce any  =

>> more useful debugging information.  Time for another approach.
>>
>> Would it make sense to create 2 different sets - one to replicate the  =

>> tables and one to replicate the sequences?  Is there a downside to this  =

>> kind of workaround?
>>     =

>
> It'd be better to figure out what the duplication is caused by.  Have
> a look in the _slony tables and check to see what's in there.  Where's
> the collision?
>
>   =

I've seen this issue recently when the initial sync fails.  If you
scroll further back in your logs do you have a failure for the initial
copy_set?  When this happens to me, it seems that slony leaves the slave
DB in a half replicated state, but reattempts to do the initial sync and
finds that the sequences are already in _cluster.sl_sequence table, then
errors out.  This requires dropping the node and starting over.  This is
with version 1.2.16. I recall previous versions being able to recover
from a failed initial sync without intervention, but my memory could be
mistaken.


-- =

Jeff Frost, Owner 	<jeff at frostconsultingllc.com>
Frost Consulting, LLC 	http://www.frostconsultingllc.com/
Phone: 916-647-6411	FAX: 916-405-4032

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20090602/=
c08c11fb/attachment.htm