Brian Fehrle wrote:
> Steve Singer wrote:
>> Brian Fehrle wrote:
>>
>> > Hi all,
>>


> All entries between sl_event and sl_confirm match exactly (each 
> con_seqno from sl_confirm matches an ev_seqno from sl_event)

It sounds like your cluster is caught up.

> On both the master and the slave, there are zero entries in either 
> sl_log_1 or sl_log_2.
>>
> I was wondering the same thing, however doesn't the slave node refuse 
> updates/inserts/deletes via a locking system? There are quite a few 
> people who use the databases and I can't account for all actions by 
> everyone. I will give this sync command a try in a bit, I need to wait 
> on some things before I can give it a try.

The slave should refuse updates to replicated tables except if your run 
EXECUTE SCRIPT, the execute script commands restores the tables on the 
replica to the normal state then runs the SQL in your script.  Once it 
is finished the replica deny triggers get enabled again.

 From what your saying the possible sources of the issues are

1) There was some sort of issue in initial sync that prevented some rows 
from being replicated and no error was generated (I don't think this is 
likely but there could be a bug somewhere)

2) There is some sort of bug that caused changes to not replicate either 
the trigger didn't fire properly or something got marked as replicated 
when it didn't.  I'd be surprised if your the only one reporting this 
but anything is possible

3) Someone ran EXECUTE SCRIP(ONLY ON=?) either with a INSERT on the 
oriigin that wouldn't get replicated or with DELETE on the replica.

4) Someone with sufficient privileges connected to either the origin or 
the replica and manipulated things to circumvent the slony triggers

5) Someone did an ALTER TABLE ... without using execute script leaving 
your replication triggers in a bad state.




> 
> Another thing that has come to mind, when we first added this table to 
> the replication set, we had a few problems with some of our scrips which 
> resulted in a daemon attempting to start the slon daemons even if they 
> were already running. Normally the daemons are smart enough to kill 
> themselves, however since this was going on during the initial 
> propagation of the data to the slave, it may have done something 
> unintentional.

I've never seen this, but I guess it is possible.


> 
> - Brian
>>
>> Steve
>>
>>
>>




-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142