I have a strange behaviour with failback of my omnibus.
So i have two object server (Primary and Backup).
On backup server, i have a bi-directionnal gateway which is configured with Gate.Resync.Type => 'UPDATE'.
This is strange behaviour (for me..)
1 - Primary and Backup object server are UP
2 - I sent an event YYY (and wait it is replicated on Backup)
3 - I stop Object Server primary
4 - I delete event YYY on Backup
5 - I start Object Server Primary
6 - Resynchronisation between two object server occurs
7 - I look in Object Primary and i see that my event YYY is always here.. it has not been deleted during synchronisation ...
I open a PMR (IBM Support) and thay seems to say me that is a normal behaviour ???!!
So it seems it is impossible to have a perfect synchronisation between the two object server omnibus ? I wouls like to have your advice about this subject.. For me it is a bug..
Pinned topic Omnibus 7.2.2 : Failback : Gate.Resync.Type => 'UPDATE' : Event deletion
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-10-05T19:18:50Z at 2012-10-05T19:18:50Z by SystemAdmin
rkrzywicki 0600013MKH133 Posts
Re: Omnibus 7.2.2 : Failback : Gate.Resync.Type => 'UPDATE' : Event deletion2011-02-16T20:36:24ZThis is the accepted answer. This is the accepted answer.The UPDATE option does not resync deletes, although I don't know why. If you want to ensure that deletes are resynced, then use either NORMAL or MINIMAL.
Re: Omnibus 7.2.2 : Failback : Gate.Resync.Type => 'UPDATE' : Event deletion2012-09-21T13:47:14ZThis is the accepted answer. This is the accepted answer.
- rkrzywicki 0600013MKH
1) What is the interval of the full db sync process?
2) Are any configurations of the gateways(UNI) that would allow to control the behavior of the gateways w.r.t. this event sync'ing? I am thinking the we could minimize the problem if we could limit the event sync process to only sync events in the last 90-120 minutes or so. That way there would be minimal double event deletions.
Re: Omnibus 7.2.2 : Failback : Gate.Resync.Type => 'UPDATE' : Event deletion2012-09-21T21:24:56ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
Data on all of the questions so far are documented in the gateway guide.
GQ4Q_Simon_Knights 060000GQ4Q7 Posts
Re: Omnibus 7.2.2 : Failback : Gate.Resync.Type => 'UPDATE' : Event deletion2012-09-26T10:55:13ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
- if the Gateway is running and connected to an active ObjectServer when the delete occurs , deletes are propagated across
- if the Gateway, ObjectServer or connection aren't active, deletes aren't propagated
Resync types of 'NORMAL' and 'MINIMAL' delete events in the target object server that were not in the source object server. (MINIMAL requires a trigger is activated to do the deletes). 'UPDATE' does not delete events when the resync completes.
If store and forward mode is activate on the Gateways, it will store all requests that occur whilst the connection is not active, and replay them when the connection restarts. This includes deletes. The store and forward option is activated by setting "SAF" and "SAFReplayOnResync" properties. NOTE: the SAF file could quickly become large on a busy system. The SAF options would not be needed on 'NORMAL' or 'MINIMAL' resync where events are deleted on reconnect.
It might to be possible to limit the events that are resynced across to a specific time period for NORMAL and UPDATE types by specifying a filter in the Gateway REPLICATION definition. For example:
REPLICATE ALL FROM TABLE 'alerts.status'
USING MAP 'StatusMap'
FILTER WITH 'StateChange > getdate() - NNNN';
where 'NNNN' is the time period you want pull events over for.
I've not tested this, and have not come across other customers running with this filter or SAF active on a Gateway. So this would need to be
carefully tested to make sure there a no unintended consequences (such as old events getting deleted).