W dniu 10.12.2013, 18:12, Quanah Gibson-Mount pisze:
--On Tuesday, December 10, 2013 11:08 AM -0600
espeake(a)oreillyauto.com
wrote:
> Do the slapcat on ldap2 and then delete the db files on ldap1 and then
> run
> the slapadd. you will not get duplicates because all of the CSN's
> will be
> the same. This is what I have done my migrations to the most recent
> versions and doing my own builds. Works great that way.
Huh?
The CSNs contain the server IDs. Servers ignore their own changes.
I admin I was not (yet!) forced to recover OpenLDAP master server from
serious disaster.
How should I recover any single master in topology where total number of
masters is more than two - and modifications are made across all of
them? I'm using LTB project package - its start+stop script is also able
to make backups of server configuration and all databases.
Will replication manage to bring recovered master up-to-date based on
slapadd from output of slapcat from *any* of other masters? Or more
proper way is to restore last backup of configuration and database and
let replication do the rest? Of course preventing clients to contact
LDAP server until replication finishes is a must in such a situation.
Best regards,
--
Olo