[Linux-HA] Openldap master/slave question

[Dejan Muhamedagic]

Hi,

On Wed, Oct 24, 2007 at 11:49:12AM +0200, Boróczki Lajos wrote:
> Dear List,
> 
> I've managed to create an openldap master/slave setup with heartbeat2
> and lsb scripts. But I have the following problem: 
> 
> When I start up heartbeat everything works fine. Making one of the nodes
> go standby works fine: when it was the node with ldap-slave running
> nothing happens; when the ldap-master goes standby, ldap-slave service
> is stopped, and ldap-master service is started. 
> 
> But when I reactivate the node, every service suddenly stops and
> restarts on a random node (conforming the constraints I set.) This means
> in real life if somebody modified something on the ldap database and the
> ldap-master service starts on the other node, we have an incosistent
> master/slave database.

In this case, there's a peace of an important information (the
LDAP database is up to date _only_ on this node) missing. It has
to be somehow relayed to the cluster (by way of a resource
agent), something like:

	It is infinitely preferable to keep the master here if the
	database changed since the slave was down.

Though, I must say that it is not clear to me how to do that. I'm
not sure if this issue can be resolved in the optimal way: how do
you know that the database changed in the meantime? The only way
to learn that is to compare databases which reside on two
different nodes, but that information is not readily available.

The best bet would be just not to move the master unless
necessary. Did you try to set the default resource stickiness to
INFINITY? In that case resources should prefer to stay put
unless there's a real outage.

Thanks,

Dejan

> I have attached my running configs.
> 
> Thanks for the help,
> Lajos
> 
> ps: Hope I was clear...


> #debugfile /var/log/ha-debug
> #logfile	/var/log/ha-log
> #logfacility	local0
> #keepalive 2
> #deadtime 30
> #warntime 10
> #initdead 120
> #udpport	694
> #baud	19200
> #serial	/dev/ttyS0
> bcast	eth1 
> #bcast	eth3
> ucast eth0 10.35.152.159
> #ucast eth2 10.35.152.158
> #mcast eth0 225.0.0.1 694 1 0
> auto_failback off
> #stonith baytech /etc/ha.d/conf/stonith.baytech
> #stonith_host *     baytech 10.0.0.3 mylogin mysecretpassword
> #stonith_host ken3  rps10 /dev/ttyS1 kathy 0 
> #stonith_host kathy rps10 /dev/ttyS1 ken3 0 
> watchdog /dev/watchdog
> node	mail1
> node	mail2
> #ping 10.10.10.254
> #ping_group group1 10.10.10.254 10.10.10.253
> #hbaping fc-card-name
> #respawn userid /path/name/to/run
> #respawn hacluster /usr/lib/heartbeat/ipfail
> #apiauth client-name gid=gidlist uid=uidlist
> #apiauth ipfail gid=haclient uid=hacluster
> ###########################
> ###########################
> #hopfudge 1
> #deadping 30
> #hbgenmethod time
> #realtime off
> #debug 1
> #apiauth ipfail uid=hacluster
> #apiauth ccm uid=hacluster
> #apiauth cms uid=hacluster
> #apiauth ping gid=haclient uid=alanr,root
> #apiauth default gid=haclient
> #msgfmt  classic/netstring
> use_logd yes
> #conn_logd_time 60
> #compression	bz2
> #compression_threshold 2
> crm yes

> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems