[Pacemaker] crm_master triggering assert section != NULL

[Lars Ellenberg]

On Thu, Oct 13, 2011 at 01:21:46AM +0200, Lars Ellenberg wrote:
> On Wed, Oct 12, 2011 at 05:09:45PM -0400, Yves Trudeau wrote:
> > Hi Florian,
> > 
> > On 11-10-12 04:09 PM, Florian Haas wrote:
> > >On 2011-10-12 21:46, Yves Trudeau wrote:
> > >>Hi Florian,
> > >>   sure, let me state the requirements.  If those requirements can be
> > >>met, pacemaker will be much more used to manage MySQL replication.
> > >>Right now, although at Percona I deal with many large MySQL deployments,
> > >>none are using the current agent.   Another tool, MMM is currently used
> > >>but it is currently orphan and suffers from many pretty fundamental
> > >>flaws (while implement about the same logic as below).
> > >>
> > >>Consider a pool of N identical MySQL servers.  In that case we need:
> > >>- N replication resources (it could be the MySQL RA)
> > >>- N Reader_vip
> > >>- 1 Writer_vip
> > >>
> > >>Reader vips are used by the application to run queries that do not
> > >>modify data, usually accessed is round-robin fashion.  When the
> > >>application needs to write something, it uses the writer_vip.  That's
> > >>how read/write splitting is implement in many many places.
> > >>
> > >>So, for the agent, here are the requirements:
> > >>
> > >>- No need to manage MySQL itself
> > >>
> > >>The resource we are interested in is replication, MySQL itself is at
> > >>another level.  If the RA is to manage MySQL, it must not interfere.
> > >>
> > >>- the writer_vip must be assigned only to the master, after it is promoted
> > >>
> > >>This, is easy with colocation
> > >Agreed.
> > >
> > >>- After the promotion of a new master, all slaves should be allowed to
> > >>complete the application of their relay logs prior to any change master
> > >>
> > >>The current RA does not do that but it should be fairly easy to implement.
> > >That's a use case for a pre-promote and post-promote notification. Like
> > >the mysql RA currently does.
> > >
> > >>- After its promotion and before allowing writes to it, a master should
> > >>publish its current master file and position.   I am using resource
> > >>parameters in the CIB for these (I am wondering if transient attributes
> > >>could be used instead)
> > >They could, and you should. Like the mysql RA currently does.
> > >
> > 
> > The RA I downloaded following instruction of the wiki stating it is
> > the latest sources:
> > 
> > wget -O resource-agents.tar.bz2
> > http://hg.linux-ha.org/agents/archive/tip.tar.bz2
> 
> Has moved to github.
> I'll try to make that more obvious at the website,

Hm. That I had already done,
not sure what else I could do there.

> but that won't help for "direct download" hg archive links.

Now, those I simply disabled,
so people will notice ;-)

> http://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/mysql
> 
> raw download:
> http://raw.github.com/ClusterLabs/resource-agents/master/heartbeat/mysql
> 
> Also see this pull request:
> https://github.com/ClusterLabs/resource-agents/pull/28


-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com