September 13, 2018 at 12:02 pm #23181Rob MatthewsParticipant
There isn’t a way to force it to re increment. You’ve tried one of the possible “fixes” to get it running again which hasn’t worked. Do the most recent changenumbers match on each instance? You could try using the dsreplication reset-change-number command to sync the changenumber from one instance to the other, although to be honest I would expect that is more a fix for if one of the instances has stopped incrementing, not both.
The other fix I have seen used is to disable replication, remove the contents of the changelogDB directory on both instances and then re-enable replication and re-initialize. This will recreate the changelog directories on both instances, the only concern here is if you have either, changes that have not been replayed to the other instance (your dsrep status shows the same entry count so this is probably ok) or if you have another application that uses the DJ changelog to update itself (IDM for example).September 13, 2018 at 1:48 pm #23183
I use OpenIDM to send info of a user from OpenIDM to OpenDJ. I try to do that:
The other fix I have seen used is to disable replication, remove the contents of the changelogDB directory
and changeNumber starts running but replication not work again, I modify an user and in the other server not been modified and changenNumber neither update. Any other options or commands to work replication again?
Thaks a lot!!!September 14, 2018 at 3:32 pm #23211Rob MatthewsParticipant
Did you reinitialize replication after you re-enabled it? Do you see any errors in your replication logs?September 19, 2018 at 9:27 am #23224
Coult It be because exists a little data and schema differences between nodes?
Thanks.September 20, 2018 at 8:53 am #23237LudoModerator
Troubleshooting this kind of errors without proper data is almost impossible.
We’ve given ideas on what to look for, alternatives to recover and resume the service.
You’re not even sure of the version, you are using (you can run
start-ds -V, and send the output).
If you are a ForgeRock customer, please raise a support ticket.
If you’re not, you will need to provide more data including the configuration of your servers, the content of the admin-backend.ldif, and the log files (under /logs).
LudoSeptember 24, 2018 at 1:26 pm #23257
But I realize that I have diferences in data and schema between nodes. Could it be why it can not replicate nodes?
Thanks.September 24, 2018 at 2:07 pm #23261LudoModerator
Replication is about making sure data and schema are identical across nodes. There is a mandatory initialisation phase, and then things will be kept synchronised.
If the server cannot replicate due to these differences, there will be explicit error messages at the start of the replication service (at server startup).September 25, 2018 at 11:20 am #23275
In my case, replication command ” replication enable …” do it perfectly but not replicate changes either changeNumber. If I initializate the content of nodo 1 to nodo 2 it could resolv this?
Thanks again!!September 25, 2018 at 3:14 pm #23276Michelle ReaginParticipant
Hi, Borjagc. I see this is not the first topic in which you’ve mentioned problems with change log numbers. We would love to assist you, but it is difficult to do so without the details requested by Ludo. If you could provide the output of
start-ds -V, the
OpenDJInstallDIR/config/admin-backend.ldif, and the files within
OpenDJInstallDIR/logs/we’d be able to give you clearer guidance.
October 4, 2018 at 11:46 am #23342Andy CoryParticipant
- This reply was modified 1 month, 3 weeks ago by Michelle Reagin.
The fact that replication is set up for the same baseDN twice cannot be helping this. Having duplicate DSid and RSid is a sure way for replication to behave in an unexpected manner.October 5, 2018 at 8:28 am #23348
Thanks. It solved. The problem is de difference on data of two ldaps… Thanks all!
You must be logged in to reply to this topic.