Hi!
I have two replicas of my DIT, which unfortunately got out of sync somehow. So I can spot a particular object where one attribute has a different value on one replica than it has on the other one.
What would I do to find out how that could have happened?
What would I do to fix this? (Other than manually deciding which data is the right one and overwrite the other; I guess this may not even fix it for the next update.)
Regards, Torsten
On Wed, 7 Apr 2010, Torsten Schlabach (Tascel eG) wrote:
What would I do to find out how that could have happened?
Perhaps you could read the output of "loglevel sync" -- admittedly this might not be of help after the fact, but perhaps for next time...
What would I do to fix this? (Other than manually deciding which data is the right one and overwrite the other; I guess this may not even fix it for the next update.)
That may depend on your local policies and applications, but one simple rule of thumb might be to take the entry with the later timestamp. However, in most OpenLDAP installations, implementing this should be as simple as "the slapcat from the master wins." Multimaster and/or mirror-mode might make this a bit more complex.
On Wed, Apr 07, 2010 at 01:04:33PM +0200, Torsten Schlabach (Tascel eG) wrote:
I have two replicas of my DIT, which unfortunately got out of sync somehow. So I can spot a particular object where one attribute has a different value on one replica than it has on the other one.
What would I do to find out how that could have happened?
There may be some evidence in the logs, but only if you have a suitable level of logging enabled.
What version of OpenLDAP, and what is the replication config? It would be useful to know what the differences are in the two replicas, and what the timestamps are on the entries. As the administrator of the system you might be able to guess where the change came from.
You should check that the two servers have identical schema and ACLs.
You should also check that the clocks are synchronised.
What would I do to fix this? (Other than manually deciding which data is the right one and overwrite the other; I guess this may not even fix it for the next update.)
In a master-slave setup it should be enough to modify the attribute on the master (you may need to remove the attribute and re-add it, depending on what the differences are).
In a multi-master or mirrormode setup you should be able to correct the error from either end, though again it may require the attribute to be deleted and re-added. Not sure what would happen in the case that you need to delete an attribute that is already missing though!
Andrew
openldap-software@openldap.org
-
Aaron Richton -
Andrew Findlay -
Torsten Schlabach (Tascel eG)