Le 11/05/2015 20:23, Greg Sabino Mullane a écrit :
Correct. All of the replication happens inside of a transaction, so
other connections will only see the final state after all the changes
have been applied.
Ok.
>2) About notifications, add/remove and always trigger:
>Each time a modification (add/remove/update) is done on a row, a
>trigger is called and notifies about the change. To make sure that
>notifications are sent on the slave, we have updated the triggers as
>always trigger.
>This works for add and remove, but as an update is done with delete
>followed by copy, we have some difficulties to make the distinction
>between a "real" add, a "real" remove and an update that leads to
>remove/add events.
>Any ideas about that?
Do not set the triggers as 'always' - as you found out, that can lead
to confusion. Why does the default trigger behavior (e.g. 'origin',
not 'always'), work for you? There are some other workarounds that
should be tried before resorting to setting triggers as 'always'.
In both the slave and the master, there is a daemon that listens for
postgres notification (NOTIFY) messages.
The NOTIFY themselves are sent by specific triggers which role is only
to sent notifications:
-when a new event is added in the events table;
-when an event is deleted in the events table;
-and when some important fields of the event tuple are modified.
In the deamon, a specific action related to the type of message
(event_added, event_removed, event_updated) is done.
This was working correctly without failover. When the failover with
bucardo was introduced, I thought I could simply change the "notify"
triggers as always trigger, so that the daemon that is on the slave be
notified the same way the master daemon is. But this does not work
correctly, like I explained above.
I amcurrently thinking of relying on another bus to propagate the
messages on the slave instead of relying of the postgres notification
that requires 'always' trigger to work "more or less" . Then I could
restore the trigger as 'origin' trigger.
Thanks for your response, and regards,
Sylvain
_______________________________________________
Bucardo-general mailing list
[email protected]
https://mail.endcrypt.com/mailman/listinfo/bucardo-general
