[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: what databases are to be replicated for a slave?

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:


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.

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

*Jephté CLAIN | Développeur, Intégrateur d'applications*
Service Systèmes d'Information
Direction des Systèmes d'Information <http://dsi.univ-reunion.fr>
Tél: +262 262 93 86 31 <tel:+262262938631> || Gsm: +262 692 29 58 24 <tel:+262692295824> www.univ-reunion.fr <http://www.univ-reunion.fr> || Facebook <http://www.facebook.com/pages/Universit%C3%A9-de-La-R%C3%A9union-OFFICIEL/197176816990430> || Twitter <http://twitter.com/univ_reunion>