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
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
