[Freeipa-users] Two masters and one of them is desynchronized

[Ludwig Krispenz]

On 08/25/2016 04:41 PM, bahan w wrote:
>
> Hello everyone.
>
> Could you explain to me about this field Sent/Skipped please ?
if replication is enabled all changes on a server are logged into the 
changelog -changes coming from clients and internal changes (eg mmeberof 
update, passwordpolocy updates, lstlogin time ...).
In the replication agreement you can configure attributes for which 
changes are not replicated (keep them local) - and IPA uses this feature 
eg for krblastlogintime.

Looking at the replication traffic your monitoring shows, I think most 
of the "real" updates are going to one server and most of the clients 
triggering internal updates are going to the other. This makes 
replciation in one direction "normal" and in the other fractional. The 
problem with fractional is that the determined staring point for a 
replciation session can b every far behind and it again and again 
iterates over the same changes until finally an update which is not 
skipped is found.

There are some options to improve this:
- upgarde to a newer version, teh DS will automatically generate updates 
to a "keep alive" entry, so that the sequences of skipped changes get 
much smaller
- do it yourself by regularily applying a dummy update on the 
problematic server which will be replicated
- check configuration if writing the internal mods can be avoided, I 
think there is an option not to log krblastlogin

>
> I checked the doc and found this :
> ###
>
> Sent/Skipped :
>
> 	
>
> The number of changes that were sent from the supplier and the number 
> skipped in the replication update. The numbers are kept in suppliers’ 
> memory only and are cleared if the supplier is restarted.
>
> ###
>
> If I check the first part :
> ###
> Master: <MASTER OK>:389 ldap://<MASTER OK>:389/
> Replica ID: 4
> Replica Root: dc=<REALM>
> Max CSN: 57bdcd36000100040000 (08/24/2016 18:37:10 1 0)
> Receiver: <MASTER UNSYNC>:389 ldap://<MASTER UNSYNC>:389/
> Type: master
> Time Lag: 0:00:00
> Max CSN: 57bdcd36000100040000 (08/24/2016 18:37:10 1 0)
> Last Modify Time: 8/24/2016 18:36:32
> Supplier: <MASTER OK>:389
> Sent/Skipped: 182110 / 1054
> Update Status: 0 Replica acquired successfully: Incremental update 
> succeeded
> Update Started: 08/24/2016 18:36:32
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
> ###
>
> This is the replication from the MASTER OK (the supplier) to the 
> MASTER UNSYNC (the receiver), right ?
> So, the MASTER OK sent 182110 changes.
> And in addition to these 182110 changes, 1054 changes were sent to the 
> MASTER UNSYNC but skipped by the MASTER UNSYNC, right ?
> Why are they skipped ?
>
> In the other side, if I take the second part :
> ###
> Master: <MASTER UNSYNC>:389 ldap://<MASTER UNSYNC>:389/
> Replica ID: 3
> Replica Root: dc=<REALM>
> Max CSN: 57bdbda1000000030000 (08/24/2016 17:30:41)
> Receiver: <MASTER OK>:389 ldap://<MASTER OK>:389/
> Type: master
> Time Lag: - 0:22:29
> Max CSN: 57bdb85c000000030000 (08/24/2016 17:08:12)
> Last Modify Time: 8/24/2016 17:07:34
> Supplier: <MASTER UNSYNC>:389
> Sent/Skipped: 3 / 9048655
> Update Status: 0 Replica acquired successfully: Incremental update 
> succeeded
> Update Started: 08/24/2016 18:36:33
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
> ###
>
> The supplier is the MASTER UNSYNC and the receiver is the MASTER OK.
> In this case I have only 3 changes sent.
> And in addition to these 3 changes, 9 048 655 changes were sent but 
> skipped on the MASTER OK, right ?
>
> I ask these questions just to be sure I understand right the return of 
> the pl script.
>
>
> Best regards.
>
> Bahan

-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160825/901224eb/attachment.htm>