In what follows I will assume that the parent PMDB is called My_PMDB and that the endpoint having lost synchronization is <Subscriber>.example.com
First of all it is always good to run
sepmd -e My_PMDB >>My_PMDB_Errors.txt
and look at the different possible errors. This may give back some clue as to the failures to synchronize. In absence of further information, there are several things we can try at the parent My_PMDB server:
- Run sepmd -R My_PMDB --> That should be sending immediate update of the offset
- Run sepmd -r My_PMDB <Subscriber>.example.com --> This will try to remove the subscriber from the list of unavailable and do a synchronization
- Also sepmd -e My_PMDB will tell us if there are errors that may give us a clue if this does not work.
If this still does not work, it is worth checking that the PIM database at the endpoint for possible errors. To do that go to the endpoint that fails to synchronize, <Subscriber>.example.com and bring down Access Control (secons -S). Then change to the directory where the database is. For instance /opt/CA/AccessControl/seosdb, and run
dbmgr -util -check
and then
dbmgr -util -build seos_cdf.dat
dbmgr -util -build seos_odf.dat
dbmgr -util -build seos_pdf.dat
dbmgr -util -build seos_pvf.dat
This will rebuild the indexes and clear possible corruptions on this side
Then restart AC in this server and launch another sepmd -R My_PMDB in the master to see if it does the synchronization.
If this still fails we can try to unsynchronize and resynchronize the database between the master and the endpoint having lost synchronization.
- Firstly, clear the list of errors in the parent DB to capture eventual problems (make sure to save them directing sepmd -e My_PMDB to a file):
sepmd -e My_PMDB >>My_PMDB_Errors.txt
- Now let's log in to the endpoint having the problems. First please check that name resolution and IP is correct from the parent PMDB to the subscriber and also that you can connect from selang. To do that do
selang in the parent pmdb
host <Subscriber>.example.com
you should be able to access it and also to do some commands inside like sr FILE * or similar. This is just for sanity check, to make sure there is connectivity
- Now log in to the endpoint having problems, <Subscriber>.example.com and stop AccessControl there (secons -S)
- Take a backup of the directory where the database is. This is to be on the safe side and to make sure all is good. We will unsubscribe now it from teh master database and resubscribe it
- Now in the master database server, let's unsubscribe the machine that does not take the updates. Please save beforehand the subscribers.dat in the master database server. This is just in case something goes wrong.
sepmd -u My_PMDB <Subscriber>.example.com
Once unsubscribed, let's resubscribe it
sepmd -s My_PMDB <Subscriber>.example.com
If worse comes to worse we can always revert back with the copy of the database and the subscribers.dat which we have saved earlier. Synchronization should however be happening now
- If this does not help still, we can completely delete the database in the secondary, recreate it from scratch and rebuild it, unsubscribe and resubscribe. Since this is a more delicate operation we suggest to contact support to seek help.