Le 28/12/2015 19:12, Quanah Gibson-Mount a écrit :
--On Monday, December 28, 2015 10:44 AM +0400 Jephte Clain jephte.clain@univ-reunion.fr wrote:
hello,
I've had problems with an upgrade to openldap 2.4.43, and I reviewed my configuration to check for errors I have two slaves which replicate all databases from the master, including cn=config.
If the replicas are replicating the provider's cn=config, I doubt they are truly replicas.
Hello,
I'm not sure to understand what you are saying. the "master" and the "slaves" are identical, and the cn=config are the same on all hosts so they are truly replicates, right?
My reasoning is in case of a severe crash, I'd like one of the slaves to be able to become the new master. To allow such a scenario, each database in the master have a syncrepl directive to replicate from itself. It obviously have no effect on the master, but the slave that replicate this configuration get the right directives to replicate from the master. so far so good...
now this is my question: should/could the accesslog configured this way? or should the accesslog be strictly local to a server? I mean, should I remove the syncrepl directive from the accesslog database?
I'm not sure what you mean about a syncrepl directive on the accesslog DB. That sounds like an incorrect configuration.
In fact, the configuration is generated by a script I wrote several years ago, and all databases for a "master" configuration are generated with a syncprov overlay and a syncrepl directive, to enable "seed replication":
dn: olcDatabase={0}config,cn=config ... olcSyncrepl: {0}bindmethod=sasl saslmech=digest-md5 authcid=_config credentials=PASSWORD rid=0 provider="ldap://HOST" searchbase=cn=config type=refreshAndPersist retry="60 10 300 +" schemachecking=off olcUpdateRef: ldap://HOST
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config ...
dn: olcDatabase={1}mdb,cn=config ... olcSuffix: cn=modiflog olcSyncrepl: {0}bindmethod=sasl saslmech=digest-md5 authcid=_syncrepl credentials=PASSWORD rid=1 provider="ldap://HOST/" searchbase=cn=modiflog type=refreshAndPersist retry="60 10 300 +" schemachecking=off olcUpdateRef: ldap://HOST/
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config ...
dn: olcDatabase={2}mdb,cn=config ... olcSuffix: dc=univ-reunion,dc=fr olcSyncrepl: {0}bindmethod=sasl saslmech=digest-md5 authcid=_syncrepl credentials=PASSWORD rid=2 provider="ldap://HOST/" searchbase=dc=univ-reunion,dc=fr type=refreshAndPersist retry="60 10 300 +" schemachecking=off olcUpdateRef: ldap://HOST/
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config ...
After the problems I had, I took the time to read the admin guide again and noticed the accesslog database was not to be replicated, or it seemed so I then wondered if the replication I configured on the accesslog database was the cause for my issues... hence my question to be sure I understood correctly
Here is another question: if an accesslog database is stricly local to a server, how should two masters in mirror mode be configured? I have a bi-master setup with an active/passive configuration: the loadbalancer only send the requests to the first master, unless it stop responding. if the first master crashes, and writes are diriged toward the second master, won't I lose the accesslog informations?
thanks for any input. best regards, Jephté CLAIN