This topic contains 19 replies, has 3 voices, and was last updated by 
Ludo 4 days, 4 hours ago.
-
Posts
-
Hi,
When I sync changenumber on OpenDJ I have this error (using dsreplication and Re-synchronizes the change-log changenumber on one server with the change-log changenumber of another.):Cannot reset change-log change number because replicated baseDNs on server sctstgiddj01.sespa.es:4444 and server sctstgiddj02.sespa.es:4444 differ. Since the change number is computed across all the replicated baseDNs, the change-log change number can only be reset between two replication servers replicating the exact same baseDNs.What It could be?
Thanks.-
This topic was modified 2 weeks, 6 days ago by
user1234.
Hi,
If you run a dsreplication status on both instances do they show the same replicated baseDN’s?
It’s possible that there are differences in the names of the backends on each replica (like different character case). Known issue and I believe a fix has been implemented and tested.
yes, I have the same base DN’s. Now I have the replication active but I have to stop (and then I cant enable again) to reset changeNumber because not update the value of it on my replication and I cant do nothing to update the value with changes, only update lastExternalChangelogCookie. Do you know what It could be this errors with changeNumber and replication?
Thanks.The process to reset changeNumber doesn’t require to unconfigure replication nor to stop servers.
Please run dsreplication status and put the output here, so that we can check.
And tell us which version of OpenDJ you are running.The error message is explicit, there are differences between the 2 servers with regards to the backends and baseDNs. As I said, this is a known issue that has been fixed in our development branch and patches are available for customers.
Hi,
But the problem is that I have replication enable but changenumber not increase, its freeze. So I have to stop and start replication, or what I can do? Thanks.It is hard to guess what issue you might be hitting without knowing the version and having a dsreplication status.
Sometimes setting compute-change-number to false and then setting it back to enabled again will kick it in to life without a restart.
Hi,
my version is OpenDJ 3.5 ( I think).
dsreplication status:
Suffix DN : Server : Entries : Replication enabled : DS ID : RS ID : RS Port (1) : M.C. (2) : A.O.M.C. (3) : Security (4)
———-:————————-:———:———————:——-:——-:————-:———-:————–:————-
o=example : 192.116.160.23:4444 : 32499 : true : 10043 : 4883 : 8989 : 0 : : false
o=example : 192.116.160.24:4444 : 32499 : true : 18485 : 2141 : 8989 : 0 : : false
o=example : dj01.example.local:4444 : 32499 : true : 10043 : 4883 : 8989 : 0 : : false
o=example : dj02.example.local:4444 : 32499 : true : 18485 : 2141 : 8989 : 0 : : false[1] The port used to communicate between the servers whose contents are being
replicated.
[2] The number of changes that are still missing on this server (and that have
been applied to at least one of the other servers).
[3] Age of oldest missing change: the date on which the oldest change that has
not arrived on this server was generated.
[4] Whether the replication communication through the replication port is
encrypted or not.How Can I change setting compute-change-number to false ?
Thanks .It’s a replication server property so you can set it with dsconfig set-replication-server-prop. It is discussed in the DJ/DS reference docs
The dsreplication status is a bit strange, you have replication configured twice for the same baseDN, once for IP and once for FQDN?
Yes, once for IP and once for FQDN
Please, help! :(
I don’t think it’s best practice to have both FQDN and IP for the same baseDN, apart from creating extra traffic for replicated domains it also means you have duplicate DS/RS Id’s. Do you see any warnings in the logs about this?
Did you try setting the compute-change-number to false and then true?
There is a bug around changenumbers not incrementing if a DS/RS is stopped or removed from the topology, are both instances up and have the IP’s/FQDN’s remained the same? Was there another instance that has been removed? Do you see any errors in your replication/error logs that might indicate an issue?
Did you try setting the compute-change-number to false and then true?
I did this but nothing happend…
There is a bug around changenumbers not incrementing if a DS/RS is stopped or removed from the topology, are both instances up and have the IP’s/FQDN’s remained the same? Was there another instance that has been removed? Do you see any errors in your replication/error logs that might indicate an issue?
I dont see nothing in replication/error logs, but if it this the problem, How can I solved this? Is there any option to force the re-increment of the ChangeNumber?
Thanks a lot Rob!My version is 3.0, I check wrong the other time
Any help?
-
This topic was modified 2 weeks, 6 days ago by
You must be logged in to reply to this topic.
